Mouse capture not working in Linux with Xorg 1.20.x

[DosFreak]

Need to check
xwininfo
xev -id windowid

Ubuntu 18.04
Only keypress and keyrelease events are shown

Ubuntu 18.10
FocusIn,FocusOut, keymapnotify in addition to keypress and keyrelease events are shown

[DosFreak]

Installed 18.10 (instead of the beta) with all updates and same issue

sudo X -version
X.Org X Server 1.20.1

Gnome 3.30.1

echo $XDG_SESSION_TYPE shows X11

[gandhig]

Due to the XGrabKeyboard function in SDL_x11wm.c, using gdb has become difficult in finding out the reason for the double call of GFX_CaptureMouse() in Ubuntu 18.10. Looking into alternates...

Edit: Thanks for the heads-up and inputs, DosFreak and Qbix...will attempt to troubleshoot further into the issue, whenever time could be managed.

[DosFreak]

Due to the XGrabKeyboard function in SDL_x11wm.c, using gdb has become difficult in finding out the reason for the double call of GFX_CaptureMouse() in Ubuntu 18.10. Looking into alternates...

Found this yesterday, don't know if it's relevant:
https://gitlab.freedesktop.org/xorg/xse ... c79bc00f6a

Going to look into compiling DOSBox with SDL2 to see if same issue or not, think someone previously in this thread stated SDL2 worked on their system whereas SDL1 did not. I've tried with SDL post 1.2.15 release (as of a couple of months ago) and same issue.

[DosFreak]

This was submitted to the SDL 1.2 branch on Aug 28, don't see anything else commited that may apply (Think my last SDL source download was in May):
https://github.com/spurious/SDL-mirror/ ... 9c4f4f040e
https://github.com/spurious/SDL-mirror/ ... /SDL12/src
https://hg.libsdl.org/SDL/rev/0f469a8b5110

[Qbix]

These are some preliminary results:

what we yesterday found (although more testing is needed), is that xorg1.20 +sdl combo gives spurious SDL_ActiveEvents when the mouse is in a locked state . Even when I skip the one that is generated when locking the mouse, more are generated as soon as you stop moving the mouse. (the events are for SDL_APPINPUTFOCUS and it is lost and gained within the same millisecond). DOSBox decides to release the mouse (unlock) when the APPINPUTFOCUS is lost, in order to give you your mouse cursor back when dosbox is not the application receiving input.

Need to determine if they are are totally unreliable/random, or that they come always in pairs and that we could have some sort of timer( if focus lost >10 ms, then consider it real, else fake) or that we have to ignore it all together on linux now..

Those events are generated for probably a reason, but I was focussing at why dosbox decides to unlock the mouse. (at this stage).

Ghandig, maybe it makes sense to add logging to the sdl_x11 code itself, as as you said, debugging is tricky.

[DosFreak]

It looks like there were kind of similar issues with SDL2 in the past:
https://hg.libsdl.org/SDL/rev/50b8ed4e6266

[gandhig]

Well, commenting out the XGrabKeyboard function call for troubleshooting purpose...fixed the capture issue somehow . Reconfirmed...as the issue came back after re-enabling the commented out function.

Universe does work in mysterious ways .

Will continue to work on this later today. DosFreak, could you please confirm this from your end too, when you find time? Happy debugging!
Edit: bug

[DosFreak]

Due to the XGrabKeyboard function in SDL_x11wm.c, using gdb has become difficult in finding out the reason for the double call of GFX_CaptureMouse() in Ubuntu 18.10. Looking into alternates...

Found this yesterday, don't know if it's relevant:
https://gitlab.freedesktop.org/xorg/xse ... c79bc00f6a

Going to look into compiling DOSBox with SDL2 to see if same issue or not, think someone previously in this thread stated SDL2 worked on their system whereas SDL1 did not. I've tried with SDL post 1.2.15 release (as of a couple of months ago) and same issue.

So if with "if (from == to)" DOSBox was fine and then with "if (from == to && mode != NotifyGrab && mode != NotifyUngrab" DOSBox loses input I'm wondering if that should be changed to an OR instead of an AND to account for programs that grab input inside of the application (SDL) because currently it looks like with the change it returns focus to SDL (Verified since the cursor stays in the Window with correct cursor) . Either that or change the timing in DOSBox or filter out the XGrabKeyboard events? (Looks like ghandig sort of proved that above)

Unfortunately I don't know how to compile and test x.org.....SDL yes xorg no.

Here's the tightvnc workaround: https://github.com/void-linux/void-pack ... diff=split

[Qbix]

This is a bit a similar to what I have send to DOSFreak, except you reported back that it got released when you stopped moving the mouse as well.
Or maybe my code had a bug.

[Qbix]

When disabling the mouse unlocking. (attached simple patch for that), things "work", but a lot more code is run than just the unlocking of the mouse (when those events happen). hence I want to get to the bottom of this, as this would screw up auto cycles (a little) and such as well.

