On Mon, Mar 10, 2014 at 11:07 AM, Daniel Vetter <daniel.vetter@xxxxxxxx> wrote: > On Mon, Mar 10, 2014 at 11:04 AM, Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> 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... > > 1. Move cursor off-screen. > 2. Check desired cursor layout with set_cursor. > 3. Pick real cursor, set it. > > Or > > 1. 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 -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
