Linux testers needed: new window management and input handling

[cabalistic]

The way that input and windows are managed for Linux has become rather dated, causing a multitude of issues. To fix that, I am currently evaluating if we can just use a library (GLFW) to handle all of that for us. First impressions are rather positive, on my end I see generally improved behavior. However, since Linux is a rather diverse ecosystem, I need additional testers to rule out I broke something important.

So if you have some time to spare, I'd appreciate it if you could give this build a try: https://ci.appveyor.com/api/buildjobs/6kbqskyx3tmla74s/artifacts/build%2Fthedarkmod.tar.bz2

Just extract to your installation, delete your darkmod.cfg and give it a spin. I'm particularly interested in input and alt-tabbing behavior. Whether it improved something for you or broke something. Thanks!

[Sneaker]

I'm on fedora 32 with a dual monitor setup and did a quick test... alt-tab worked quite nice and I didn't notice anything out of place in the few minutes I tried it out.  An improvement is that I noticed it recognized my main monitor resolution off the bat (which is something I always configured manually before).

[jonri]

I'll give this a go on Arch Linux / KDE late this weekend or early next week.  I should be able to try both X and Wayland to see what happens.  Having looked at the windowing code once before I like the approach of picking up a library that's built to be good at this.  Thanks for taking this on!

[nbohr1more]

Linux Mint 19.3 Tricia

Window Manager = Macro + Compton

User Interface scaling = Auto

 

When I start this new executable, the desktop mouse cursor appears on top of the TDM Menu cursor.

After some time fiddling around going between TDM and other applications the Desktop cursor goes out-of-sync

and is rendered to the upper left of the TDM Menu cursor and if this gets too severe the Deskop cursor will be at the edge of

the screen and will prevent the TDM Menu cursor from reaching things ( like the exit mission button ).

 

My current Window Manager setting is due to how buggy the others were when starting TDM.

I will try the Window Managers to see if any behave better now and whether these issues persist.

 

Edit:

Yes, the same behavior happens for all Window managers.

[cabalistic]

Sounds like you have in_grabMouse set to 0 - did you reset your darkmod.cfg?

[nbohr1more]

Yeah. That was it.

It works perfectly now!

[stgatilov]

I get this on Ubuntu 16.04:

./thedarkmod.x64: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.27' not found (required by ./thedarkmod.x64)
./thedarkmod.x64: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.24' not found (required by ./thedarkmod.x64)

Which is rather strange, because as far as I remember, we wanted to link all runtime statically.

UPDATE: Looking at UCM source, it seems that we only link С++ standard library statically now, but glibc is linked dynamically.
I wonder why no one has noticed it yet: my Ubuntu is only 5 years old, I'm pretty sure there are people who have older OS...

[cabalistic]

Perhaps because you build the release and dev versions with that older Ubuntu system, whereas AppVeyor builds with Ubuntu 18.04? It appears that statically linking to glibc is not without issues: https://stackoverflow.com/questions/57476533/why-is-statically-linking-glibc-discouraged

[stgatilov]

13 minutes ago, cabalistic said:

Perhaps because you build the release and dev versions with that older Ubuntu system, whereas AppVeyor builds with Ubuntu 18.04? It appears that statically linking to glibc is not without issues: https://stackoverflow.com/questions/57476533/why-is-statically-linking-glibc-discouraged

Yes, I tried to add -static, added a bunch of additional X libraries, and in the end built static executable successfully.
But 1) it crashes on start even on my system, and 2) it prints sane warnings that it will need exact same version of libdl.so in order to run, making the static linking pointless.

So we can: build on old Ubuntu and hope it works... suggest people who cannot run TDM executable to built it themselves... dive into the great world on Linux compatibility. I'll choose the first two ways

[stgatilov]

I have run ldd on thedarkmod.x64|x86 to see if the situation has changed.

Obviously, TDM 2.05 linked both glibc and C++ library dynamically, and recent TDM only links glibc dynamically.
So the problem of glibc compatibility has been like that for ages: in fact the situation has probably improved a bit with migration to CMake.

