cabalistic 885 Posted April 15 Report Share Posted April 15 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! 3 1 Quote Link to post Share on other sites
Sneaker 17 Posted April 16 Report Share Posted April 16 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). Quote Link to post Share on other sites
jonri 72 Posted April 16 Report Share Posted April 16 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! Quote Link to post Share on other sites
nbohr1more 2268 Posted April 16 Report Share Posted April 16 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. Quote 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 post Share on other sites
cabalistic 885 Posted April 16 Author Report Share Posted April 16 Sounds like you have in_grabMouse set to 0 - did you reset your darkmod.cfg? Quote Link to post Share on other sites
nbohr1more 2268 Posted April 16 Report Share Posted April 16 Yeah. That was it. It works perfectly now! Quote 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 post Share on other sites
stgatilov 1373 Posted April 17 Report Share Posted April 17 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... Quote Link to post Share on other sites
cabalistic 885 Posted April 17 Author Report Share Posted April 17 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 Quote Link to post Share on other sites
stgatilov 1373 Posted April 17 Report Share Posted April 17 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 Quote Link to post Share on other sites
stgatilov 1373 Posted April 17 Report Share Posted April 17 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) Quote Link to post Share on other sites
datiswous 24 Posted April 17 Report Share Posted April 17 (edited) 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 by datiswous Quote Link to post Share on other sites
cabalistic 885 Posted April 18 Author Report Share Posted April 18 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. Quote Link to post Share on other sites
jonri 72 Posted April 18 Report Share Posted April 18 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. Quote Link to post Share on other sites
datiswous 24 Posted April 18 Report Share Posted April 18 (edited) 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 by datiswous Quote Link to post Share on other sites
Sneaker 17 Posted April 19 Report Share Posted April 19 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. Quote Link to post Share on other sites
cabalistic 885 Posted April 19 Author Report Share Posted April 19 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? Quote Link to post Share on other sites
cabalistic 885 Posted April 19 Author Report Share Posted April 19 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 1 Quote Link to post Share on other sites
cabalistic 885 Posted April 22 Author Report Share Posted April 22 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 2 Quote Link to post Share on other sites
nbohr1more 2268 Posted April 23 Report Share Posted April 23 No issues with the mousewheel here but I didn't have these issues in the last build. Merge please? Quote 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 post Share on other sites
stgatilov 1373 Posted April 23 Report Share Posted April 23 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... Quote Link to post Share on other sites
cabalistic 885 Posted April 23 Author Report Share Posted April 23 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. 1 Quote Link to post Share on other sites
MirceaKitsune 261 Posted April 24 Report Share Posted April 24 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? Quote Link to post Share on other sites
cabalistic 885 Posted April 24 Author Report Share Posted April 24 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. Quote Link to post Share on other sites
MirceaKitsune 261 Posted April 24 Report Share Posted April 24 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. Quote Link to post Share on other sites
stgatilov 1373 Posted April 24 Report Share Posted April 24 I assume grayscaling is performed by OS in Windowed mode: Spoiler Quote Link to post Share on other sites
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.