grep -e "Using input driver" ~/.local/share/xorg/Xorg.0.log

Did some testing with MS-DOS edit instead of just DOSBox itself and it looks like autolock=true is not working at least not with Vmware and Ubuntu 18.10 Beta

When set to true then in Windowed mode then mouse is not captured in dosbox, works in fullscreen. Even if you go to fullscreen, capture the mouse and then switch back to windowed the mouse is still not captured.
When set to false then in Windowed mode mouse is captured, works in fullscreen.

In Vmware if the cursor is "too fast" when you switch to fullscreen you may need to set the SDL_MOUSE_RELATIVE=0 variable

For those having issues with the mouse cursor in DOSBox are you testing with DOSBox itself or testing with a program loaded in DOSBox?

I've tried installing the dosbox-sdl2 package suggested by @darkgamorck. In this case, "autolock = FALSE" has the same problem as before where the mouse cursor would jump out to desktop once it goes beyond a small rectangular area in DOSBox. When "autolock = TRUE", autolock appears to work in DOSBox's windowed mode again (yay!). However, I can't unlock the mouse with Ctrl-F10 anymore! This means that, in windowed mode, I can't switch to another program/task on my host system (alt-tab also doesn't work) unless I completely quite the program/game in DOSBox and exit DOSBox completely... So this is still problematic.

I also updated to the latest Xorg 1.20.2 that was just released, same problems.

DosFreak wrote:

Other things to try: export SDL_VIDEO_X11_DGAMOUSE=0 Change mouse driver in /etc/X11/xorg.conf SDL_MOUSE_RELATIVE=0 (or 1) […]
Show full quote

Other things to try:
export SDL_VIDEO_X11_DGAMOUSE=0
Change mouse driver in /etc/X11/xorg.conf
SDL_MOUSE_RELATIVE=0 (or 1)

For some reason, there is no /etc/X11/xorg.conf on my system. Should I manually create it? If so, what do I put in it?

As for SDL_VIDEO_X11_DGAMOUSE and SDL_MOUSE_RELATIVE, where do I set these things???

DosFreak wrote:

For those having issues with the mouse cursor in DOSBox are you testing with DOSBox itself or testing with a program loaded in DOSBox?

I tried by loading multiple games that need the mouse in DOSBox, they all had the same problem. Is there a way to test DOSBox directly without loading a program in it???

I'm glad you tested with SDL2 and provided results but go back the SDL1 ver and test the below and compare to the SDL2 ver:

So for the "small rectangular area in DOSBox what games does this happen in? Can you provide a screenshot showing the problem? (Can't replicate this)
So you're saying you can't use Ctrl+F10 in windowed mode but the mouse is captured? (I can replicate the CTRL+F10 issue but the mouse is not captured)
Can you use the other CTRL+FX keys in DOSBox? (I can)

These are SDL variables and the easiest way to test is to launch a terminal and type in, test each seperately :
export SDL_VIDEO_X11_DGAMOUSE=0
export SDL_MOUSE_RELATIVE=0

Can you post again what distro you're using, if using a physical machine or VM (If so what software version)?

With no game loaded in DOSBox you should be able to press CTRL+F10 in windowed mode or fullscreen and see the mouse disappear if it's capture or appear if it's not. If it's not captured then you should be able to drag the mouse cursor over any area of the DOSBox window.

DosFreak wrote:

I'm glad you tested with SDL2 and provided results but go back the SDL1 ver and test the below and compare to the SDL2 ver:

OK, please read on.

DosFreak wrote:

So for the "small rectangular area in DOSBox what games does this happen in? Can you provide a screenshot showing the problem? (Can't replicate this)

I've recorded a short GIF demonstrating this problem:

https://framapic.org/rL0D3anNlzzB/1xpDlbOP2bYF.gif

In this GIF, I have the classic DOS game Oregon Trail running in DOSBox. As you can see the in-game mouse cursor is moved up above the river, after which it immediately jumps out of the DOSBox window and into the host system's desktop (you can see the cursor icon change, too). Moving the in-game mouse cursor in the other three directions have the same problem (hence an invisible "rectangular" area in the DOSBox window that the mouse cursor appears in). This happens both on the physical machine and VM running DOSBox 0.74-2 with SDL1 installed from the Manjaro Linux primary repository (not AUR). The problem depicted in the GIF happens with "autolock = FALSE". If "autolock = TRUE", the mouse cursor is never captured to begin with even if I press Ctrl-F10.

Note: The VM is running Manjaro Linux like the physical system, but the VM is running in VirtualBox 5.2.20 hosted on a fully updated Red Hat Enterprise Linux 7.4 system.

DosFreak wrote:

So you're saying you can't use Ctrl+F10 in windowed mode but the mouse is captured? (I can replicate the CTRL+F10 issue but the mouse is not captured)

That's right. With "autolock = FALSE", the mouse is captured (only inside the small area as I described above with the GIF and text), but Ctrl+F10 doesn't do anything to lock or unlock it.

I also note that when "autolock = TRUE", Ctrl+F10 doesn't do anything either.

DosFreak wrote:

Can you use the other CTRL+FX keys in DOSBox? (I can)

No, the other Ctrl keys also don't work! For example, I tried to start the keymapper with no success. Again this is true both on the physical machine and in the VM.

DosFreak wrote:

These are SDL variables and the easiest way to test is to launch a terminal and type in, test each seperately :
export SDL_VIDEO_X11_DGAMOUSE=0
export SDL_MOUSE_RELATIVE=0

I tried the following on physical machine and VM:

1. Start a terminal running bash.

2. Ran the two export commands.

3. Started DOSBox via the command line.

4. I get the same problem shown in the GIF.

DosFreak wrote:

Can you post again what distro you're using, if using a physical machine or VM (If so what software version)?

As in indicated above, I am experiencing this in Manjaro Linux XFCE edition (fully updated with Xorg 1.20.2) running on both the physical machine and VM. The VM is running on VirtualBox 5.2.20 hosted on a fully updated Red Had Enterprise Linux 7.4 system.

DosFreak wrote:

With no game loaded in DOSBox you should be able to press CTRL+F10 in windowed mode or fullscreen and see the mouse disappear if it's capture or appear if it's not. If it's not captured then you should be able to drag the mouse cursor over any area of the DOSBox window.

Ctrl+F10 fails to capture the mouse with no game loaded. The host system's cursor moves over the DOSBox window as you predicted.

What a bewildering mystery! Hopefully we are collectively getting closer to a resolution. Thank you for your help and patience on this important matter.

Quick jump in:
If your OS(window manager) (host) captures the CTRL-FXX keys, then they won't arrive at the guest systems (VM) either...
Quick jump out.

So in my case it looks like as long as the DOSBox window is focus then pressing CTRL+F10 is seen by DOSBox. This is verified by putting the mouse cursor outside the DOSBox window while DOSBox is focused and pressing CTRL+F10. When CTRL+F10 is pressed then the mouse cursor will move to the outside of the dosbox window. Once the mouse is clicked then the cursor moves back to outside of the DOSBox window.

If you can't do the above then check your keyboard settings in your OS to verify nothing else is using those keys or remap the capture mouse keys to a different key.

So assuming everyone can verify the above then now we have an easy way to recreate the issue.

Since autolock=false works and true does not (at least as far as the cursor working inside the window not Ctrl+F10) I'm wondering if that helps pinpoint the issue.

So now SDL needs to be checked to see if it's working correctly or if it's Xorg.

Tested Scummvm today and didn't have this issue. (Use CTRL+M to lock mouse, if issues in a VM turn off relative using the SDL variable)

Also noticed that the arrow color still changes when the cursor is hovered over DOSBox:
Ubuntu 18.04 white cursor to black
Ubuntu 18.10 grey cursor to black

Mabye DOSBox doesn't think it has focus in window mode which is why Ctrl+F10 doesn't work (even if remapped)? The window does have focus though. Still looking.

Sooo...

When I run the SDL testcursor program on Ubuntu 18.04 it works.
When I run the SDL testcursor program on Ubuntu 18.04 I receive the error: Couldn't initialize SDL: No available video device.

HOWTO COMPILE SDL TEST PROGRAMS
sudo apt-get install mercurial
hg clone -u SDL-1.2 https://hg.libsdl.org/SDL SDL-1.2.15
cd SDL-1.2.15
./autogen.sh
./configure
sudo make install

cd test
./autogen.sh
./configure
sudo make

export SDL_VIDEODRIVER=X11 does not work

TEST PROGRAMS

Working on Ubuntu 18.04:
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for an ANSI C-conforming const... yes
checking for sdl-config... /usr/bin/sdl-config
checking for SDL - version >= 1.2.10... yes
checking how to run the C preprocessor... gcc -E
checking for X... libraries , headers
checking for OpenGL support... yes
configure: creating ./config.status
config.status: creating Makefile

NOT WORKING ON UBUNTU 18.10:
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for an ANSI C-conforming const... yes
checking for sdl-config... /usr/local/bin/sdl-config
checking for SDL - version >= 1.2.10... yes
checking how to run the C preprocessor... gcc -E
checking for X... libraries , headers
checking for OpenGL support... no
configure: creating ./config.status
config.status: creating Makefile

./configure on SDL itself

18.04

checking for getpagesize... yes
checking for directfb-config... no
checking for pkg-config... (cached) /usr/bin/pkg-config
checking for DirectFB 0.9.15 support... no
checking for PlayStation 2 GS support... no
checking for PlayStation 3 Cell support... no
checking for SVGAlib (1.4.0+) support... no
checking for libVGL support... no
checking for wscons support... no
checking for OpenGL (GLX) support... yes
checking for Linux 2.4 unified input interface... yes
checking for Touchscreen library support... no
checking for hid_init in -lusbhid... no
checking usb.h usability... no
checking usb.h presence... no

18.10
checking for DirectFB 0.9.15 support... no
checking for PlayStation 2 GS support... no
checking for PlayStation 3 Cell support... no
checking for SVGAlib (1.4.0+) support... no
checking for libVGL support... no
checking for wscons support... no
checking for OpenGL (GLX) support... no
checking for Linux 2.4 unified input interface... yes
checking for Touchscreen library support... no
checking for hid_init in -lusbhid... no

Config.log
configure:19870: result: no
configure:20250: checking for OpenGL (GLX) support
configure:20269: gcc -c -g -O2 -I./include -D_GNU_SOURCE=1 -DXTHREADS -I./include -D_GNU_SOURCE=1 conftest.c >&5
conftest.c:111:19: fatal error: GL/glu.h: No such file or directory
#include <GL/glu.h>
^~~~~~~~~~

Sudo apt-get install libglu1-mesa-dev fixed that

Still no go on running testcursor. Mabye missing X11 headers? checking the log....

Okay did a reinstall of 18.10 beta and installed these:
sudo apt-get install autoconf
sudo apt-get install gcc
sudo apt-get install libglu1-mesa-dev
sudo apt-get install make

Then compiled the SDL testcursor program and it works so mabye we can blame DOSBox now. 😀

DosFreak wrote:

Then compiled the SDL testcursor program and it works so mabye we can blame DOSBox now. 😀

Oh joy!

Do these lock the cursor as well ?, as that was what seemed broken from the clip posted before.

I don't see that functionality but I'll keep digging. Right now testcursor acts similary to autolock=false in DOSBox.

I noticed summvm by default doesn't lock the cursor but if you press Ctrl+M it then will lock it. Scummvm working fine (except for relative issue in a VM where you have to set the variable to disable relative otherwise mouse craziness...same as dosbox without this mouse capture issue)

Should OpenGL be required to lock the mouse cursor in X11? (gut feel is no.. but I don't know).

If you get rid of the OpenGL headers then compile ScummVM, can it still lock the cursor using "pure X11" calls instead of via some connection to OpenGL?

This is happening to me, also. You guys are well beyond me in development skills, but here's a little extra info in case it helps. Thanks for everything!

I recently performed a Kubuntu dist upgrade from 18.04 (Bionic) to 18.10 (Cosmic), using their do-dist-upgrade tool. Along with all the other changes (kernal, Xorg, mesa, etc), this upgraded DOSBOX from 0.74 to 0.74-2. The problem appeared right after the upgrade.

Also, a new configuration file was created (dosbox-0.74-2.conf), leaving the original dosbox-0.74.conf file unchanged. Notably, the settings in the original conf file did not transfer to the new file. I had to go in and replicate my changes. (I mention this as a clue; not as a complaint!)

Thanks again! If there's anything I can do to help, please let me know, keeping in mind that I'm pretty new at this...

Installed Lubuntu 18.10 today morning, Grab is working fine in 18.04 but not in 18.10. Presently tracing the program flow using gdb. Reached SDL_x11wm.c and investigating further...

Edit:

While stepping through the program flow, focus gets restricted to dosbox window as well as a disabled keyboard input after the following lines insides the function 'X11_GrabInputNoLock' in SDL_x11wm.c:
result = XGrabPointer(SDL_Display, SDL_Window, True, 0, GrabModeAsync, GrabModeAsync, SDL_Window, None, CurrentTime);
XGrabKeyboard(SDL_Display, WMwindow, True, GrabModeAsync, GrabModeAsync, CurrentTime);

Consequently, unable to switch to gdb for running bt or further step through. Nothing works except switching to tty and then force kill dosbox. Passing 'DEBUG_GRAB' to 'configure' while building SDL finally confirmed the 'double grab' for just a single click in case of 18.10 as opposed to 'single grab' in 18.04. Will update further if some more time could be managed at my end.

Somebody posted this:
https://nopaste.xyz/?9ef8029d2db7fc30#V2BCCHj … D9hLHwIQDtiFgg=

I don't have an affected system, but that locking was going wrong, was my best guess as well. Maybe somebody with an affected system can set a break point on the capture mouse routine and do backtraces to see where it is being called from. Maybe we can see if there is a logical error somewhere that could explain calling it twice.

That makes sense since now that I read that when I tried CTRL +F10 outside of the DOSBox window with DOSBox the focus and hit CTRL+F10 it doesn't immediately go to the DOSBox window it may take several tries. It did the same with the key remapped as well.
https://unix.stackexchange.com/questions/1462 … oard-mouse-in-x

All,

Worked with Qbix today on some tests. Still testing.

https://gitlab.freedesktop.org/xorg/xserver/commits/master
10 May 2018 Xserver 1.20
24 APR 2018 xserver 1.20 RC5
10 APR 2018 Xserver 1.20 RC4
02 APR 2018 Xserver 1.20 RC3 *
28 MAR 2018 Xserver 1.20 RC2