Hi Michael, On 4 March 2016 at 14:26, Michael Thayer <michael.tha...@oracle.com> wrote: > On 02.03.2016 18:43, Michael Thayer wrote: >> >> At present if modesetting ever fails to set a hardware cursor it >> switches back to a software one and stays that way until it is unloaded. >> The following patch should fix that. I say "should" because I had >> difficulties testing it - the cursor simply disappeared when it should >> have been rendering in software, though the debugger showed that >> pixman_image_composite() was getting called whenever the cursor moved, >> and my kernel driver was getting dirty rectangle information. My >> feeling is that the patch is correct and something else is broken. I >> have not investigated in depth in case some one else immediately has an >> idea. > > > My apologies for the noise. Without going into detail, the failure to show > the software cursor was due to the unclean way in which we (VirtualBox) > handle 3D acceleration, and nothing to do with the X server or modesetting. > I tested my patch again, taking this into account, and it worked as > expected. > Note that I'm not the person who wrote any of that code, although I do wonder... Why do we have to attempt/probe for hardware cursor everything time ? If the first invocation has failed it is reasonable to expect that all/most sequential ones will also fail.
Is the failed call to drmModeSetCursor/drmModeSetCursor2 an intentional behaviour, it suspiciously sound like a bug in the drm module (some along the line) to me. Which DRM module is that ? Regards, Emil _______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel