yeah i think it started with Xserver 1.20. Not sure what they changed...

Why so vague on what distro you're using?
Are these computers using multiple monitors?

More detailed report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900717

Looks like downgrading xorg from 1.20.0-2 to 1.19.6+13 fixes it.
https://bbs.archlinux.org/viewtopic.php?id=237587

Possibly bug with mouse driver?
https://bugs.gentoo.org/658130

Running a rebuild worked here: https://forums.gentoo.org/viewtopic-t-1077950 … c-start-25.html

Looks like it works fine with Ubuntu 18.04.1 w/ Xorg 1.19.6 fully updated as of today . This is using my build w/ SDL 1.2.15.

Xorg 1.20 Announcement
https://lists.x.org/archives/xorg-announce/20 … May/002893.html

Xorg 1.20.1 Announcement
https://lists.x.org/archives/xorg-announce/20 … ust/002912.html

Diff
https://fossies.org/diffs/xorg-server/1.19.6_vs_1.20.0/

Changelog
https://fossies.org/linux/xorg-server/ChangeLog
Looks like alot of cursor changes around Feb 2018.

Distribution is openSUSE Tumbleweed; I need the latest X server to be able to run my Radeon RX580 card with HDMI audio output, so downgrading is not an option for me.

Can you see if setting autolock=false fixes the issue?
Also does the issue only occur when DOSBox is in a window?

Interesting:
- Fullscreen is OK, mouse is working in DOS
- Also, autolock=false is OK for windowed Dosbox. Sounds counterintuitive. In fact, the mouse behaves as if there were a seamless pointer integration: It is not captured, but when moved across the Dosbox window, the mouse is automatically captured, then released when the pointer leaves the window again (no use of Ctrl-F10).

Thanks

I'm going to try to check out xorg 1.20 this week.

Installing Ubuntu 18.10 Beta to do some testing:

dpkg -l |grep xserver-xorg-core
xserver-xorg-core 2:1.20.1-3ubuntu2

So far these work:
DOSBox 0.74-2-1 in the Ubuntu repo (links against SDL1.2 AND SDL2 for some reason....)
My compiled ver of DOSBox SVN from a couple of months ago (SDL 1.2.15)
OpenSuse DOSBox 0.74.2 https://software.opensuse.org/package/dosbox

Works fine in Tumbleweed with a fresh install.

OpenSuse
rpm -qa |grep xorg-x11-server
xorg-x11-server-wayland-1.20.1-1.1.x86_64
xorg-x11-server-1.20.1-1.1.x86_64

DOSBox 0.74-2 working in OpenSuse as well.

Mabye when xorg gets upgraded something is corrupted or not upgraded during the upgrade?

Op, can you try a fresh install on another computer or VM?

Just fyi, the thing which makes newer AMDGPU driven cards work with HDMI audio is having DC or Display Code enabled. And further fyi, Display Code’s functionality was not feature complete compared to the older drivers, such as missing DVI-D Dual Link support, until that extra functionality was added by the 4.18 kernel release. And of course, since all of that is new features and not security or bugfixes, it won’t he backported into the 4.15 kernel that Ubuntu LTS is sporting by default.

I’d be interested in testing this, maybe, but I guess I really don’t want to install out of repository versions of Xorg.

I am experiencing the same problem as originally reported by @mizapf. This is happenning on a fully updated Manjaro Linux system (with Intel integrated graphics) with Linux kernel 4.14 and Xorg 1.20+.

I tried setting "autolock = FALSE" when running Dosbox in windowed mode, but it doesn't completely solve the problem. In my case, when I move my desktop mouse cursor into the Dosbox window, the cursor would appear in the Dosbox program somewhere close to the center of the window. If I move the within-Dosbox cursor out of a small rectangular area inside the window, the cursor would jump out of the window and back to my desktop. What this means is that there is essentially a large, thick border within my Dosbox window where the cursor is unable to reach. Obviously this breaks the majority of Dos programs/games that I'd like to run in Dosbox.

Is there more I can do to troubleshoot this issue? Will this be addressed in a future Dosbox release? Thank you for your help on this matter.

Next thing I'd like to test is a system with < Xorg 1.20 that's upgraded to 1.20.x because I haven't seen the issue on a fresh install with Xorg 1.20.
If no issue then mabye something in Xorg corrupted rarely when users update?
Are there any programs that do anything with windowed programs or focus loaded?
Mabye issue with SDL dynamic link library that DOSBox is loading on an upgraded system vs fresh?

