On Wed, Sep 28, 2016 at 12:05 PM, Michel Dänzer <[email protected]> wrote: > On 27/09/16 10:54 PM, Michael Thayer wrote: >> On 27.09.2016 12:06, Hans de Goede wrote: >>> On 23-09-16 10:20, Hans de Goede wrote: >>>> On 09/16/2016 06:52 PM, Michael Thayer wrote: >>>>> When the X server asks us to load a hardware cursor, that >>>>> request is always followed up by a request to show it if we >>>>> report success, or to hide it if we report failure. Therefore >>>>> it makes no sense to suppress the request if the cursor is not >>>>> currently visible. >>>> >>>> Ok, I've just spend the last half hour tracing (using grep) all >>>> callers of load_cursor_argb_check and you're right, either the >>>> cursor is already visible (XRecolorCursor does this), or it will >>>> get shown directly after the drmmode_load_cursor_argb_check() >>>> call. >>> >>> And despite double checking I still missed a trouble-some scenario >>> here. >>> >>> If we've 2 monitors active, then as the cursor moves from one to >>> the other show()/hide() gets called on them. >>> >>> If the cursor then changes load_cursor_argb_check() gets called on >>> all active crtc-s causing the cursor to now be shown on both >>> monitors at the same time, not good. >> >> Indeed. Looking at other ways of handling this, but the whole thing >> is somewhat tricky due to the differences in how the X server and >> the kernel handle cursor setting. I think that the most correct way >> to fix this would be to allow show and hide cursor operations to >> return failure too, but that would be a very invasive change. A less >> invasive but also less clean change would be to extend the first time >> hack to also trigger if a load happens when the cursor is hidden >> globally (or perhaps better, if it is hidden on all crtc-s at the >> time of the load). For VirtualBox, if a cursor load succeeds on one >> crtc we know it will succeed on any, but I wonder whether that would >> apply to other users. I also wonder which other potential users >> there are. So far most other people use their own DDX instead of >> modesetting. Alexandre, did you say this was an issue for Tegra? > > IIRC the issue with Tegra is that it can't use the HW cursor at all for > some reason, not that it sometimes can and sometimes can't.
Correct. Tegra cannot manage the cursor format that modesetting is trying to use, so the MODE_SETTING ioctl fails and we fall back to software cursor. _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
