On 09/11/17 03:06 PM, Hans de Goede wrote: > On 09-11-17 02:34, Alex Goins wrote: >> On Wed, 8 Nov 2017, Hans de Goede wrote: >> >>>> and that would be preferable to using the server's software cursor (due >>>> to the fact that it's unsynchronzied by OpenGL rendering to the root >>>> window, it can cause corruption with certain compositors). >>> >>> Frankly, that sounds like an issue with your direct rendering >>> infrastructure. We used to have the same issue with DRI1, but no more >>> with DRI2/DRI3 (we still have an intermittent cursor flickering issue >>> though, but not corruption). >> >> Really? I observe the same issue using mesa + modesetting + glamor + >> i915 + >> mutter. Dragging a window around with software cursor produces a >> square of >> corruption around the cursor. >> >> In any case, I would like some means to bring back the pre-7b634067 >> functionality. In situations such as using UDL as a slave, it appears >> as a >> regression. An opt-in mechanism for drivers that support master-driven >> cursor is >> acceptable, I think. I'll follow up with a new patch set implementing the >> feedback so far if you agree. > > I'll leave further discussion of this between you and Michel Däzner. FWIW > I do believe that Michel's suggestion to implement the master-driven cursor > overlay in some generic place so it works with all the drivers is a better > solution then allowing drivers to opt-out.
Unfortunately, that's not really possible, because at least xf86-video-intel doesn't use PixmapSyncDirtyHelper. So even if that is made to handle this transparently, there needs to be an opt-in mechanism. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
