external monitor mirroring laptop monitor in Linux

[imaginaryboy 0]

I just downloaded TDM for Linux.  When I start it, it forces my external display to mirror my laptop display, then displays the game on both monitors, with one somewhat distorted due to it having the wrong aspect ratio.  Even after the quitting the game, it leaves the display setting to display the same image on both screens, which I have to fix manually.  

Ideally, I'd prefer it only play on the external display without needing to disable the built in.

 

 

[STiFU 732]

You could try the 2.08 beta and check if the issue is still given with the borderless-fullscreen mode, which you can enable in the video-settings.

 

[stgatilov 1129]

36 minutes ago, STiFU said:

You could try the 2.08 beta and check if the issue is still given with the borderless-fullscreen mode, which you can enable in the video-settings.

This would be absolutely useless, because there is no support for borderless mode on Linux.
It is only handled on Windows, and merely moves/resizes the window by a few pixels.

[STiFU 732]

Ah ok, I was not aware of that. That's quite a bummer, actually! What course of action would you suggest, @stgatilov?

[stgatilov 1129]

1 hour ago, STiFU said:

Ah ok, I was not aware of that. That's quite a bummer, actually! What course of action would you suggest, @stgatilov?

Pray for a Linux guru to come and share his wisdom with us

I'm pretty sure it is something about Linux windowing system (I guess it is called X, although today it might be Wayland). I'm afraid any Linux player will be more helpful in the diagnostics of the problem than me. Maybe @PranQster could help.

[PranQster 454]

I haven't tried TDM on a laptop with an external monitor. Nor have I tried borderless fullscreen, though that seems to be windows only.

In my case I also have 0 experience with wayland as it does not yet work with nvidia. However I will try to test this when I can, though I seriously doubt the laptop I have will even run TDM.

[duzenko 654]

On 5/5/2020 at 4:50 AM, imaginaryboy said:

I just downloaded TDM for Linux.  When I start it, it forces my external display to mirror my laptop display, then displays the game on both monitors, with one somewhat distorted due to it having the wrong aspect ratio.  Even after the quitting the game, it leaves the display setting to display the same image on both screens, which I have to fix manually.  

Ideally, I'd prefer it only play on the external display without needing to disable the built in.

I'd think you should have the full system specs (OS, drivers, laptop model) before even considering to tackle this.

I have a laptop and a monitor but the very idea of installing what version of Linux on it to hunt driver bugs is nauseating.

Imagine spending a year of your life to come up with a pull request on some obscure opensource site - and if it's proprietary and past its end of life?

[jonri 29]

On 5/4/2020 at 9:50 PM, imaginaryboy said:

When I start it, it forces my external display to mirror my laptop display, then displays the game on both monitors, with one somewhat distorted due to it having the wrong aspect ratio.  Even after the quitting the game, it leaves the display setting to display the same image on both screens, which I have to fix manually. 

I've actually got the same situation with dual-monitors on my Linux desktop.  I was recently reminded that this happens out-of-the-box by wiping settings for the 2.08 beta (where it does still happen).

The workaround I've always used is to run it windowed at the full resolution of my monitor.  Then (in KDE at least, I'm sure others have similar settings), apply window- or application-specific properties to select a monitor, remove the window border, and disable compositing.  This also has the benefit of letting you access your other monitor whenever you open the in-game console.

I believe there are some window manager hints that we could set to automatically achieve this, this sounds about like the Linux equivalent of "borderless" mode anyways. 

I don't think the poor experience is a driver-specific issue, just the fact that multi-monitors in linux has always been a pain, and also changing the resolution on the fly tends to ruin your desktop even if the program is nice enough to change it back for you afterwards.  It might also be better to detect the current resolution on first run and use it by default instead of resizing to whatever the current default value is.  I think forcefully changing resolutions like that was more acceptable back when Doom 3 came out than it is now.

As far as X vs Wayland goes, fullscreen is one of the areas where native X vs the XWayland compatibility layer may not work identically.  I'd expect XWayland to disallow some of the more invasive screen resolution changes, but I haven't really played with it to know for sure.

For reference, here are my relevant specs:

• OS: Arch Linux
• Graphics driver: AMDGPU
• Desktop: KDE (plasma5) using Xorg

I could do a little research and see if there are any modern guidelines/best practices for fullscreen on Linux and at least make some recommendations.  If I get enough free time I might be able to look at the code as well.