I know with SDL 1.2.14+ in Windows 9x I had a similar issue with DOSBox but it is actually an issue with the commit in SDL that breaks DirectInput in 9x. In that case when the mouse was in non-relative mode hovered over the DOSBox window then it would act like molasses and be difficult to remove from the window whereas in this case you state it jumps out of the DOSBox window so seems like SDL loses track of the coordinates of the window?

Nothing can be addressed until we can replicate the issue and identify what's causing it. So far doesn't seem like a DOSBox issue to me.

OK, I did a quick test which provides a new data point to this mystery:

DosFreak wrote:

because I haven't seen the issue on a fresh install with Xorg 1.20.

I installed a completely fresh Manjaro Linux (in a virtual machine) which includes xorg 1.20.1 out-of-the-box (no updates needed). However, even in this case I experienced the exact same problem I had in DOSBox (as described in my previous post) where when "autolock = FALSE" the mouse cursor only works in a small area in the Dosbox window (otherwise the cursor jumps out to the desktop), and when "autolock = TRUE" the mouse just isn't captured at all.

DosFreak wrote:

Nothing can be addressed until we can replicate the issue and identify what's causing it. So far doesn't seem like a DOSBox issue to me.

I don't know if what I did counts as a good-enough replication of the issue. Let me know if there's something else I can check (SDL versions?). In any case it'll be good to know whether it is a DOSBox problem...

Guess I'll be downloading yet another distro heh

Might be a good idea to compare Xorg configurationfiles as well

1. Downloaded manjaro-xfce-17.1.12-stable-x86_64
2. Installed in Vmware
3. Rebooted VM
4. Installed DOSBox 0.74-2 from Add/Remove Software
5. No issues.

Sudo X -version

Xorg 1.20.1

Wonder if it's a diff between Xorg mouse drivers. Did you use vmware or virtualbox?
Also looks like Manjaro installs the xf86-video-vmware driver

Can you check the contents of /var/log/Xorg.0.log on the for the physical system and VM? There may be multiple xorg logs in that folder.

DosFreak wrote:

1. Downloaded manjaro-xfce-17.1.12-stable-x86_64

That's the same image I used.

DosFreak wrote:

Did you use vmware or virtualbox?

I used the latest Virtualbox 5.2.18. I don't have access to vmware.

DosFreak wrote:

Can you check the contents of /var/log/Xorg.0.log on the for the physical system and VM? There may be multiple xorg logs in that folder.

Here is the /var/log/Xorg.0.log for the virtual machine:

https://framabin.org/p/?b23ec55a5b4e0e7c#w/1G … xGVGRwgXyHba/I=

Here is the same log for the physical machine:

https://framabin.org/p/?399a8177ffcf9c62#y4Vl … NCmOqKYk6Xt61o=

I don't know how to intepret those logs, though. Any guidance would be appreciated.

Weird stuff going on in the second log. Why would a camera be detected as a keyboard? Also does the physical machine have a different input device like a touchpad? In the log it's losing input events over and over is the computer too busy?
The virtualbox logs detect a USB tablet as a mouse as well? Mabye see if you can disable the USB tablet BS. https://www.virtualbox.org/manual/ch03.html
I'm wondering if you could try dosbox more on the VM to see if you can get a larger log, so far the physical machine log looks more suspicious
Also detach any USB devices to the guest

I guess I'll see if I can screw up my system by installing virtualbox bleh.

So installed the same Manjaro iso on Virtualbox v5.2.18. Same procedure as described above for vmware. No issues.

FWIW, I can replicate this issue on multiple Linux boxes. So far the only thing I've found that can work around it is to install dosbox-sdl2 (the name of the AUR package in Arch and its derivatives): https://aur.archlinux.org/packages/dosbox-sdl2/

That resolves the issue for me completely.

Can you replicate it so that someone who can't can because I can't.....heh

Assuming we all use the same ver of virtualbox and the same distro and the same testing procedure and some have the issue and some do not then something on the host or a driver issue may be causing the problem.

Guess the next thing to try would be sharing VMs.....

An update to Xorg was released yesterday.

Thanks for testing with SDL2.

Some more hints:
https://www.linuxquestions.org/questions/show … d.php?p=5913140

So somehow SDL w/ Xorg 1.20 not tracking mouse location correctly in windowed mode. Mabye unable to track mouse coordinates in the Window so dumps the cursor back to the desktop?

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