[solved + bug] startx option to disable a certain display

olocin · 2018-02-01 18:35:07

Is there an option available in startx command so that it requires X to disable a certain display when launched, say eDP-1? I can achieve that of course with xrandr --output eDP-1 --off, but I'd like if possible to pass it as an option to startx itself, in the same fashion as one can do startx -- -dpi 216. Is it even possible?

Last edited by olocin (2018-02-01 22:58:44)

progandy · 2018-02-01 19:04:49

I think you should be able to call xrandr in your .xinitrc and react to commandline arguments, either positional or with getopt.

if [ x"$1" = x"-external" ]; then
    xrandr ...
fi

startx -external -- -dpi 216

Trilby · 2018-02-01 19:22:18

Or just set up your alternative configurations in xorg conf files - you can even just put the dpi information there instead of needing it on the command line:

man Xorg wrote:

-screen screen-name
Use the xorg.conf(5) file Screen section called screen-name. By default the screens referenced by the default Layout section are used, or the first Screen section when there are no Layout sections.

With this, you could have `startx` use whatever you put in the first Screen section and `startx -- -screen external` for when you are plugged into the other output.

Last edited by Trilby (2018-02-01 19:23:41)

olocin · 2018-02-01 20:05:20

If I put in my .xinitrc

if [ x"$1" = x"-external" ]; then
    xrandr --output eDP-1 --off
fi

and use

startx -external

then both displays are still on, while I'd like eDP-1 to be turned off.

Last edited by olocin (2018-02-01 21:39:28)

Trilby · 2018-02-01 20:34:18

Where in your xinitrc did you put it? If you put if after an `exec` line, then yes, of course, it never runs.

olocin · 2018-02-01 20:40:23

Just after !/bin/sh

progandy · 2018-02-01 20:51:14

xrandr requires a double dash for --output, in post #4 you only have a single dash.

olocin · 2018-02-01 21:39:01

I apologize, my actual .xinitrc has two dashes, it's a copy-paste typo, but still the thing does not work. Does it work for you?

Trilby · 2018-02-01 21:48:55

What does "doesn't work" mean? How do you assess whether it worked?

EDIT: oops sorry, stupid question. I confused this with the thread where you were trying to set dpi, not just turn off a screen which would - of course - be obvious if it worked.

Last edited by Trilby (2018-02-01 22:24:52)

olocin · 2018-02-01 22:12:20

The screen I try to switch off in post #4 (with --off) is still on.

progandy · 2018-02-01 22:18:14

I missed something in the startx documentation and did only a partial test. I simply ran "startx -dummy" and did not check for -dummy in my xinitrc and that seemed to work. After reading the manpage again that seems to be wrong and should not work at all.
startx documentation says, that it won't use xinitrc if an argument is given. [Edit: Not really accurate, see the edit at the end of my post.]

As documented it sets "xterm" as the client and then calls this:

xinit xterm -external -- ...

xinit doesn't seem to work as advertised and now runs xinitrc with $1=xterm and $2=-external.
If you rely on this buggy behaviour, then you can work with "$2" instead of "$1".

If you want to use documented functionality, then one of these commands should work. you can define an alias or a wrapper script to shorten it.

# with if [ "$1" = ... ] test:
startx ~/.xinitrc -external 

# with alternative xinitrc, e.g.:
# xrandr --output XYZ --off
# source ~/.xinitrc
startx ~/.xinitrc_external

Edit: the xinit manpage is a bit unclear and it seems startx assumes some wrong things and does even more wrong things. It treats a statement in an example as the proper behaviour, but this seems to conflict with the description. Additionally, it uses "xinit" as the client instead of "/usr/bin/startx" or leaving it to xinit to select it.

man startx wrote:

To determine the client to run, startx first looks for a file called
.xinitrc in the user's home directory. If that is not found, it uses
the file xinitrc in the xinit library directory. If command line
client options are given, they override this behavior and revert to the
xinit(1) behavior.

man xinit wrote:

Description
If no specific client program is given on the command line, xinit will
look for a file in the user's home directory called .xinitrc to run as
a shell script to start up client programs. If no such file exists,
xinit will use the following as a default:
xterm -geometry +1+1 -n login -display :0
...
Both the client program name and the server program name must begin
with a slash (/) or a period (.). Otherwise, they are treated as an
arguments to be appended to their respective startup lines. This makes
it possible to add arguments (for example, foreground and background
colors) without having to retype the whole command line.

...
Examples
xinit -geometry =80x65+10+10 -fn 8x13 -j -fg white -bg navy
This will start up a server named X, and will append the given
arguments to the default xterm command. It will ignore .xinitrc.

Last edited by progandy (2018-02-01 22:37:33)

seth · 2018-02-01 22:21:02

Please post your actual .xinitrc and the output of "xrandr -q"
The typical offender here is some desktop session config altering the screen setup - and takes place at the end of the xinitrc (when launching the session)

olocin · 2018-02-01 22:43:12

Thanks progandy, using

# with if [ "$1" = ... ] test:
startx ~/.xinitrc -external

as you suggest in post # 11 works for me. If you also say it is done according to documented functionality, then I'm happy with that.

progandy · 2018-02-01 22:56:35

"startx -external" should work as well, but startx does some strange things. I edited my previous post and added that. I guess this should be reported as a bug, but I don't want to register on another bug tracker...
https://bugs.freedesktop.org/
Edit: I guess I was already registered. I'll file a bug report. I don't know if it will be fixed and which behaviour will be the end result, but maybe it will help.

Last edited by progandy (2018-02-01 22:59:05)

olocin · 2018-02-01 22:59:23

Thanks again, I marked as solved + bug.

Arch Linux

#1 2018-02-01 18:35:07

[solved + bug] startx option to disable a certain display

#2 2018-02-01 19:04:49

Re: [solved + bug] startx option to disable a certain display

#3 2018-02-01 19:22:18

Re: [solved + bug] startx option to disable a certain display

#4 2018-02-01 20:05:20

Re: [solved + bug] startx option to disable a certain display

#5 2018-02-01 20:34:18

Re: [solved + bug] startx option to disable a certain display

#6 2018-02-01 20:40:23

Re: [solved + bug] startx option to disable a certain display

#7 2018-02-01 20:51:14

Re: [solved + bug] startx option to disable a certain display

#8 2018-02-01 21:39:01

Re: [solved + bug] startx option to disable a certain display

#9 2018-02-01 21:48:55

Re: [solved + bug] startx option to disable a certain display

#10 2018-02-01 22:12:20

Re: [solved + bug] startx option to disable a certain display

#11 2018-02-01 22:18:14

Re: [solved + bug] startx option to disable a certain display

#12 2018-02-01 22:21:02

Re: [solved + bug] startx option to disable a certain display

#13 2018-02-01 22:43:12

Re: [solved + bug] startx option to disable a certain display

#14 2018-02-01 22:56:35

Re: [solved + bug] startx option to disable a certain display

#15 2018-02-01 22:59:23

Re: [solved + bug] startx option to disable a certain display

Board footer