[STiFU 732]

Thanks for sharing your workaroung. I guess this could help @imaginaryboy for the time being.

[jonri 29]

It was easy enough to find the relevant code so I took a first look at this.  Here's what I found:

• On Windows, there's a function to get the current desktop screen resolution and use it on first run. 
• On other platforms that function is a no-op and you end up with an 800x600 resolution by default.  Without going into details, this function is called too early in the startup process for it to work on Linux.  I've got 2 possible ways to work around this that I'm trying out.
• The current mode-setting code for choosing a resolution uses the original, old-school X API calls.  These aren't very multi-monitor friendly and librandr has superseded these calls for quite some time now.  Since the platform-specific windowing code is really self-contained, I don't think it will be too hard for me to swap it out and see if things improve.
• The same area of the code already sets some X Window hints, I believe I could tack on a few more here to create a borderless mode equivalent as I previously described without much additional effort.  It seems like this is more or less what several other fullscreen applications do on Linux too.

 

[imaginaryboy 0]

Thanks for looking into this!  If it helps, here's my system specs:

 

System:    Host: inspiron Kernel: 5.3.0-45-generic x86_64 bits: 64 compiler: gcc v: 7.5.0 
           Desktop: MATE 1.22.2 wm: marco dm: LightDM Distro: Linux Mint 19.3 Tricia 
           base: Ubuntu 18.04 bionic 
Machine:   Type: Laptop System: Dell product: Inspiron 5379 v: N/A serial: <filter> Chassis: 
           type: 10 serial: <filter> 
           Mobo: Dell model: 0T8VVT v: A00 serial: <filter> UEFI: Dell v: 1.9.0 date: 06/12/2018 
Battery:   ID-1: BAT0 charge: 35.1 Wh condition: 35.1/42.0 Wh (83%) volts: 12.7/11.4 
           model: SMP DELL Y3F7Y6B serial: <filter> status: Full 
           Device-1: hidpp_battery_10 model: Logitech M705 serial: <filter> charge: 85% 
           status: Discharging 
           Device-2: hidpp_battery_11 model: Logitech K350 serial: <filter> charge: 70% 
           status: Discharging 
CPU:       Topology: Quad Core model: Intel Core i7-8550U bits: 64 type: MT MCP arch: Kaby Lake 
           rev: A L2 cache: 8192 KiB 
           flags: lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 31999 
           Speed: 2300 MHz min/max: 400/4000 MHz Core speeds (MHz): 1: 2322 2: 2312 3: 2333 
           4: 2337 5: 2316 6: 2354 7: 2321 8: 2330 
Graphics:  Device-1: Intel UHD Graphics 620 vendor: Dell driver: i915 v: kernel bus ID: 00:02.0 
           chip ID: 8086:5917 
           Display: x11 server: X.Org 1.19.6 driver: modesetting unloaded: fbdev,vesa 
           compositor: compton resolution: 1920x1080~60Hz, 1920x1080~60Hz 
           OpenGL: renderer: Mesa DRI Intel UHD Graphics 620 (Kabylake GT2) v: 4.5 Mesa 19.2.8 
           compat-v: 3.0 direct render: Yes 
Audio:     Device-1: Intel Sunrise Point-LP HD Audio vendor: Dell driver: snd_hda_intel v: kernel 
           bus ID: 00:1f.3 chip ID: 8086:9d71 
           Sound Server: ALSA v: k5.3.0-45-generic 
Network:   Device-1: Qualcomm Atheros QCA6174 802.11ac Wireless Network Adapter vendor: Dell 
           driver: ath10k_pci v: kernel port: f040 bus ID: 01:00.0 chip ID: 168c:003e 
           IF: wlp1s0 state: up mac: <filter> 
           Device-2: Atheros type: USB driver: btusb bus ID: 1-7:3 chip ID: 0cf3:e007 
Drives:    Local Storage: total: 238.47 GiB used: 141.16 GiB (59.2%) 
           ID-1: /dev/sda vendor: Toshiba model: KSG60ZMV256G M.2 2280 256GB size: 238.47 GiB 
           speed: 6.0 Gb/s serial: <filter> 
