On Tue, Mar 25, 2014 at 03:09:16PM +0000, Chris Wilson wrote: > On Tue, Mar 25, 2014 at 02:59:18PM +0000, Damien Lespiau wrote: > > On Tue, Mar 25, 2014 at 02:54:56PM +0000, Chris Wilson wrote: > > > On Tue, Mar 25, 2014 at 02:49:30PM +0000, Damien Lespiau wrote: > > > > Those fields are supposed to be a good default value for the cursor > > > > size, intended for the case where the hardware doesn't support 64x64 > > > > cursors, for use with a hw agnostic DDX driver for instance. > > > > > > > > We're fine with 64x64 cursors though and don't need to set those fields > > > > (DRM core will return 64 is we don't). If we declare 256x256, that > > > > generic driver will use a big buffer for the cursor, without any good > > > > reason. > > > > > > How does userspace now know that 256x256 cursors are support for HiDPI? > > > > It doesn't currently? a property on the cursor plane with the list of > > supported formats in the brave new full drm_plane world seems like a > > good option to me. > > Userspace currently uses this method to determine the largest cursor > supported by the driver. That userspace is inept at resize the cursor bo > as required is a probably that won't be solved by simply exposing it > later. That doesn't seem to be the intention of the original patch? http://lists.freedesktop.org/archives/dri-devel/2014-February/053770.html Are you saying the Intel DDX currently derives a different meaning to the intented behaviour? in which case it can still be changed to not do that? -- Damien _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
