VOGONS

Common searches


Reply 40 of 70, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

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

How To Ask Questions The Smart Way
Make your games work offline

Reply 41 of 70, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

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

How To Ask Questions The Smart Way
Make your games work offline

Reply 42 of 70, by gandhig

User metadata
Rank Member
Rank
Member

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.

Last edited by gandhig on 2018-11-01, 01:06. Edited 1 time in total.

Dosbox SVN r4019 + savestates Build (Alpha)
1st thread & the only one related to the forum(?)...warning about modern-retro combo
Dead, but, Personal Favourite
Replacement for Candy Crush...Train the Brain

Reply 43 of 70, by DosFreak

User metadata
Rank l33t++
Rank
l33t++
gandhig wrote:

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/xserver/c … accb7c79bc00f6a

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.

How To Ask Questions The Smart Way
Make your games work offline

Reply 44 of 70, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

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/commit … 6014d9c4f4f040e
https://github.com/spurious/SDL-mirror/commits/SDL12/src
https://hg.libsdl.org/SDL/rev/0f469a8b5110

How To Ask Questions The Smart Way
Make your games work offline

Reply 45 of 70, by Qbix

User metadata
Rank DOSBox Author
Rank
DOSBox Author

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.

Water flows down the stream
How to ask questions the smart way!

Reply 46 of 70, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

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

How To Ask Questions The Smart Way
Make your games work offline

Reply 47 of 70, by gandhig

User metadata
Rank Member
Rank
Member

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

Dosbox SVN r4019 + savestates Build (Alpha)
1st thread & the only one related to the forum(?)...warning about modern-retro combo
Dead, but, Personal Favourite
Replacement for Candy Crush...Train the Brain

Reply 48 of 70, by DosFreak

User metadata
Rank l33t++
Rank
l33t++
DosFreak wrote:
Found this yesterday, don't know if it's relevant: https://gitlab.freedesktop.org/xorg/xserver/c … accb7c79bc00f6a […]
Show full quote
gandhig wrote:

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/xserver/c … accb7c79bc00f6a

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-packages/c … f066?diff=split

How To Ask Questions The Smart Way
Make your games work offline

Reply 49 of 70, by Qbix

User metadata
Rank DOSBox Author
Rank
DOSBox Author

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.

Water flows down the stream
How to ask questions the smart way!

Reply 50 of 70, by Qbix

User metadata
Rank DOSBox Author
Rank
DOSBox Author

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.

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.

Attachments

  • Filename
    DF4.patch
    File size
    1.46 KiB
    Downloads
    161 downloads
    File comment
    simple patch for logging
    File license
    Fair use/fair dealing exception

Water flows down the stream
How to ask questions the smart way!

Reply 51 of 70, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

https://www.libsdl.org/release/SDL-1.2.15/doc … ctiveevent.html
https://gitlab.freedesktop.org/xorg/xserver/b … ix/enterleave.c

dix: always send focus event on grab change

/**
* 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.

How To Ask Questions The Smart Way
Make your games work offline

Reply 52 of 70, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

Check this out:
https://xorg-devel.x.narkive.com/mSi2ztpr/pat … -on-grab-change

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.

How To Ask Questions The Smart Way
Make your games work offline

Reply 53 of 70, by Qbix

User metadata
Rank DOSBox Author
Rank
DOSBox Author

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

Water flows down the stream
How to ask questions the smart way!

Reply 54 of 70, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

Sent an email to Samuel Thibault concerning https://xorg-devel.x.narkive.com/mSi2ztpr/pat … -on-grab-change about xorg testing

How To Ask Questions The Smart Way
Make your games work offline

Reply 55 of 70, by gandhig

User metadata
Rank Member
Rank
Member

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...

Dosbox SVN r4019 + savestates Build (Alpha)
1st thread & the only one related to the forum(?)...warning about modern-retro combo
Dead, but, Personal Favourite
Replacement for Candy Crush...Train the Brain

Reply 56 of 70, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

Here's his response:

Sam, […]
Show full quote

Sam,

I it looks like this commit broke grab for DOSBox as well, see this thread:
Mouse capture not working in Linux with Xorg 1.20.x

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/mSi2ztpr/pat … -on-grab-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, […]
Show full quote

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:
> Mouse capture not working in Linux with Xorg 1.20.x

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

How To Ask Questions The Smart Way
Make your games work offline

Reply 57 of 70, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

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

How To Ask Questions The Smart Way
Make your games work offline

Reply 58 of 70, by gandhig

User metadata
Rank Member
Rank
Member
DosFreak wrote:

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

Dosbox SVN r4019 + savestates Build (Alpha)
1st thread & the only one related to the forum(?)...warning about modern-retro combo
Dead, but, Personal Favourite
Replacement for Candy Crush...Train the Brain

Reply 59 of 70, by gandhig

User metadata
Rank Member
Rank
Member

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

Last edited by gandhig on 2018-11-21, 11:36. Edited 3 times in total.

Dosbox SVN r4019 + savestates Build (Alpha)
1st thread & the only one related to the forum(?)...warning about modern-retro combo
Dead, but, Personal Favourite
Replacement for Candy Crush...Train the Brain