Partition: ID-1: / size: 233.24 GiB used: 141.15 GiB (60.5%) fs: ext4 dev: /dev/sda2 
USB:       Hub: 1-0:1 info: Full speed (or root) Hub ports: 12 rev: 2.0 chip ID: 1d6b:0002 
           Device-1: 1-3:15 info: Logitech Unifying Receiver type: Keyboard,Mouse,HID 
           driver: logitech-djreceiver,usbhid rev: 2.0 chip ID: 046d:c52b 
           Device-2: 1-5:2 info: Realtek type: Video driver: uvcvideo rev: 2.0 chip ID: 0bda:58f3 
           Device-3: 1-7:3 info: Atheros type: Bluetooth driver: btusb rev: 2.0 chip ID: 0cf3:e007 
           Device-4: 1-8:4 info: Elan Micro type: HID driver: hid-multitouch,usbhid rev: 2.0 
           chip ID: 04f3:2494 
           Hub: 2-0:1 info: Full speed (or root) Hub ports: 6 rev: 3.0 chip ID: 1d6b:0003 
Sensors:   System Temperatures: cpu: 56.0 C mobo: 54.0 C sodimm: 41.0 C 
           Fan Speeds (RPM): cpu: 3649 
Repos:     No active apt repos in: /etc/apt/sources.list 
           Active apt repos in: /etc/apt/sources.list.d/google.list 
           1: deb [arch=amd64] http: //dl.google.com/linux/chrome/deb/ stable main
           Active apt repos in: /etc/apt/sources.list.d/official-package-repositories.list 
           1: deb http: //packages.linuxmint.com tricia main upstream import backport #id:linuxmint_main
           2: deb http: //archive.ubuntu.com/ubuntu bionic main restricted universe multiverse
           3: deb http: //archive.ubuntu.com/ubuntu bionic-updates main restricted universe multiverse
           4: deb http: //archive.ubuntu.com/ubuntu bionic-backports main restricted universe multiverse
           5: deb http: //security.ubuntu.com/ubuntu/ bionic-security main restricted universe multiverse
           6: deb http: //archive.canonical.com/ubuntu/ bionic partner
           Active apt repos in: /etc/apt/sources.list.d/vscode.list 
           1: deb [arch=amd64] http: //packages.microsoft.com/repos/vscode stable main
Info:      Processes: 322 Uptime: 8d 5h 23m Memory: 23.24 GiB used: 6.37 GiB (27.4%) Init: systemd 
           v: 237 runlevel: 5 Compilers: gcc: 7.5.0 alt: 7 Client: Unknown python3.6 client 
           inxi: 3.0.32 

 

[duzenko 654]

On 5/8/2020 at 6:21 AM, HeresJonny said:

It was easy enough to find the relevant code so I took a first look at this.  Here's what I found:

• On Windows, there's a function to get the current desktop screen resolution and use it on first run. 
• On other platforms that function is a no-op and you end up with an 800x600 resolution by default.  Without going into details, this function is called too early in the startup process for it to work on Linux.  I've got 2 possible ways to work around this that I'm trying out.
• The current mode-setting code for choosing a resolution uses the original, old-school X API calls.  These aren't very multi-monitor friendly and librandr has superseded these calls for quite some time now.  Since the platform-specific windowing code is really self-contained, I don't think it will be too hard for me to swap it out and see if things improve.
• The same area of the code already sets some X Window hints, I believe I could tack on a few more here to create a borderless mode equivalent as I previously described without much additional effort.  It seems like this is more or less what several other fullscreen applications do on Linux too.

 

Feel free to remove screen resolution change code COMPLETELY and just maximize the window. That's what happens on Windows since a few years ago.

The engine now renders 3D in offscreen framebuffer and its dimension is controlled via render scale GUI option.

I'm sure the less legacy burden we need to carry on Linux, the better for everyone.

[jonri 29]

On 5/9/2020 at 3:17 AM, duzenko said:

Feel free to remove screen resolution change code COMPLETELY and just maximize the window. That's what happens on Windows since a few years ago.

The engine now renders 3D in offscreen framebuffer and its dimension is controlled via render scale GUI option.

I'm sure the less legacy burden we need to carry on Linux, the better for everyone.

Nice!  I never paid much attention to the render scale option, I assumed it was just something for DPI scaling.  We'll still have to grab the screen resolution at startup but everything else should be simplified after that.  I'll look at the Windows code for comparison of the logical results. 

Taking care of this should lead to a better first impression and overall experience on Linux.