linux-kernel - Re: [Intel-gfx] [PATCH v3 1/1] drm/i915: Enabling 128x128 and 256x256 ARGB Cursor Support

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]

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/