Jump to content
The Dark Mod Forums

Linux testers needed: new window management and input handling


cabalistic
 Share

Recommended Posts

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

Link to comment
Share on other sites

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!

Link to comment
Share on other sites

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.

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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 😭

Link to comment
Share on other sites

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)

 

 

Link to comment
Share on other sites

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 by datiswous
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by datiswous
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share


  • Recent Status Updates

    • STiFU

      We are taking our son on his very first holiday trip to see the sea for the first time. 🙂 Will be back in a week.
      · 0 replies
    • Gilkar

      When I was a young man my father was so ignorant I could hardly stand to have him around. As I grew older I was amazed at how much the old man had learned in such a short time.
      · 1 reply
    • jaxa

      RTX 3090 Super, RTX 3070 Ti 16 GB, RTX 2060 12 GB
      https://wccftech.com/nvidia-launching-rtx-3090-super-rtx-3070-ti-16gb-and-rtx-2060-12gb-by-january-2022/
      · 0 replies
    • duzenko

      CPU benchmark time - compiling DarkRadiant (2nd run)
      i5 8600K 6C/6T@4.4GHz DDR4 2x2133MHz 9MB cache
      Parallel builds: 1. 3:57 Parallel builds: 6 (default). 2:28 r5 1600AF 6C/12T@3.3GHz DDR4 1x2666MHz 16 MB cache, temp folder on HDD
      Parallel builds: 1. 5:05 Parallel builds: 4. 2:47 Parallel builds: 6. 2:55 Parallel builds: 12 (default). 2:57
      · 6 replies
    • nbohr1more

      Status updates are back so it is also a good time to return to contests!
      https://forums.thedarkmod.com/index.php?/topic/21095-christmas-connections-contest-2021
       
      · 0 replies
×
×
  • Create New...