Page 3 of 11 FirstFirst 12345 ... LastLast
Results 21 to 30 of 109

Thread: A Run Down Of VT Switching On Linux

  1. #21
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    5,128

    Default

    Quote Originally Posted by Ericg View Post
    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?

  2. #22
    Join Date
    Sep 2012
    Posts
    687

    Default

    Quote Originally Posted by curaga View Post
    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.

  3. #23
    Join Date
    Sep 2008
    Location
    Vilnius, Lithuania
    Posts
    2,563

    Default

    Quote Originally Posted by curaga View Post
    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.

    Quote Originally Posted by curaga View Post
    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.

    Quote Originally Posted by curaga View Post
    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.

  4. #24
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    5,128

    Default

    Quote Originally Posted by GreatEmerald View 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.
    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).

  5. #25
    Join Date
    Jan 2013
    Posts
    1,458

    Default

    Quote Originally Posted by curaga View Post
    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?

  6. #26
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    5,128

    Default

    Quote Originally Posted by dee. View Post
    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.

  7. #27
    Join Date
    Jul 2010
    Posts
    593

    Default

    Quote Originally Posted by curaga View Post
    ...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".

  8. #28
    Join Date
    Jan 2013
    Posts
    1,116

    Default

    Quote Originally Posted by Ericg View Post
    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.

  9. #29
    Join Date
    Mar 2012
    Posts
    14

    Default

    Quote Originally Posted by Vim_User View Post
    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.

  10. #30
    Join Date
    Jan 2013
    Posts
    1,116

    Default

    Quote Originally Posted by dvdhrm View Post
    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?

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •