lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKMK7uEFpkRs5euH_un=3MEstwO2PMwk0RAOhP-2+cgfMK1sgA@mail.gmail.com>
Date:	Mon, 10 Mar 2014 10:55:40 +0100
From:	Daniel Vetter <daniel.vetter@...ll.ch>
To:	Chris Wilson <chris@...is-wilson.co.uk>,
	Sagar Arun Kamble <sagar.a.kamble@...el.com>,
	Alex Deucher <alexdeucher@...il.com>,
	Daniel Vetter <daniel.vetter@...ll.ch>,
	Intel Graphics Development <intel-gfx@...ts.freedesktop.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Maling list - DRI developers 
	<dri-devel@...ts.freedesktop.org>
Subject: Re: [Intel-gfx] [PATCH v3 1/1] drm/i915: Enabling 128x128 and 256x256
 ARGB Cursor Support

On Mon, Mar 10, 2014 at 10:29 AM, Chris Wilson <chris@...is-wilson.co.uk> wrote:
>> Realized after sending mail that we just get to know current cursor
>> width and height. Can we have capability that exposes all supported
>> cursor sizes?
>
> The cap exposes the max cursor size. Knowing our hardware we can infer
> that pot sizes from 64 to max are supported, but it would be better if
> we did expose that information through the cap as well.

I think the right approach here is to expose this through the
cursor-as-real-plane interface, which kinda has this already. On top
of that we can then add a few fourcc enumerations of the fixed rgba
cursor layouts like 64x64, 128x128, ... This helps if the plane is a
general one with very high limits, but also with special support for
cursor formats.

If anyone wants to go crazy we could then also add new fourccs for all
the other cursor layouts - atm only rgba with fixed dimensions can be
support with the current cursor ioctl.

So reviewing the overall situation I actually _don't_ want a new
cap/ioctl/prop here just for now. As long as we need to go with intel
specific hacks userspace might as well probe things manually and act
upon the -EINVAL.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