Human Readable   

GNU/Linux Journal  How-Tos and Essays  A Slackware Desktop Enhancement Guide  Home

StartX, Consoles, and Keyboard Shortcuts—Day 28

© Copyright Darrell Anderson.

Although not stopping me from using Slackware and KDE in a productive manner, the way in which I enable a second GUI session continues to perplex me. I hope somebody can shed light on this obtuse mystery.

I have edited /etc/X11/xdm/Xservers:

I have edited /opt/kde/share/config/kdm/Xservers:

My inittab is configured as follows:

When I start KDE from run level 4 and the K display manager (KDM), I get exactly what I expect:

1. When I press Ctrl-Alt-F1, I toggle to tty1 and because of the way inittab is configured, that tty session is not usable as a console.
2. Likewise, tty2 is unavailable for console use.
3. While outside of X, when I press Alt-F3 I toggle to the available tty console screen.
4. When I press Alt-F7 I return to my KDE GUI session.
5. When I select the KDE menu “Start New Session,” I toggle to another KDM login screen.
6. When I press Ctrl-Alt-F7 and Ctrl-Alt-F8 I toggle between the two GUI sessions.
7. From either GUI session I can press Ctrl-Alt-F3 to toggle to the tty3 console.
8. From the tty3 screen I can press Alt-F7/F8 to toggle to the appropriate GUI.

Except for the error messages about KDE and aRts not liking that second session, everything seems Nirvana at this point. Because I intend to boot primarily through run level 4, I should be happy. Except things do not work according to Hoyle if I decide to boot into run level 3 ans start X from there.

I always configure GRUB to allow me to boot into a command line login (init 3) or GUI login (init 4 or 5). Thus, when I want to quickly test init scripts I select run level 3 to avoid the time involved going GUI.

When I boot into run level 3, I do not see the same results of toggling consoles and screens. When I boot init 3 I see the following:

1. When I type startx I begin an X session in KDE.
2. From within KDE, when I press Ctrl-Alt-F1/F2/F3 I toggle to the expected tty console and each console is available as expected.
3. From any of the tty console screens, nothing happens when I press Alt-F7. I am taken to a blank screen with the cursor blinking at the top left corner.
4. To return to my KDE session I must press Alt-F4.
5. When I toggle to a different tty console and type startx -- :1, I do not eventually see another KDE session. I see a black background screen, the X cursor, but never proceed past Go or collect $200. I never see the familiar gray back drop.
6. There is an Xorg.1.log generated in /var/log. No clues in the log that help me.
7. Strangely, when I start an X session from the command line no ~/.xsession-errors file is generated and all X messages are directed to the screen.
8. When I append my startx command with an ampersand, I can toggle and continue using that screen, but when I exit the GUI, the command line prompt does not return automatically. I have to press Enter to awaken the prompt.
9. I thought I had eliminated the mysterious inet6 X error messages, but I had done so only if I started KDE through run level 4 and the KDM. If I started KDE from startx those error messages returned in my Xorg.0.log. I had previously edited the startx script to serverargs="-nolisten tcp" so I don’t know why those errors returned.

I pulled my hair for a long time. Two mysteries here:

1. Why can’t I start a second X session?
2. Why is the first X session being assigned to the F4 function key when in my Xservers files I specifically assign vt7?

By trial and error I noticed the following:

1. When I deleted “-nolisten tcp” from the startx serverargs parameter, I finally could start a second X session when I typed startx -- :1!
2. Before I tried deleting the serverargs parameter, I always received a KDE error message in ~/.xsession-errors that “KDE seems to be already running on this display; Hangup; GOT SIGHUP.”
3. When I typed startx -- :0 vt7 –nolisten tcp or I typed startx -- :1 vt8 –nolisten tcp, I avoided the inet6 error messages and forced-assigned my X session to the expected function keys.

My conclusion was startx never sourced the Xservers file or the Xsession script. Indeed, although I am a neophyte with bash, I am familiar enough with programming that after perusing the startx script, I decided that I was correct. When I inspected the Mandrake scripts, the Mandrake programmers are sourcing those files.

Yes, I could type this manually every time or create some aliases. I actually created some aliases simply to help me save time while troubleshooting. However, these fixes are kludges. Everything works according to Hoyle in my old Mandrake 9.2 setup in both run level 3 and 4. Yet try as I might, I cannot distinguish why everything works there and fails miserably in Slackware. I am not yet sufficiently seasoned to understand bash. True, if I intend to launch KDE mostly from init 4, then my function keys will be mapped as expected. If I work from run level 3 I have to remember the function keys are mapped differently. Bah! I want consistency and if I have that consistency in Mandrake I expect no less in Slackware.

Additionally, the alias kludge does not resolve the problem of not generating an .xsession-errors log file. I finally resolved that problem by copying a few lines of bash code from the Xsession script to the xinitrc script.

I’ve tried to study the various documentation about X and as far as I can tell I am on the right path. Yet things do not work as expected from init 3, only init 4. I understand that X normally assigns the function keys to whatever is next available, but I specifically assigned vt7 (F7) and vt8 (F8) to the respective :0 and :1 displays. Thus, why the remapping of the function keys to F4 and F5? Why won’t startx launch a second X session if the startx script is edited with serverargs parameters? Something is broke. What is going on here? I think the problem is peculiar to Slackware and is merely a lack of insight. I’m sure there are some bash wizards out there who can fix this problem.

The reason all of this works correctly with display managers is those programs use a configuration file that maps which files and scripts to use. The KDE display manager copies the existing xdm configuration files and uses those files as a baseline. The KDE display manager configuration file, kdmrc, can be regenerated at any time, so the original xdm files serve as the proper single source. Unlike Mandrake, in Slackware the startx script does not correctly source the xdm configuration files.

The Slackware startx should do the following:

1. Automatically determine the next appropriate display to use. If the user purposely types -- :1 then use that parameter, otherwise default to the next available display.
2. Automatically parse the Xservers file to determine which function keys to map to each X display, unless the user purposely uses a specific vt console.
3. Additionally, the Slackware xinitrc script should be modified to imitate the Xsession script.
4. Because any user can start a second X session, there should be separate .xsession-error files for each session, such as .xsession0-errors and .xsession1-errors. Currently, a second X session will automatically overwrite and create anew .xsession-errors file.

Lastly, once again, what do I have to do to obtain use of my right Alt key when I am not in an X session? This is getting to be a nightmare!

Finis.

Table of Contents

GNU/Linux Journal  How-Tos and Essays
A Slackware Desktop Enhancement Guide
Contact Me  Terms of Use
Search
Home