On 09/11/17 02:34 AM, Alex Goins wrote: > On Wed, 8 Nov 2017, Michel Dänzer wrote: > >>> Change 7b634067 added HW cursor support for PRIME by removing the >>> pixmap_dirty_list check from xf86CursorSetCursor() and making the requisite >>> cursor functions set/check the cursor both on master and slave. >>> >>> However, before this change, drivers that did not make use of >>> pixmap_dirty_list >>> to implement PRIME master were able to pass this check. That may have been a >>> bug, but in effect it allowed hardware cursor to be enabled with PRIME, >>> where >>> the master composites the cursor into the shared pixmap. >>> >>> Naturally, the slave driving an actual hardware cursor is preferable to the >>> master compositing a cursor into the shared pixmap, but there are certain >>> situations where the slave cannot drive a hardware cursor (certain DRM >>> drivers, >>> or when used with a transform). In these cases the master may still be >>> capable >>> of compositing a cursor, >> >> How and where exactly would this "compositing the cursor into the shared >> pixmap" happen? Looks like this is just left for the master screen >> driver to handle? If so, there probably needs to be a mechanism for the >> master screen driver to opt into this. > > Yes, it's just left for the master screen the handle as if it were a hardware > cursor.
Please provide an implementation of this as part of the series. In order of my preference: 1. Make PixmapSyncDirtyHelper handle it automagically. 2. Add a helper function that drivers can call after PixmapSyncDirtyHelper. I'm asking this to avoid ending up in a similar situation as with the PRIME synchronization functionality, where it seems like the modesetting driver still can't use it with itself as the peer. >>> 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. That's a modesetting driver bug. It allows page flipping with SW cursor, but that can't work correctly. At least xf86-video-amdgpu/ati don't have this issue. -- 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
