autorandr
autorandr copied to clipboard
Fails when using bwrap to launch application
When using bubblewrap which is used by sandboxing platform, such as flatpak, autorandr will crash due to bwrap
using a psuedo DISPLAY
numbered 99.
autorandr looks for used DISPLAY
for each user by looking in /proc/
, and because such DISPLAY
is not for "real", thus running DISPLAY=:99 xrandr
would cause autorandr to fail.
[es@es-l proc]$ sudo DISPLAY= /usr/bin/autorandr --debug --batch --change --default default
Running autorandr as es for display :0
autorandr running as user es (started from batch instance)
default (detected) (current)
| Differences between the two profiles:
\-
docked-open
docked
Config already loaded
Running autorandr as es for display :99
autorandr running as user es (started from batch instance)
Can't open display :99
Failed to run xrandr (line 503)
Should we ignore DISPLAY=:99
, or ignore when process is launched using bwrap?
I'm very reluctant to start a blacklist. Maintaining a list of supplications to blacklist sounds like it won't scale and maintaining a list of blocked displays doesn't cover nested x servers that use low numbers traditionally, like xephyr/xnest. Doing something like using the lowest number found per user won't work here because each application runs as it's own user? If I'm wrong and it would, I'd vote for that.
In which sense is this an issue for you? I don't see the immediate harm in starting autorandr only to quit right away because something's not right.
If there is harm, then I guess blacklisting :99 is the next best choice.
I have a similar report to add. When running Chrome with flatpak, there will be a process with a sandboxed XAUTHORITY=/run/flatpak/Xauthority
envvar. autorandr will try and fail to use that environment.
Suggestion: Add a way for users to blacklist processes by name? So we don't maintain a blacklist in autorandr, but users can fix their setups themselves.
Edit: perhaps autorandr should try different fallback environments for a given display and/or keep processing displays, otherwise any failure causes autorandr to stop batch mode and thus not apply the display changes that the user expects.
This is especially painful when unplugging my laptop from the dock leaves the laptop screen off.
e.g., see https://github.com/darkfeline/autorandr/commit/9cf9470395063ada81812089488b8feef03b2d77