kmscon with systemd and startx broken

[vodik]

On archlinux, I setup kmscon to replace agetty by creating a symlink in /etc/systemd/system/ between autovt@.service and kmsconvt@.service. This works great as systemd now automatically starts kmscon instead of agetty.

Now typically I use startx in place on a tty. So when I launch xmonad through startx on tty1, it launches X on tty1 instead of creating allocating new tty. This is necessary to have startx work nicely with loginctl. If startx instead grabs a new tty, according to systemd, the login is no longer considered active.

So when running startx on tty1, I essentially run startx -- vt0

However it seems like running kmscon prevents access to the underlying virtual terminal. Running the above command yields the following error:

Fatal server error:
xf86OpenConsole: VT_ACTIVATE failed: No such device or address

Basically, afaik, X can't draw on top of kmscon like it could with agetty.

[dvdhrm]

Yeah, that use-case isn't supported. And honestly, I see no reason why we should support it. VTs are used to allow one application per VT. So either kmscon or an xserver.

Could you elaborate why starting X on a new VT isn't good enough for you? I don't get the reason with the logind session.

We could, optionally, support some command like "kmscon-exec" which can be used to put kmscon into background and start whatever you want and kmscon will not show up as long as this process is running. However, this really doesn't make much sense to me because you could just use a separate VT.

[vodik]

This bug report explains.

startx cannot create a new session. Sessions are tied to the audit system. Once the session identifier is set for a process, it is immutable.

Starting X on a new tty causes the session to lose its active status. X will start, but goodbye hardware acceleration and sound.

More details here about how starting X "in place" helps: http://blog.falconindy.com/articles/back-to-basics-with-x-and-systemd.html

I personally use startx over a login manager because I actually do start multiple X sessions (typically 2) and chose between a few DE's depending on what I'm working on.

[dvdhrm]

I did some research here and it's not that easy to solve. The problem is that sessions are bound to VTs. At most one VT per session. The kmscon-login binds your session already to the kmscon-VT and you cannot reuse it easily as kmscon already uses the VT_GRAPHICS mode. But you also cannot start it on a new VT because this VT will not be associated with the session. So switching to the new VT will deactivate your session. (and some privileges are restricted to the active session)

So there are two ways to solve that:

\1: Add a kmscon-spawn command or similar which puts kmscon into background for as long as a client program runs. This allows "kmscon-spawn startx" and the xserver would be able to take over the VT. (btw. this is what the linux console indirectly does via the VT_TEXT/GRAPHICS mode-switch).

\2: Use a login-manager.

The problem with #\1 is that it is really ugly to implement. You would have to use control-sequences (PM or similar) to notify kmscon that you spawned a new process. Then kmscon sleeps for as long as that process is alive and when it stops, kmscon shows up again. This isn't sane at any level... And the only reason to support this is to allow users to transform TEXT sessions into GRAPHICS sessions.

So for now I have to tell you that you cannot do this with kmscon if you want you x-session to be marked as "active" session.

A simple reason for this is: kmscon provides a login for text-mode sessions. If you want graphics-mode sessions, use some other login-manager (like slim, gdm, ...). The classic linux-console does the same, btw. However, it allows to transform your session into a graphics-mode session which cannot easily be done by kmscon.

I will keep this bug open and try to figure out whether a transform into another session can be implemented in a sane way. However, I really doubt it. Sorry!

Regards David

[vodik]

Yeah, I understand and feared as much. I'll probably try and move to starting two lxdm sessions on demand on tty1 and tty2.