You are not logged in.
Pages: 1
Hello,
I have two rather newly installed Archlinux systems (one some months ago, the second a few days ago) and on both xorg runs in tty1 instead of tty7.
Is that normal behavior? (It seems strange to me.) Where and how can I configure on which console X is starting up?
Also, there are no real error messages in /var/log/Xorg.0.log. Just some warnings about falling back to old probing methods and not being able to load modules which aren't installed like fbdev and nvidia (on the machine with Nvidia chipset). Btw. do I need the modesetting module??
Also, both are old machines: Dell Latitude C840 (Nvidia 440Go) and Dell Dimension 2400 (Intel 845GV).
The Dell Dimension currently also has some problems that X only shows a blank screen with just a mouse pointer when starting lxdm. But still no error messages neither in Xorg.0.log nor in lxdm.log. A few days ago it worked well after setting rendering method to UXA for the Intel driver as stated in the wiki.
Any suggestions?
Thanks.
Last edited by cro (2013-09-18 19:25:38)
Offline
Hi, you could always use SNA again, if that works.
About the tty, yes that is normal, and is due to switching to Systemd, only starts one getty by default.
Maybe this helps https://wiki.archlinux.org/index.php/Systemd_FAQ
Offline
Actually it is not because there is only one tty started. If that were the case it would start on tty2, as the previous behavior was to start X on the first free tty.
Now X is (by default) not started on the first free tty, but instead the calling tty is used. If you run startx in tty2, X will run in tty2. This is set in /etc/X11/xinit/xserverrc.
You can easily override this by adjusting that file, or (preferrably) by specifying a vt number when you start x, eg `xinit -- vt7`.
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
Ah . I thought Systemd was what made that change, but it's X,
Thanks for some clarification Trilby.
Offline
I believe it is still ultimately due to the systemd changeover as it uses VTNR, which (IFAIK?) is set by systemd/logind - it's just not directly due to the fewer automatic ttys.
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
Switching back to the first idea I had.. due to Systemd;)
Ah so VTNR makes it possible to start on the same tty where the call is made, clear, just read man logind.conf.
Offline
Since you use a login manager: you can usually configure it there somewhere. I use slim and in my slim.conf I have
# Path, X server and arguments (if needed)
# Note: -xauth $authfile is automatically appended
default_path /bin:/usr/bin:/usr/local/bin
default_xserver /usr/bin/X
xserver_arguments -nolisten tcp vt07
which starts x on tty 7 (the xserver_arguments line).
You can do something similar in your lxdm.conf (I just had a look at the default config and it looks like it starts on tty 1 by default; http://lxde.git.sourceforge.net/git/git … ea;hb=HEAD ).
Offline
Thanks for your answers!
Hi, you could always use SNA again, if that works.
About the tty, yes that is normal, and is due to switching to Systemd, only starts one getty by default.
Maybe this helps https://wiki.archlinux.org/index.php/Systemd_FAQ
With the Intel driver on the old machine SNA runs worse (just 256 colors or something) than UXA, that's why I switched. I wouldn't have changed the default without a reason.
Ok, for fixing the current problem with the blank screen, I switched back to default (SNA I guess) and got the same result as earlier (works but 256 colors or something like that). But then as I switched back to UXA it worked again. How strange is that? No change in configuration but different behavior. Could it be some kind of problem with intial hardware state?? It really seems so. After cold restart same problem again, and after switching to SNA and back to UXA it works again. Should I post a bug report? But where?
Ah ok, I didn't got the news that X in Arch now runs by default in tty1 (or as I read the calling tty - Why has systemd a tty, isn't it a daemon??). Also, I found no mention of this fact in the wiki, but maybe it's there. I obviously missed that systemd FAQ although I read a lot about systemd before and after I switched my system to it.
I still mainly use a very old Archlinux Installation (I installed around 2005-2007), of course properly updated but some differences remain as I see, e.g. Xorg runs on tty7 as I am used to.
Actually it is not because there is only one tty started. If that were the case it would start on tty2, as the previous behavior was to start X on the first free tty.
Now X is (by default) not started on the first free tty, but instead the calling tty is used. If you run startx in tty2, X will run in tty2. This is set in /etc/X11/xinit/xserverrc.
You can easily override this by adjusting that file, or (preferrably) by specifying a vt number when you start x, eg `xinit -- vt7`.
Thanks for the information!
Letting X start on the calling tty seems a bit too random for my taste.
$ cat /etc/X11/xinit/xserverrc
#!/bin/sh
if [ -z "$XDG_VTNR" ]; then
exec /usr/bin/X -nolisten tcp "$@"
else
exec /usr/bin/X -nolisten tcp "$@" vt$XDG_VTNR
fi
Well, where is XDG_VTNR set?? Can't find it in /etc:
$ grep -r "XDG_VTNR" /etc/
/etc/X11/xinit/xserverrc:if [ -z "$XDG_VTNR" ]; then
/etc/X11/xinit/xserverrc: exec /usr/bin/X -nolisten tcp "$@" vt$XDG_VTNR
Last edited by cro (2013-09-17 13:39:46)
Offline
Since you use a login manager: you can usually configure it there somewhere. I use slim and in my slim.conf I have
# Path, X server and arguments (if needed) # Note: -xauth $authfile is automatically appended default_path /bin:/usr/bin:/usr/local/bin default_xserver /usr/bin/X xserver_arguments -nolisten tcp vt07
which starts x on tty 7 (the xserver_arguments line).
You can do something similar in your lxdm.conf (I just had a look at the default config and it looks like it starts on tty 1 by default; http://lxde.git.sourceforge.net/git/git … ea;hb=HEAD ).
Thanks for the information!
Right, /etc/X11/xinit/xserverrc is probably only used by xinit or startx or something like that!
Default for kdm seems to be 7, as I can see in /usr/config/kdm/kdmrc.pacnew.
Last edited by cro (2013-09-17 13:49:03)
Offline
VTNR, which (IFAIK?) is set by systemd/logind
I don't think you can (or should!) change what VTNR is set to. But you can override the tty for X with parameters to X as has been described above.
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
I haven't got a clue where to look for the problem with UXA?SNA, right now I'm using UXA as accelerator (happily), but I have had lots of trouble with it, pages rendering wrong, stripes on the screen, and so on. Could be a bug, I wish you luck, figuring that out.
Offline
This is the recent lxdm change: https://bbs.archlinux.org/viewtopic.php?id=169556
Offline
Trilby wrote:VTNR, which (IFAIK?) is set by systemd/logind
I don't think you can (or should!) change what VTNR is set to. But you can override the tty for X with parameters to X as has been described above.
??
Well, I could modify the xserverrc, but I don't want that. It's probably only used by startx. lxdm and other displaymanagers seem to start X directly. The tty or VT used can be set in the configuration of the displaymanager used.
The tty problem is solved for me. Thx.
I haven't got a clue where to look for the problem with UXA?SNA, right now I'm using UXA as accelerator (happily), but I have had lots of trouble with it, pages rendering wrong, stripes on the screen, and so on. Could be a bug, I wish you luck, figuring that out.
Ok.
As far as I know there are a lot of problems with the Intel driver, probably no matter if UXA or SNA. That was no concern of mine at the moment. If you have serious trouble with it you should probably open a new thread or post a bug report.
I just want to know where to post the bug report concerning the startup issue of the Intel driver I found. Where should I look? Is there a bugtracker for xorg? Is it bugs.freedesktop.org?
Last edited by cro (2013-09-17 14:36:13)
Offline
Well, there seems to be a related problem of lxdm and lightdm blocking tty1 when configured to start X on another console, which is discussed here.
Anyone tested if it's really different when using kdm (for example)? I'm not quite sure if that is the reason why I don't have these problems on my old ArchLinux installation. Maybe I will test it when I have the time.
Offline
Pages: 1