[SOLVED] External monitor only recognised after boot or restarting X

not_a_kangaroo · 2024-02-24 10:51:22

I've been searching for answers to this for the past few days now and don't seem to be getting anywhere.

Basically, my XPS 9520 only recognises external monitors if they are plugged in when booting, or if I restart X. I have a UDEV triggered script running that uses xrandr to detect the monitors and set them up, and it works correctly if the monitors are plugged in at boot (or restarting X) but otherwise no luck.

In an ideal world, I would like to keep extending the script (activated on drm plug / unplug through UDEV) to be able to handle the various different monitor setups that I use. However, this obviously only works if they can be recognised by xrandr when hotplugged.

I'm at the point of guessing now, but do I need to be ensuring that some firmware is always loaded at boot time or something similar to that? I'm feeling a bit out of ideas to be honest.

Some potentially relevant info:
- Running i3
- My XPS does have a nvidia 3070 in it, however, I believe I am using the built-in one by default. Confirmed by running:
glxinfo | grep "OpenGL renderer string" - and I get back Mesa Intel (R) Graphics (ADL GT2)

Thanks in advance for any guidance!

Last edited by not_a_kangaroo (2024-02-25 20:36:50)

seth · 2024-02-24 13:57:50

have a UDEV triggered script running that uses xrandr

on the advice of shitGPT
You want https://aur.archlinux.org/packages/x-on-resize

not_a_kangaroo · 2024-02-24 19:19:04

ha, thanks - agree it gives pretty shoddy advice! After looking around I followed the advice found here but clearly going down the wrong path. I am having a play with x-on-restart now, so fingers crossed will solve the problem. Will report back!

not_a_kangaroo · 2024-02-25 00:13:56

seth wrote:

have a UDEV triggered script running that uses xrandr
on the advice of shitGPT
You want https://aur.archlinux.org/packages/x-on-resize

Afraid I'm having the same outcome as with the UDEV Script. The script seems to be triggered either way (UDEV or x-on-resize, although x-on-resize does seem like a cleaner implementation and so will continue with that!) but the issue seems to be that the script doesn't work as expected.

Weirdly, if I run the xrandr commands in the terminal manually, then they have the desired effect even if the monitors aren't connected on boot or when restarting X. However, when those same commands are called from a script, they will only work on the first attempt if the monitors are connected at boot / after restarting X. Equally odd, if I connect the monitors after boot and then enter the commands manually in the terminal (a way that seems to get things working), then after that the script works as expected. Just seems to not like the commands coming from a script for the first configuration.

Maybe help with a script is outside the scope of this forum - I'm not sure - but will link it here just in case.

Otherwise - do you know of some avenues I need to look down? I'm calling x-on-resize from i3 and so coupled with the fact that it works after done once manually, I'm assuming the daemon has the permissions needed to run the file correctly.

seth · 2024-02-25 08:06:21

The main benefit of x-on-resize is that it runs on the relevant X11 server with the relevant environment, you don't have to guess the server, detect its display and owner, su into that, import the XAUTHORITY (and in this case DBUS_SESSION_BUS_ADDRESS) from another process running there (your script doesn't do any of this, but it hardcodes the display)

1. Make sure you've removed the udev rule
2.

they will only work on the first attempt if the monitors are connected at boot / after restarting X

X11 by default enables all present outputs, if you've some configlet in place, it'll also place them accordingly
3. enter what commands manually? Can you just run your script instead?
4. how exactly do you start x-on-resize? xinitrc?

Your greps might be off, because there can be tokens between "connected" and the size (notably "primary")
You should be able to debug the script w/ notify-send (just notify-send yourself the actual variable resolution)

not_a_kangaroo · 2024-02-25 09:57:36

seth wrote:

The main benefit of x-on-resize is that it runs on the relevant X11 server with the relevant environment, you don't have to guess the server, detect its display and owner, su into that, import the XAUTHORITY (and in this case DBUS_SESSION_BUS_ADDRESS) from another process running there (your script doesn't do any of this, but it hardcodes the display)
1. Make sure you've removed the udev rule
2.
they will only work on the first attempt if the monitors are connected at boot / after restarting X
X11 by default enables all present outputs, if you've some configlet in place, it'll also place them accordingly
3. enter what commands manually? Can you just run your script instead?
4. how exactly do you start x-on-resize? xinitrc?
Your greps might be off, because there can be tokens between "connected" and the size (notably "primary")
You should be able to debug the script w/ notify-send (just notify-send yourself the actual variable resolution)

