A Run Down Of VT Switching On Linux

[curaga]

If your X Server freezes, you can't switch to a console.

That is a completely valid point, but how can you be so ignorant to think the solution in logind to that, forcing it with a timeout, could not also be implemented in kernel?

[erendorn]

They have every reason to be in the kernel, which is why they are. The kernel manages the display, the kernel manages the input. It manages the processes that run on that VT. Now, can you make an argument, when given all that, that the combination of those three should also not be in the same place?

Your argument makes it sound like X should be in the kernel.

[GreatEmerald]

Yes, I did read his blog posts. Did you read my post?

By that logic, the fix to all the problems in the X server is to extend the X server. Which it isn't, due to legacy reasons. The actual fix is to throw it all out the window and start fresh.

No, it's not. If you read the blog posts, the work to make it do its job is just now being done. So why would any existing distro deploy it, when it doesn't do its job fully yet? It may be in the development Ubuntu version, but not in any released one.

It will be included in a later version of logind, but logind itself is already used in a lot of distributions. So they'll get this functionality after updating it.

They have every reason to be in the kernel, which is why they are. The kernel manages the display, the kernel manages the input. It manages the processes that run on that VT. Now, can you make an argument, when given all that, that the combination of those three should also not be in the same place?

No. The kernel manages the display drivers and the input drivers, and then provides access to them to the userland. It shouldn't manage any processes, it's not the job of the kernel. It's the job of logind or other init daemons.

[curaga]

By that logic, the fix to all the problems in the X server is to extend the X server. Which it isn't, due to legacy reasons. The actual fix is to throw it all out the window and start fresh.

Well, I continue to think that throwing away one of the X platform's biggest advantages, networking for all apps, is a huge mistake. But there's quite a difference in scale here, the X codebase may be 1000 times that of the VT codebase, which means different solutions would work for them.

@erendorn: Also the difference in scale.

Making VTs multi-seat aware, and adding revoke() or alternatives, is a much saner choice than yet another daemon.

No. The kernel manages the display drivers and the input drivers, and then provides access to them to the userland. It shouldn't manage any processes, it's not the job of the kernel. It's the job of logind or other init daemons.

That's systemd think, init should have nothing to do with that (of course depending on the definition of "manage" - starting and stopping them is quite different from what systemd does).

[dee.]

Well, I continue to think that throwing away one of the X platform's biggest advantages, networking for all apps, is a huge mistake. But there's quite a difference in scale here, the X codebase may be 1000 times that of the VT codebase, which means different solutions would work for them.

Direct rendering on X is somehow more network-transparent than direct rendering on Wayland? How so?

[curaga]

Direct rendering on X is somehow more network-transparent than direct rendering on Wayland? How so?

Direct rendering by definition is not, but indirect rendering is. However I mainly meant 2d apps, as for 3d it usually is more bandwidth-efficient to send the image; for 2d text is much more efficient than image.

[Teho]

...than yet another daemon

It's already used to handle user logins, device access and seats on every distribution that uses systemd and Ubuntu 13.10+. This just extends it, systemd-logind itself replaces ConsoleKit so it's not "yet another daemon".

[Vim_User]

Fair enough, it will probably be hidden by a config switch for many years. HOPEFULLY it will eventually be removed after its fairly certain that its no longer used.

How would a removal of this code (or its move to userspace) affect single purpose or embedded systems that don't use/have no need for session management, multi-seat or VT switching, for example if they directly boot into a shell script or other applications. That is something I use often and the inability to do that would make Linux more or less unusable for my purposes.

[dvdhrm]

How would a removal of this code (or its move to userspace) affect single purpose or embedded systems that don't use/have no need for session management, multi-seat or VT switching, for example if they directly boot into a shell script or other applications. That is something I use often and the inability to do that would make Linux more or less unusable for my purposes.

If you don't want session-switching then you don't need VTs. Especially if you have no monitor attached.. People often confuse VTs and TTYs. Without VTs you can still use whatever TTY you want, just not on a virtual console.

[Vim_User]

If you don't want session-switching then you don't need VTs. Especially if you have no monitor attached.. People often confuse VTs and TTYs. Without VTs you can still use whatever TTY you want, just not on a virtual console.

Just to clarify that that, it would still be possible to run a bare Bash script (no init or getty used) on console with output to a monitor and keyboard input?