This is a pretty interesting piece of log from DosFreaks testing setup.

Code: Select all

Event 4 polled at 14141
Event 4 polled at 14148
Event 4 polled at 14157
Event 4 polled at 14165
Event 4 polled at 14174
Event 1 polled at 15678
ActiveEvent state 2 gain 0 mouse locked 1
Event 1 polled at 15678
ActiveEvent state 2 gain 1 mouse locked 1
Event 1 polled at 17179
ActiveEvent state 2 gain 0 mouse locked 1
Event 1 polled at 17179
ActiveEvent state 2 gain 1 mouse locked 1
Event 1 polled at 18680
ActiveEvent state 2 gain 0 mouse locked 1
Event 1 polled at 18680
ActiveEvent state 2 gain 1 mouse locked 1
Event 1 polled at 20185
ActiveEvent state 2 gain 0 mouse locked 1
Event 1 polled at 20185
ActiveEvent state 2 gain 1 mouse locked 1
Event 1 polled at 21686
ActiveEvent state 2 gain 0 mouse locked 1
Event 1 polled at 21686
ActiveEvent state 2 gain 1 mouse locked 1
Event 1 polled at 23188
ActiveEvent state 2 gain 0 mouse locked 1
Event 1 polled at 23188
ActiveEvent state 2 gain 1 mouse locked 1
Event 1 polled at 24690
ActiveEvent state 2 gain 0 mouse locked 1
Event 1 polled at 24690
ActiveEvent state 2 gain 1 mouse locked 1
Event 4 polled at 24867
Event 4 polled at 24877
Event 4 polled at 24885
Event 4 polled at 24894
Event 4 polled at 24904
Event 4 polled at 24912
Event 4 polled at 24920


event 4 is mouse moving.
So when not moving the mouse, a pair of events is being generated every 1.5 seconds.

[DosFreak]

https://www.libsdl.org/release/SDL-1.2. ... event.html
https://gitlab.freedesktop.org/xorg/xse ... terleave.c

dix: always send focus event on grab change

Code: Select all

/**
 * Figure out if focus events are necessary and send them to the
 * appropriate windows.
 *
 * @param from Window the focus moved out of.
 * @param to Window the focus moved into.
 */
void
DoFocusEvents(DeviceIntPtr pDev, WindowPtr from, WindowPtr to, int mode)
{
    if (!IsKeyboardDevice(pDev))
        return;

    if (from == to && mode != NotifyGrab && mode != NotifyUngrab)
        return;

    CoreFocusEvents(pDev, from, to, mode);
    DeviceFocusEvents(pDev, from, to, mode);
}


When using xev -id on dosbox with the mouse captured but not used I'm seeing a constant FocusOut NotifyGrab and then FocusIn NotifyGrab events with autolock=true but not with autlock=false

SDL itself shows Activeevent gain and loss when mouse cursor moved into and out of the DOSBox window as normal.

Since this: https://bbs.archlinux.org/viewtopic.php?id=237587 was reported in May and the commit in April it's looking like that that's the cause.

[DosFreak]

Check this out:
https://xorg-devel.x.narkive.com/mSi2zt ... rab-change

Code: Select all

c67f2eac5651 ("dix: always send focus event on grab change") made dix
always sent events when it's a NotifyGrab or NotifyUngrab, even if
from == to, because 'from' can just come from a previous XSetInputFocus
call.

However, when an application calls XGrabKeyboard several times on
the same window, we are now sending spurious FocusOut+FocusIn with
NotifyGrab, even if the grab does not actually change. This makes screen
readers for blind people spuriously emit activity events which disturb
screen reading workflow when e.g. switching between menus.

This commit avoids calling DoFocusEvents in that precise case, i.e. when
oldWin is a previous grab and the new grab is the same window.

Signed-off-by: Samuel Thibault <***@ens-lyon.org>

