[SOLVED] Switch ttys once Xorg runs issue

Areimas · 2018-01-20 16:29:24

Hi everyone,

I'm having some issues figuring out what exactly about my Xorg configuration is causing my issue, since I don't manage to find another exemple of it.

I'm running Archlinux on my laptop, which has both an intel integrated graphic card, as well as an Nvidia card. I have the proprietary nvidia drivers installed to play some games.

I have my laptop always linked to an external monitor using my hdmi port, which I use in conjunction with my laptop's screen for a dual-screen setup.

I can start Xorg and my window manager (bspwm but I suspect is not related) without issue. Though, once Xorg has started, I cannot view any other tty, or log out of bspwm and get back to my initial tty (tty1 most of the time).

If I try to switch to a different tty when Xorg runs (through ctrl + alt + Fx), then the screen freezes on whatever was visible on my screen (doesn't go black, just nothing changes). When I log out of bspwm to get back to tty1, then my screen turns black but still allows command (I can't see what I type, but trying to type startx again or shutdown does work).
I would assume that the issue comes from how I've set up my .xinitrc :

{
xrandr --output HDMI-1-1 --mode 1920x1080 --primary
xrandr --output eDP-1-1 --auto --left-of HDMI-1-1
} &

xrandr --setprovideroutputsource modesetting NVIDIA-0
xrandr --auto

xsetroot -cursor_name left_ptr
sxhkd &
exec bspwm

So far, I thought that when setting xrandr to use NVIDIA-0, the other ttys were still using my intel card, and therefore the signal sent to it was not visible.

Now, for something odd : this behaviour is not consistent.

Most of the time, when running my computer and getting to the login screen, my secondary monitor (HDMI) is not found and used. When that is the case, the issue is guaranteed to happen. But very rarely, it also happens that my secondary monitor mirrors my main monitor when logging into a tty. When that is the case, I can freely switch between ttys even with Xorg running.

In case that would help, here is my xorg.conf file :

Section "ServerLayout"
    Identifier "layout"
    Screen 1 "nvidia"
    Inactive "intel"
EndSection

Section "Device"
    Identifier "nvidia"
    Driver "nvidia"
    BusID "PCI:1:0:0"
EndSection

Section "Screen"
    Identifier "nvidia"
    Device "nvidia"
    Option "AllowEmptyInitialConfiguration" "Yes"
EndSection

Section "Device"
    Identifier "intel"
    Driver "modesetting"
    BusID "PCI:0:2:0"
    Option "AccelMethod" "none"
EndSection

Section "Screen"
    Identifier "intel"
    Device "intel"
EndSection

I also recall having had to add an extra "modeset=nouveau" in the archlinux boot command in grub. I also tried replacing it by nomodeset but that would prevent Xorg from running altogether.

Would anyone have any idea over what is going on ?

Thanks in advance !

Last edited by Areimas (2018-01-21 10:27:22)

Slithery · 2018-01-20 17:30:24

Probably nothing to do with your issue, but your ~/.xinitrc is missing vital sections...
https://wiki.archlinux.org/index.php/Xinit#xinitrc

Trilby · 2018-01-20 17:56:37

I don't know if this is the main cause of the issue (but it could definitely cause the inconsistent behavior), but you definitely should be backgrounding that subshell with two xrandr calls and following it by two more.

That is quite directly creating a non-deterministic startup where different xrandr instances may run in different orders, or even at the same time competing with each other. It's really just horrible all around - do you even need more than one call to xrandr? If you do, just run them in series, nothing in subshells and nothing backgrounded (I'm pretty sure you don't need more than one xrandr call anyways).

For the life of me I can't even figure out what they are meant to do given that the last one is just "auto" which undoes half of the other ones.

But the most likely cause of the main problem is your driver set up. You say you installed the nvidia driver. But did you configure bumblebee or optimus? With hybrid graphics, I don't think you can just install the nvidia driver and leave it at that (I don't think you can, I have no direct experience).

Last edited by Trilby (2018-01-20 18:00:19)

Areimas · 2018-01-20 21:32:02

Thank you both for your answers.

@slithery indeed you are right ! I have added the missing elements, thank you very much ! Though it is indeed unrelated to my issue.

@Trilby Well, the two lines of xrandr are what is described in the wiki to install the nvidia drivers without using bumblebee, you can find it here : https://wiki.archlinux.org/index.php/NVIDIA_Optimus

I have tried using bumblebee before, but that always resulted on a black screen after running startx even when following the wiki's instructions. Since this solution worked very well for me for a very long time ( years ), I did not see the need to use bumblebee. The issue I am having right now is pretty recent.