Here is the ldd output (darkmod_205/* is 2.05 and darkmod/* is your binary):

Spoiler

user@ubuntu:/mnt/hgfs/thedarkmod/darkmod_205$ ldd ./thedarkmod.x86
    linux-gate.so.1 =>  (0xf7f3b000)
    libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xf7efe000)
    libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xf7ef9000)
    librt.so.1 => /lib/i386-linux-gnu/librt.so.1 (0xf7ef0000)
    libX11.so.6 => /usr/lib/i386-linux-gnu/libX11.so.6 (0xf7da5000)
    libXext.so.6 => /usr/lib/i386-linux-gnu/libXext.so.6 (0xf7d8f000)
    libXxf86vm.so.1 => /usr/lib/i386-linux-gnu/libXxf86vm.so.1 (0xf7d88000)
    libstdc++.so.6 => /usr/lib/i386-linux-gnu/libstdc++.so.6 (0xf7c11000)
    libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xf7bbc000)
    libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xf7b9f000)
    libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf79e7000)
    /lib/ld-linux.so.2 (0xf7f3d000)
    libxcb.so.1 => /usr/lib/i386-linux-gnu/libxcb.so.1 (0xf79c1000)
    libXau.so.6 => /usr/lib/i386-linux-gnu/libXau.so.6 (0xf79bd000)
    libXdmcp.so.6 => /usr/lib/i386-linux-gnu/libXdmcp.so.6 (0xf79b6000)
user@ubuntu:/mnt/hgfs/thedarkmod/darkmod_205$ cd ../darkmod
user@ubuntu:/mnt/hgfs/thedarkmod/darkmod$ ldd ./thedarkmod.x64
./thedarkmod.x64: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.27' not found (required by ./thedarkmod.x64)
./thedarkmod.x64: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.24' not found (required by ./thedarkmod.x64)
    linux-vdso.so.1 =>  (0x00007ffd427af000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f9e1beed000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f9e1bce9000)
    libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007f9e1b9af000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f9e1b6a6000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f9e1b2dc000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f9e1c10a000)
    libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f9e1b0ba000)
    libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007f9e1aeb6000)
    libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007f9e1acb0000)

 

 

[datiswous]

Nice, Alt-tab now works. and my second monitor stays on. As said before first start correctly detects proper monitor resolution.
When doing Alt-Tab game keeps running in the background.

Previous/next weapon change via mouse wheel seems reversed..

Tested on Manjaro Linux (Arch based distro) xfce.

 

Edited April 17, 2021 by datiswous

[cabalistic]

9 hours ago, datiswous said:

Previous/next weapon change via mouse wheel seems reversed..

Do you have inverted / "natural" scrolling activated in your desktop environment? One disadvantage of GLFW is that it only reports a scroll value instead of individual events for the scroll wheel, so if that value gets inverted, it will invert the button mapping in TDM.

[jonri]

Some preliminary results from me:

This works great so far on KDE Plasma/Xorg, in addition multi-montiors and alt-tab working as expected I like the ability to resize in windowed mode.  I could see that being helpful during mapping.

I switched over to the Wayland version of plasma and the mouse is fairly unusable.  When you move around on the main menu, it will suddenly jump back to where it was a few moments ago.  I'll try to do more investigation as it could very well be plasma's fault.  Plasma/wayland still has too many glitches for me to use as my daily driver so I normally stick to Xorg.

[datiswous]

9 hours ago, cabalistic said:

Do you have inverted / "natural" scrolling activated in your desktop environment?

No, the setting reverse scroll direction is there, but is deactivated.

Don't know if it helps, but if I go to settings, try to change settings for prev. and next weapon it does detect a scroll up or scroll down from my mouse correctly.

Edited April 18, 2021 by datiswous

[Sneaker]

I also noticed the scroll wheel directions were reversed, but I've never set a "inverted/natural" wheel scroll setting (didn't know there was something like that), but, as said, I can change the directions back in the key mapping settings and it works.

[cabalistic]

Hmm... So when you reset the controls, does it also show a reverse mapping, i.e. you get MWHEELUP when you assigned down and vice versa? And if you scroll in the console or e.g. in the mission download list, is the scroll action also reversed?

[cabalistic]

Actually, there is a relevant bug report for GLFW: https://github.com/glfw/glfw/issues/1463

Supposedly fixed with version 3.3.3+, we are currently at 3.3.2. Looks like it's time to upgrade

[cabalistic]

Here's a new test executable that should hopefully fix the mouse wheel direction: https://ci.appveyor.com/api/buildjobs/xld2bd9hrvpe9f4h/artifacts/build%2Fthedarkmod.tar.bz2

[nbohr1more]

No issues with the mousewheel here but I didn't have these issues in the last build. Merge please?

[stgatilov]

13 hours ago, cabalistic said:

Here's a new test executable that should hopefully fix the mouse wheel direction: https://ci.appveyor.com/api/buildjobs/xld2bd9hrvpe9f4h/artifacts/build%2Fthedarkmod.tar.bz2

Do I need to worry about glfw update?

To be honest, I hope glfw won't need constant updates like OpenAL did...

[cabalistic]

Unlikely. I only upgraded due to a specific bug, and that probably wasn't even the cause of the issue, because I also had a bug in my own code. Otherwise, GLFW is fairly mature; the current 3.3 tree was released in April 2019, and there have been 4 patch releases since.

[MirceaKitsune]

Yet another great improvement I'm delighted to hear about! Was directed here from the extra mouse buttons bug since I understand this should guarantee at least 8 mice buttons will work in the input selection. Though I'm intrigued by many questions upon seeing this. The first being if we should see any performance improvement and how much! Also does it mean there will be native Wayland support when using a WL desktop session instead of X11?

[cabalistic]

No performance improvements - why would you expect them from this change?

I have no idea about the state of Wayland support in GLFW currently, or what other parts of TDM still depend on X indirectly. I haven't tested it, but would not get my hopes up.

[MirceaKitsune]

49 minutes ago, cabalistic said:

No performance improvements - why would you expect them from this change?

I have no idea about the state of Wayland support in GLFW currently, or what other parts of TDM still depend on X indirectly. I haven't tested it, but would not get my hopes up.

Alright. And that's because I imagined the method used to draw the window could have a minor impact on paint update latency thus on perceived performance, even if this obviously doesn't affect the work the renderer has to do before the drawing stage of each frame.

[stgatilov]

I assume grayscaling is performed by OS in Windowed mode:

Spoiler