On Mon, Oct 07, 2013 at 03:29:15PM +0300, Siarhei Siamashka wrote: > On Mon, 7 Oct 2013 11:32:50 +0100 > Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx> wrote: > > However, what you're suggesting is dangerous. What do you do when you're > > presented with a cursor which is 64x64 ? Do you: > > > > (a) not display it > > (b) crash the X server > > > > There isn't a fallback to using software cursors available in the X server > > because there's no error reporting for a failed hardware cursor update. > > Hmm, maybe I'm missing something, but doesn't returning FALSE from > UseHWCursorARGB just make the X server fallback to using a software > cursor? > > https://github.com/ssvb/xf86-video-fbturbo/blob/689c08256555/src/sunxi_disp_hwcursor.c#L72 > > I'm just doing this. And also have hooks to notify the DRI2 code about > the status of the cursor. In the case if the hardware cursor is not > enabled, hardware overlays can't be safely used with the software > cursor and we need to fallback to CPU/GPU copy instead of zero-copy > buffers swapping. > > And I fully agree that it is the responsibility of the kernel to expose > as much of the hardware capabilities as possible (without compromising > reliability and/or security). If you wish to go in below the level presented by hw/xfree86/modes/xf86Cursors.c (as you are doing), then yes you can do this, and it's something which maybe should be looked into. You have a good reason to do this (due to your hardware cursor being incompatible with overlays). We have no such restriction - the only issue here is the "odd" size of cursors. Practically, choosing one or other of 64x32 or 32x64 works fine for the cases I've seen. I haven't seen any cursors which are 64x64 yet. I'm not saying they don't exist though! I can imagine that some accessibility options might want to display a large cursor. Now, the way I handle this is that the kernel allows _either_ a (1 to 32)x(1 to 64) or (1 to 64)x(1 to 32) cursor. Both width and height larger than 32 gets rejected with -EINVAL: + /* maximum size is 64x32 or 32x64 */ + if (w > 64 || h > 64 || (w > 32 && h > 32)) + return -ENOMEM; which is quite reasonable for this hardware. However, there is no way to export this from DRM - adding maximum cursor size properties wouldn't really represent this. The only question is whether DRM should export some capabilities to indicate what's possible with the cursor, so that X knows about this quirk of this hardware. Overall, I suspect that it's just rare and not worth the effort. I think it's just easier to pick one of these and stick with it, and if we happen to encounter a cursor larger than our chosen dimentions, XFree86 will already automatically fall back to s/w cursor. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
