linux-kernel - Re: [PATCH 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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20140225113520.GA723@ulmo.nvidia.com>
Date:	Tue, 25 Feb 2014 12:35:21 +0100
From:	Thierry Reding <thierry.reding@...il.com>
To:	Ville Syrjälä <ville.syrjala@...ux.intel.com>
Cc:	sagar.a.kamble@...el.com, Daniel Vetter <daniel.vetter@...ll.ch>,
	intel-gfx@...ts.freedesktop.org,
	"G, Pallavi" <pallavi.g@...el.com>, linux-kernel@...r.kernel.org,
	dri-devel@...ts.freedesktop.org
Subject: Re: [PATCH 1/1] drm/i915: Enabling 128x128 and 256x256 ARGB Cursor
 Support

On Tue, Feb 18, 2014 at 03:13:33PM +0200, Ville Syrjälä wrote:
[...]
> Once we have drm_planes for cursors, I was thinking we might add some kind
> of enum property that lists all the supported sizes for the plane.

This comment was intriguing, so I was wondering whether you could
elaborate a little on this. The reason why I ask is that we have a
fairly similar issue on Tegra, where recent hardware supports 128x128
and 256x256 hardware cursors, whereas older generations support only
32x32 and 64x64. Also very early generations don't support ARGB cursors,
but a somewhat funky pixel format (2 bpp, background, foreground,
transparent, invert).

With the current set of cursor IOCTLs it isn't really practical to
support the legacy kind of cursors, but representing the cursor as a
plane would have the benefit of attaching a number of supported formats
as well as resolutions to it. That would make it a whole lot easier to
support these additional modes.

As for the supported sizes enumeration, how do you intend to handle the
correlation between horizontal and vertical sizes, since an enumeration
property is only a single 32-bit value. I suppose if we limit ourselves
to supporting only cursors with 64Kx64K we could stash horizontal and
vertical dimensions into a single 32-bit value.

Also, is there a plan to add a type field to the planes so that
userspace can determine if it's a proper overlay or a cursor?

Thierry

Content of type "application/pgp-signature" skipped