Announcement

Collapse
No announcement yet.

Some Distributions Still Live In A KMS-Less World

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

  • Some Distributions Still Live In A KMS-Less World

    Phoronix: Some Distributions Still Live In A KMS-Less World

    One of the most commonly mentioned terms at Phoronix is KMS, as in kernel mode-setting, whereby the GPU mode-setting is done in kernel-space rather than user-space with an X.Org DDX driver. The major open-source drivers were quick to adopt KMS support in their DRM drivers since it allows for cool features like a cleaner boot process, faster and more reliable VT switching, more reliable suspend-and-resume, greater security by running the X Server as a normal user, the ability to have a Linux kernel panic message (like a Windows BSOD), and for new technologies like the Wayland Display Server to emerge. However, not all Linux distributions are yet on this KMS bandwagon...

    http://www.phoronix.com/vr.php?view=OTI1MQ

  • #2
    Take a look at the lists of bugs fixed in stable Mesa versions, and then say with a straight face conservative distros should ship the non-stable (.0) Mesa versions.

    Comment


    • #3
      How does not shipping the latest user space mesa code have anything to do with the in kernel DRM code we've seen talked about on the LKML?

      Or was that just another cheap self referring link?

      Comment


      • #4
        As for non-KMS-by-default, perhaps they just hate the Linux kernel DRM problems?
        What a stupid, unrelated, and totally shameless self-referencing plug.

        Comment


        • #5
          Originally posted by mattst88 View Post
          What a stupid, unrelated, and totally shameless self-referencing plug.
          Agreed, this seems to be becoming more and more frequent on Phoronix. Shame on you Michael...

          Comment


          • #6
            The next release of Slackware (currently at rc3) I know has KMS on by default for the radeon drm. Either way, Zenwalk still has the support there, just not enabled by default, so who cares.

            Comment


            • #7
              Eh, uh, what?
              Hello?

              Yes, I use fglrx from time to time. Yes, it sadly doesn't work with any Kernel graphic parts. But then it brings my whole system to 85W idle. (Windows w. Catalyst is 90W and KMS is 95W at best).
              So with KMS I still have 10W more on idle, there is a bunch of rendering problems here and there, somehow I lack the bootup and init screen completely after KMS kicks in and my monitor is without signal until X rises up. (Did not do so on an older kernel, now using 2.6.38). And then, just a few minutes ago I had to REISUB (!) just after switching a few tabs in the browser. System completely frozen. Grrr.

              So without KMS my system runs better (or say: more stable and reliable) - a.t.m.. Still I hope for KMS to fully work soon on my RV670.
              But I DO understand that KMS is still not ready for productive system in the very close future. Maybe <=R500 and most intel chips do already fine.

              Comment


              • #8
                I prefer the non-KMS VT's. They don't rely on so much hardware acceleration and put less strain on the system. Sure they might be a bit slower but they work extremely reliable on almost all graphic cards/chips that you can run Linux on.
                The same can not be said for hardware accelerated OpenGL and similar.

                A few years ago I suffered from flaky hardware (in part due to a really bad power supply) for a couple of months and that made me really appreciate stability when it comes to system-critical tasks.

                It's annoying when the display driver crashes, but at least you'll have a chance to kill and restart X. How do you kill and restart a KMS VT?

                Comment


                • #9
                  Originally posted by a7v-user View Post
                  I prefer the non-KMS VT's. They don't rely on so much hardware acceleration and put less strain on the system. Sure they might be a bit slower but they work extremely reliable on almost all graphic cards/chips that you can run Linux on.
                  The same can not be said for hardware accelerated OpenGL and similar.

                  A few years ago I suffered from flaky hardware (in part due to a really bad power supply) for a couple of months and that made me really appreciate stability when it comes to system-critical tasks.

                  It's annoying when the display driver crashes, but at least you'll have a chance to kill and restart X. How do you kill and restart a KMS VT?
                  KMS VTs aren't hardware accelerated.

                  So the rest of your post is... I... you... *sigh*.

                  Comment


                  • #10
                    Originally posted by mattst88 View Post
                    What a stupid, unrelated, and totally shameless self-referencing plug.
                    I totally agree.

                    Some chit-chat on LKML about the code which will be released in 3 months and likely adopted this fall with additional heap of fixes is not really worth a comment now.

                    Comment

                    Working...
                    X