Something I just noticed though is that I found a way to consistently provoke this behaviour, as well as consistently avoid it : my issue only happens when my external monitor is plugged in my HDMI port when the computer boots up.

I do not know if this would happen with other screens, but I do see that when this screen is plugged in by default, archlinux does not often manage to mirror my login prompt on boot. I have noticed that other OS also have issue with this screen (often take mac OS a solid 2min of blinking back and forth before having both displays active, windows manages alright in comparaison).

Though, if I unplug my monitor, boot archlinux, and then plug it back then it can be mirrored correctly, and the issue does not happen after running Xorg.

Would I be correct to assume this would be closer to a hardware issue than anything relating to my setup ? Did anyone ever encounter something like this before ?

Trilby · 2018-01-20 21:55:20

Areimas wrote:

@Trilby Well, the two lines of xrandr are what is described in the wiki to install the nvidia drivers without using bumblebee, you can find it here : https://wiki.archlinux.org/index.php/NVIDIA_Optimus

But you have four xrandr commands - and I was primarily referring to the two in the backgrounded subshell - there is no such content in the wiki.

Areimas · 2018-01-20 22:56:51

Trilby wrote:

Areimas wrote:
@Trilby Well, the two lines of xrandr are what is described in the wiki to install the nvidia drivers without using bumblebee, you can find it here : https://wiki.archlinux.org/index.php/NVIDIA_Optimus
But you have four xrandr commands - and I was primarily referring to the two in the backgrounded subshell - there is no such content in the wiki.

Sorry since you mentioned two, I thought you were talking about the two first.
With a bit of experimentation here is the config I end up having at the moment :

...
xrandr --setprovideroutputsource modesetting NVIDIA-0 --output HDMI-1-1 --mode 1920x1080 --primary  --output eDP-1-1 --auto --left-of HDMI-1-1
xsetroot -cursor_name left_ptr
sxhkd &
exec bspwm;

With this setup, the issue still happens when the HDMI is plugged when starting the computer, but never happens when I plug the HDMI cable after the login prompt displays itself on eDP-1-1. This doesn't even seem related to Xorg or drivers at this point, since it also affects my default tty1 prompt before X is started, right ?

Trilby · 2018-01-20 23:54:23

I was talking about the first two!