Thanks for getting back to me!

1. Yep, UDEV rule is completely gone and I cleaned up the script to remove the Xauthority and DBUS_SESSION_BUS_ADDRESS before sharing.

2. Interesting - so If I was to set up a configlet, is this likely to work better for those hot plug events? I'll give this a try!

3. This is where it's odd. Regardless of when I attach the monitors (before boot, after boot etc. ), if I write the commands that are in the script sequentially into a terminal, they have the desired effect. If I attach the monitors before boot, the script also works as expected. However, if I attach the monitors after boot, and I either manually run the script or it is triggered by x-on-resize, it doesn't fully work. Things do happen, e.g. I can notify-send monitor names (correctly) and my inbuilt monitor will turn off (with is one of the xrandr commands) - but the second monitor won't actually spring to life. The really odd part to this is that the script will start to work completely as expected again if the same commands that are in the script have been entered into the terminal manually once. I hope I'm explaining this well enough but to me I'm understanding it as the script works, technically, but either a) doesn't have the right permissions to get xrandr going the first time, but is okay if it's been done manually once before, or b) potentially the speed at which the commands are run in the script stops them from working the first time. I've tried playing with adding '&' s and sleeps to ensure one command is complete before going onto the next but doesn't seem to be the right path either.

4. I am currently starting it from within my i3 config.

Yeah, understood on the greps. I've done a fair bit of debugging on this front already with notify-send and think I'm all good from what I can tell.

Last edited by not_a_kangaroo (2024-02-25 10:09:09)

seth · 2024-02-25 15:31:33

The xorg confliglets will not activate outputs attached to a running server, only control what to do with them when the server starts.

If the script fails on manual invocation on the first run, add "set -x" to its top to trace it.
I highly suspect that

widescreen=`xrandr -d :0 -q | grep 'connected 3440x1440' | cut -d' ' -f1`
penArtist=`xrandr -d :0 -q | grep 'connected 1920x1080' | cut -d' ' -f1`

actually fails because the connected, but not enabled outputs will not have a size to them.

If you don't want to hardcode the outputs (I assume you using them directly on manunal step-by-step processing) you probably want to parse the EDID for the output name.

not_a_kangaroo · 2024-02-25 20:35:44

seth wrote:

The xorg confliglets will not activate outputs attached to a running server, only control what to do with them when the server starts.
If the script fails on manual invocation on the first run, add "set -x" to its top to trace it.
I highly suspect that
widescreen=`xrandr -d :0 -q | grep 'connected 3440x1440' | cut -d' ' -f1`
penArtist=`xrandr -d :0 -q | grep 'connected 1920x1080' | cut -d' ' -f1`
actually fails because the connected, but not enabled outputs will not have a size to them.
If you don't want to hardcode the outputs (I assume you using them directly on manunal step-by-step processing) you probably want to parse the EDID for the output name.

Thanks! Yes, I was trying to avoid using output names due to moving around a fair bit with my laptop, and also because my docking station seems to use different output names each time I reconnect. I was having some trouble with finding the EDID info for my monitors, however, in my research I stumbled upon autorandr, which I think is exactly what I was looking for! I'll need to set up multiple profiles to handle the different connections issue, but all in all it will do for what I'm hoping to achieve. Thanks for your help, very much appreciate it!

Arch Linux

#1 2024-02-24 10:51:22

[SOLVED] External monitor only recognised after boot or restarting X

#2 2024-02-24 13:57:50

Re: [SOLVED] External monitor only recognised after boot or restarting X

#3 2024-02-24 19:19:04

Re: [SOLVED] External monitor only recognised after boot or restarting X

#4 2024-02-25 00:13:56

Re: [SOLVED] External monitor only recognised after boot or restarting X

#5 2024-02-25 08:06:21

Re: [SOLVED] External monitor only recognised after boot or restarting X

#6 2024-02-25 09:57:36

Re: [SOLVED] External monitor only recognised after boot or restarting X

#7 2024-02-25 15:31:33

Re: [SOLVED] External monitor only recognised after boot or restarting X

#8 2024-02-25 20:35:44

Re: [SOLVED] External monitor only recognised after boot or restarting X

Board footer