747-400 Precision Simulator: Mouse can only move down and to the right since 0.80.0

[kqr]

Are you using the latest Dosbox-Staging Version?

• [X] I have checked releases and am using the latest release.

Different version than latest?

0.82.0

What Operating System are you using?

Linux x86_64

If Other OS, please describe

Fedora 41 running in a Hyper-V virtual machine with enhanced session mode (using xrdp) under Windows 11

Relevant hardware info

Thinkpad P52, Linux using only integrated graphics

Have you checked that no other similar issue already exists?

• [X] I have searched and not found similar issues.

A clear and concise description of what the bug is.

When running Dosbox-Staging 0.79.1 the mouse works as expected. When running Dosbox-Staging 0.80.0 and later, the following happens:

If I open the menu of 747-400 Precision Simulator I can see the mouse cursor in its default position, however, as soon as I move my physical mouse ever so slightly the cursor jumps to a specific spot in the bottom right of the window, with just a pixel or two of the cursor poking up.

If I set sensitivity=1, I can see this happening live. However I move my physical mouse, the cursor creeps down and to the right. Once it hits the right edge of the window, it only moves down. Then it gets stuck in the bottom right.

Related discussion in #4073.

Steps to reproduce the behaviour.

Running this script in a new empty directory reproduces it for me:

#!/bin/sh

curl -SLO https://github.com/dosbox-staging/dosbox-staging/releases/download/v0.82.0/dosbox-staging-linux-x86_64-v0.82.0.tar.xz
tar -xvf dosbox-staging-linux-x86_64-v0.82.0.tar.xz

curl -SLo 747-400-precision-simulator-1.3a.zip https://ia803104.us.archive.org/cors_get.php?path=/35/items/msdos_747-400_Precision_Simulator_2000/747-400_Precision_Simulator_2000.zip
unzip 747-400-precision-simulator-1.3a.zip

cat >744ps.conf <<EOF
[autoexec]
mount c ${PWD}/747400
C:
747.BAT
EXIT
EOF

./dosbox-staging-linux-x86_64-0.82.0-9df43/dosbox --noprimaryconf --nolocalconf --conf 744ps.conf

Download URL of affected game or software

See repro script

Your configuration

See repro script

Provide a Log

https://entropicthoughts.com/pastes/744ps-log-705f37..html

Code of Conduct & Contributing Guidelines

• [X] Yes, I agree.

[interloper98]

I also had mouse problems running in a Linux VM inside a Windows host. I eventually switched to dual boot Linux along side Windows.

I remember having better results in the VM using the texture outputs (that's [sdl] output = texture or texturenb).

Curious if either help your 0.80+ builds.

[johnnovak]

Fedora 41 running in a Hyper-V virtual machine with enhanced session mode (using xrdp) under Windows 11

Right, so if our Linux guys can't repro the issue on Linux running on bare metal, I'm inclined to close this with "out of scope". Any number of things can go wrong with OpenGL / graphical apps in a VM, and we're uninterested in such scenarios. We only support Staging running on OSes running on bare metal.

[FeralChild64]

As a guy who did the mouse rework, I have to agree with @johnnovak. If you are using Windows as the host OS, I strongly suggest to get the Windows build of DOSBox Staging and run it natively.

[kqr]

output = texture did not help when I tried, unfortunately.

I am only using Windows as a hypervisor -- I don't run any applicarions in it. But I also understand your hesitation to dig into something only I experience.

As for myself, the simulator runs really well on 0.79.1 and I don't mind using that. The main reason I opened this issue anyway is I got really curious what could possibly cause this!

[FeralChild64]

You can try to use a real DOS mouse driver, not the built-in one. Some can be loaded normally, some (like Microsoft Mouse Driver 8.20) require dos_mouse_driver = false in the config file.

Part of the problem is that Hyper-V is not available in Windows 11 Home - so, if this is really related to (for example) xrdp, I have no way to investigate this (I'm not purchasing a more expensive Windows 11 version, that's for sure).

Does the problem happen with other software (mainly games) too? This simulator is a very exotic piece of software...

[johnnovak]

I am only using Windows as a hypervisor -- I don't run any applicarions in it. But I also understand your hesitation to dig into something only I experience.

That's a personal choice. We only support bare metal OSes. We've had weird VM-only issues that we closed outright in the past similarly.

Even Microsoft warns people that Hyper-V is a bad idea for games and low-latency applications, such as audio software. Yeah, audio is the other area where things can go horribly wrong with a VM.

https://learn.microsoft.com/en-us/virtualization/hyper-v-on-windows/about/#limitations

The main reason I opened this issue anyway is I got really curious what could possibly cause this!

Well, in such cases please don't raise a ticket but feel free to do the digging and experimentation yourself. If the fix is trivial, just raise a PR and we'll merge it.

[Torinde]

The main reason I opened this issue anyway is I got really curious what could possibly cause this!

I think Discussions is a better place for such cases. (although it happens for me to open Discussion-type Issues as well...)

[interloper98]

The main reason I opened this issue anyway is I got really curious what could possibly cause this!

I think Discussions is a better place for such cases.

Recall the original question only mentioned that the mouse worked in v0.79 and then broke in 0.80 and latter, which at face value is an immediate regression (and should always be reported, I would expect).

However, these disqualifying details about running inside a VM only came to light with the full context in this issue.

Without those details, @FeralChild64 would have been chassing ghosts - and @kqr also didn't realize that VM-based regressions are grounds for dismissal.

At least no additional time was wasted. Thanks for opening it @kqr so we could quickly discoverer this.