8

I've always been curious about an idiosyncrasy of Xorg that seems to happen on every machine I've tried it on; whenever I start a new X instance on a TTY using startx manually (that is, without the aid of a display manager), switch to another TTY, and then attempt to return to my original TTY, X's framebuffer breaks and I'm dropped to my original shell with X still running. Hitting ^C or ^D will stop X, but I'll have to run startx/xinit again, losing my original session. I.e:

CTRL+ALT+F1
$ startx /usr/bin/xterm -- :1
CTRL+ALT+F7
CTRL+ALT+F1

Will break my X buffer on TTY1. It seems that applications that rely on Wayland/Mir for composition handle TTY switching like I'd expect, but for applications that use X that aren't started with a display manager like LightDM, being unable to return to the X session I manually started is a real pain. Is there any way to correct this problem so that I can switch back to my X session when I switch TTYs?

  • I don't understand. You have no X on tty1. Also ctrl-alt-f7 is tty7 where is most of time run X server. You need to edit your post to make it more clear. If you are using 12.04, it is sure you are not using Wayland/Mir either. Not even in 15.04. – solsTiCe May 3 '15 at 22:46
  • @solsTiCe There wasn't an X session on TTY1 until I ran startx to create one on TTY1... – joshumax May 3 '15 at 22:49
  • @solsTiCe I'm afraid I don't see the ambiguity in my question, can you elaborate as to what it might be that's unclear? – joshumax May 3 '15 at 22:55
  • 1
    @solsTiCe I am most certainly not, I'm merely asking as to what you find unclear in my question so that I can fix it? – joshumax May 3 '15 at 22:56
  • For related questions, see askubuntu.com/questions/221762 and askubuntu.com/questions/443418 . – JdeBP May 4 '15 at 0:44
2

Ah, the solution was relatively simple, instead of running

$ startx /usr/bin/xterm -- :1

Running

$ startx /usr/bin/xterm -- :1 vt$(tty | sed -e "s:/dev/tty::")

Will prevent X from breaking when I switch TTYs.

  • … which indicates that it didn't really "break", but simply ended up on a different virtual terminal, the first available virtual terminal, that could have been anything from tty2 to tty63 depending from how your system happens to be configured when it comes to virtual terminal usage. Of course tty1 was unavailable, as you had a login shell running on it at the time. – JdeBP May 4 '15 at 8:33
  • @JdeBP I had a talk with the Xorg people about this, and it seems to have nothing to do with automatically selecting available terminals at all--but rather by passing a virtual terminal parameter to startx, startx will put X into a "persistent state" (as startx by default launches a non-persistent X session on the current vt if it's available, and immediately fails if it cannot do so. – joshumax May 4 '15 at 17:46
  • -1 I think there is another way to do this smoothly. I think this is not the way to do what you do. – Léo Léopold Hertz 준영 Dec 14 '15 at 20:47
  • 1
    @Masi Maybe you want to expound on why you think this method isn't that good and explicate your better way of achieving it? That would be much more serendipitous then this ambiguity. – Seth Dec 16 '15 at 1:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.