Index: xorg-server-1.19.2/dix/events.c
===================================================================
--- xorg-server-1.19.2.orig/dix/events.c
+++ xorg-server-1.19.2/dix/events.c
@@ -1530,7 +1530,9 @@ ActivatePointerGrab(DeviceIntPtr mouse,
mouse->spriteInfo->sprite->hotPhys.y = 0;
ConfineCursorToWindow(mouse, grab->confineTo, FALSE, TRUE);
}
- DoEnterLeaveEvents(mouse, mouse->id, oldWin, grab->window, NotifyGrab);
+ if (! (grabinfo->grab && oldWin == grabinfo->grab->window
+   && oldWin == grab->window))
+ DoEnterLeaveEvents(mouse, mouse->id, oldWin, grab->window, NotifyGrab);
mouse->valuator->motionHintWindow = NullWindow;
if (syncEvents.playingEvents)
grabinfo->grabTime = syncEvents.time;
@@ -1640,7 +1642,9 @@ ActivateKeyboardGrab(DeviceIntPtr keybd,
oldWin = keybd->focus->win;
if (keybd->valuator)
keybd->valuator->motionHintWindow = NullWindow;
- if (oldWin)
+ if (oldWin &&
+   ! (grabinfo->grab && oldWin == grabinfo->grab->window
+   && oldWin == grab->window))
DoFocusEvents(keybd, oldWin, grab->window, NotifyGrab);
if (syncEvents.playingEvents)
grabinfo->grabTime = syncEvents.time;

So need to figure out how to test with this commit (Guess bug a distro to provide the update) and if still has an issue then open bug report with them or mabye bug the guy that submitted this and have him test DOSBox on his build.

As always DOSBox is perfect.

[Qbix]

There is another layer between DOSBox and Xorg, but this does sound similar to at least the paired events in idle mode.
Not sure if this will fix focusloss on locking problem

[DosFreak]

Sent an email to Samuel Thibault concerning https://xorg-devel.x.narkive.com/mSi2zt ... rab-change about xorg testing

[gandhig]

This is turning out to be a thing that has the potential of a minute possibility of getting on the nerve...XGrabKeyboard function call. Despite enabling logging to know about the result of the function call, nothing gets printed, neither by using printf nor fprintf. Enabling the macro ‘DEBUG_ERROR’ and trying to make use of SDL_GetError function also didn't accomplish anything. Maybe... missing something, so obvious. To be continued in the weekend with more concentration as well as from a more relaxed state...

[DosFreak]

Here's his response:

Sam,

I it looks like this commit broke grab for DOSBox as well, see this thread:
viewtopic.php?f=31&t=62703&hilit=xorg#p702314

To recreate:
1. Have a system with Xorg 1.20 (works fine when using 1.19)
2. Download, install and execute DOSBox
3. Launch MS-DOS edit.com or any program that needs a mouse
4. Press CTRL+F10. The mouse normally should be captured but cannot with 1.20. SDL sees the mouse just fine and gets gain and loss ActiveEvents but grab events inside the DOSBox window do not work.

Basically seeing the same grab focusin, focusout events as described in the latest post below:
https://xorg-devel.x.narkive.com/mSi2zt ... rab-change

Unfortunately I don't know how to test XORG before and after that commit or test it with the fix the code in the latest post without using the releases that come with the distro.

Can you describe how to recreate a test environment with xorg and/or verify that DOSBox works with the latest fix you described?

Thanks

Hello,

Any reason not to follow this up on xorg-devel? Doing all these
discussions privately means other Xorg hackers can't help, can't know
ins and outs, etc.

Dos Freak, le jeu. 08 nov. 2018 10:31:46 +0000, a ecrit:
> I it looks like this commit broke grab for DOSBox as well, see this thread:
> viewtopic.php?f=31&t=62703&hilit=xorg#p702314

I can confirm that the change is what makes dosbox unable to grab the
pointer.

> SDL sees the mouse just fine and gets gain and loss ActiveEvents but grab
> events inside the DOSBox window do not work.
>
> Basically seeing the same grab focusin, focusout events as described in the
> latest post below:
> https://xorg-devel.x.narkive.com/mSi2ztpr/
> patch-xserver-dix-always-send-focus-event-on-grab-change

I can however also confirm that the precise event that this change was
meant to make the Xorg server to send is also exactly the one which
seems to be disturbing dosbox: I printed values in ActivateKeyboardGrab,
there is a first call with oldWin != grab->window (thus the event
gets through in both 1.19 and 1.20), and a second call with oldWin ==
grab->window == keybd->focus->win (thus the event was not emitted in
1.19 but is emitted in 1.20), but we also have grabinfo->grab == NULL,
so it's really a new grab, and thus we really do want to send the event
in that case, and SDL _has_ to cope with that.

> Unfortunately I don't know how to [...] test it with the fix the code

Hide original message

> in the latest post without using the releases that come with the
> distro.


I tried it, and the fix posted on October 30th does not fix dosbox,
precisely because grabinfo->grab == NULL and so we do want the event in
that case.

Samuel

[DosFreak]

gandhig, are you using the SDL 1.2.15 release or the latest 1.2 code?

Think there's a thread on the SDL forum of talk about consolidating all the 1.2 fixes since distros are using their own various fixes and I do see commits for 1.2 occasionally.

https://bugzilla.libsdl.org/
https://discourse.libsdl.org/c/sdl-development

[gandhig]

gandhig, are you using the SDL 1.2.15 release or the latest 1.2 code?

Downloaded by means of "hg clone -u SDL-1.2 https://hg.libsdl.org/SDL SDL-1.2.15"

Output log:
requesting all changes
adding changesets
adding manifests
adding file changes
added 12404 changesets with 49398 changes to 5140 files (+1 heads)
new changesets 74212992fb08:a4d730631698
updating to branch SDL-1.2
1378 files updated, 0 files merged, 0 files removed, 0 files unresolved

[gandhig]

Trying to make sense of the whole grabbing business in the world of Xorg/SDL/DOSBox...
Currently intaking, digesting and assimilating this