Now in your xinitrc excerpt you left out those lines, but you have an elipsis suggesting there is content there you are not showing. Are the other xrandr commands still there? Post the full content of the file (after taking Slithery's comment into consideration).

rowdog · 2018-01-21 02:32:32

Areimas wrote:

xrandr --setprovideroutputsource modesetting NVIDIA-0 --output HDMI-1-1 --mode 1920x1080 --primary  --output eDP-1-1 --auto --left-of HDMI-1-1

Does it work right if you startx and then enter the above command from the shell? If so, you have a race condition where xrandr is trying to talk to an X that is still starting. I ask because my .xinitrc looks like

tint2 &
(sleep 2 && /bin/sh $HOME/.fehbg) &
xset led 3
exec openbox-session

tint2 starts up fine but feh has the race condition so I put it to sleep for 2 seconds before letting it run.
https://wiki.archlinux.org/index.php/Xr … figuration recommends using xorg.conf or having your window manager autostart the xrandr stuff.

Trilby · 2018-01-21 03:14:33

X is not still starting. X has started prior to anything in xinitrc running*. Openbox-session is, however, itself a special delicate flower. Your feh command was not in a race condition with X, but with the dozen or so background-setting checks openbox-session does during it's painfully slow startup. I like openbox, but openbox-session is rather ridiculous: I've never seen recommendations for all that "sleep" and subshell nonsense on any other WM on any unixlike system.

* A sane startup waits for SIG_USR1 from the server before clients (e.g. the shell that runs xinitrc) are spawned. The less-sane, but current implementation of xinit/startx actually attempts an XOpenDisplay call once per second and waits for it to return succesfully before launching any client code. (Unless you're on an Apple, then prior to that it waits 2 seconds before even trying because ... well 2 seems like a good arbitrary number of seconds to wait and was determined empirically to not be right, but to minimize the number of awkward complaints from users.)

(edit: I didn't mean to suggest your xinitrc is nonsense: you are following the "best practices" from the authors of openbox-session. I just think openbox-session is iteself nonsense if it is so broken that it needs to give that advice as a best practice.)

Last edited by Trilby (2018-01-21 03:43:46)

V1del · 2018-01-21 08:43:40

For the nvidia driver to be able to display a TTY you will have to load

nvidia-drm.modeset=1

on your kernel parameters or with an appropriate line in modprobe.d however the fact that you can "toggle" this by having the HDMI present or not makes this somewhat weird. Is it possible that your HDMI is hooked to the nvidia card as opposed to the intel card and thus is forcibly displayed over nvidia?

What are the outputs of

xrandr --listproviders
xrandr -q

Areimas · 2018-01-21 10:09:57

Trilby wrote:

I was talking about the first two!
Now in your xinitrc excerpt you left out those lines, but you have an elipsis suggesting there is content there you are not showing. Are the other xrandr commands still there? Post the full content of the file (after taking Slithery's comment into consideration).

The content hidden above were parts of the default xinitrc, they do not contain any xrandr command. You can find the whole content here : https://pastebin.com/g0iR9vmc

V1del wrote:

For the nvidia driver to be able to display a TTY you will have to load
nvidia-drm.modeset=1
on your kernel parameters or with an appropriate line in modprobe.d however the fact that you can "toggle" this by having the HDMI present or not makes this somewhat weird. Is it possible that your HDMI is hooked to the nvidia card as opposed to the intel card and thus is forcibly displayed over nvidia?
What are the outputs of
xrandr --listproviders
xrandr -q

Here are the outputs :

areimas@laptop ~ % xrandr --listproviders
Providers: number : 2
Provider 0: id: 0x204 cap: 0x1, Source Output crtcs: 0 outputs: 0 associated providers: 1 name:NVIDIA-0
Provider 1: id: 0x45 cap: 0x2, Sink Output crtcs: 3 outputs: 3 associated providers: 1 name:modesetting

areimas@laptop  ~ % xrandr -q
Screen 0: minimum 8 x 8, current 3286 x 1080, maximum 16384 x 16384
eDP-1-1 connected 1366x768+0+0 (normal left inverted right x axis y axis) 344mm x 194mm
   1366x768      60.00*+
   1024x768      60.04    60.00
   960x720       60.00
   928x696       60.05
   896x672       60.01
   800x600       60.00    60.32    56.25
   700x525       59.98
   640x512       60.02
   640x480       60.00    59.94
   512x384       60.00
   400x300       60.32    56.34
   320x240       60.05
VGA-1-1 disconnected (normal left inverted right x axis y axis)
HDMI-1-1 connected primary 1920x1080+1366+0 (normal left inverted right x axis y axis) 510mm x 290mm
   1920x1080     60.00*+  50.00    59.94
   1920x1080i    60.00    50.00    59.94
   1680x1050     59.88
   1400x1050     59.95
   1600x900      60.00
   1280x1024     60.02
   1440x900      59.90
   1280x800      59.91
   1152x864      59.97
   1280x720      60.00    50.00    59.94
   1024x768      60.00
   800x600       60.32
   720x576       50.00
   720x480       60.00    59.94
   640x480       60.00    59.94

I will try to set the kernel parameter as you suggested, to see if that changes anything.

EDIT : I have edited my gryb default linux command line as such :

GRUB_CMDLINE_LINUX_DEFAULT="nvidia-drm.modeset=1 quiet splash"

followed by running grub-mkconfig, but I did not notice any change.

EDIT2 : I am just an idiot. Changing it again to :

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash nvidia-drm.modeset=1"

fixes the issue altogether. Now I can let my HDMI port plugged at all time without issue. Thank you very much @V1del !

Last edited by Areimas (2018-01-21 10:24:50)

Arch Linux

#1 2018-01-20 16:29:24

[SOLVED] Switch ttys once Xorg runs issue

#2 2018-01-20 17:30:24

Re: [SOLVED] Switch ttys once Xorg runs issue

#3 2018-01-20 17:56:37

Re: [SOLVED] Switch ttys once Xorg runs issue

#4 2018-01-20 21:32:02

Re: [SOLVED] Switch ttys once Xorg runs issue

#5 2018-01-20 21:55:20

Re: [SOLVED] Switch ttys once Xorg runs issue

#6 2018-01-20 22:56:51

Re: [SOLVED] Switch ttys once Xorg runs issue

#7 2018-01-20 23:54:23

Re: [SOLVED] Switch ttys once Xorg runs issue

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

Re: [SOLVED] Switch ttys once Xorg runs issue

#9 2018-01-21 03:14:33

Re: [SOLVED] Switch ttys once Xorg runs issue

#10 2018-01-21 08:43:40

Re: [SOLVED] Switch ttys once Xorg runs issue

#11 2018-01-21 10:09:57

Re: [SOLVED] Switch ttys once Xorg runs issue

Board footer