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]
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