Page 1 of 2 12 LastLast
Results 1 to 10 of 14

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

  1. #1
    Join Date
    Jan 2007
    Posts
    14,529

    Default 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. #2
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    5,033

    Default

    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.

  3. #3
    Join Date
    Dec 2007
    Location
    Edinburgh, Scotland
    Posts
    574

    Default

    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?

  4. #4
    Join Date
    Jan 2008
    Posts
    297

    Default

    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.

  5. #5
    Join Date
    Apr 2010
    Posts
    62

    Default

    Quote 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...

  6. #6
    Join Date
    Oct 2008
    Posts
    25

    Default

    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.

  7. #7
    Join Date
    Mar 2009
    Location
    in front of my box :p
    Posts
    781

    Default

    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.

  8. #8
    Join Date
    Apr 2007
    Posts
    37

    Default

    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?

  9. #9
    Join Date
    Jan 2008
    Posts
    297

    Default

    Quote 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*.

  10. #10
    Join Date
    Jan 2009
    Posts
    619

    Default

    Quote 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.

Posting Permissions

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