Announcement

Collapse
No announcement yet.

A Run Down Of VT Switching On Linux

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #21
    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?

    Comment


    • #22
      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.

      Comment


      • #23
        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.

        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.

        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.

        Comment


        • #24
          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).

          Comment


          • #25
            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?

            Comment


            • #26
              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.

              Comment


              • #27
                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".

                Comment


                • #28
                  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.

                  Comment


                  • #29
                    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.

                    Comment


                    • #30
                      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?

                      Comment

                      Working...
                      X