On Mon, Mar 10, 2014 at 11:07 AM, Daniel Vetter daniel.vetter@ffwll.ch wrote:
On Mon, Mar 10, 2014 at 11:04 AM, Chris Wilson chris@chris-wilson.co.uk wrote:
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.
Adding the cap allows existing userspace to dtrt...
- Move cursor off-screen.
- Check desired cursor layout with set_cursor.
- Pick real cursor, set it.
Or
- Use set_cursor on disabled crtc.
Both aren't pretty, but that ugly should help to move cursors-as-real-planes forward ;-)
I stand corrected, there's now a cursor size cap in the drm-next branch (which is included in -nightly), so we need support this and also make sure it works correctly in the igt. -Daniel