Announcement

Collapse
No announcement yet.

An Updated ATI Kernel Mode-Setting Driver

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

  • #11
    Originally posted by jakubo View Post
    its explicitly said that support for r500 cards is provided...
    what about r300? does it include that chipset and previous ones?
    Yes. R500 is just the latest that haven't got KMS yet.

    Check out

    http://www.x.org/wiki/RadeonFeature

    Comment


    • #12
      Yes, KMS and GEM/TTM in the radeon/drm/mesa drivers currently supports from R1xx through R5xx, plus RS690 I believe. Not sure about RS600.

      The Catalyst drivers do not work with the KMS drm; the issue is not so much KMS as the memory manager API; the proprietary drivers use a different (proprietary ) kernel memory manager.

      AFAIK the primary reason X needed root privileges was that the X drivers accessed hardware directly. Once that stops (KMS moves the hardware accesses into the kernel) then in principle you don't need root privileges for X any more. There are probably a few other things that need to be tweaked but airlied first ran non-root X over a year ago with early KMS.

      Comment


      • #13
        Originally posted by Louise View Post
        Can KMS be used together with the Catalyst drivers?
        When I first saw your question, I wanted to answer a big NO!
        Then, I would have answered "it is possible in the future using radeon.ko" and so, catalyst would have switched to TTM and would have used radeon.ko for modesetting. But I don't really know if the main difficulty is in the kernel or in the driver :s
        Finally, I remembered that catalyst had its own kernel stack with its own memory manager. So, they will have to do everything twice. I don't think this will happen in a near future (unless they've been working on it for months already).

        Originally posted by Louise View Post
        So it doesn't require a major rewrite of X to make it root-less?
        Michael made an article about it 2 months ago, I haven't checked the status yet.
        http://www.phoronix.com/scan.php?pag...item&px=NzM2MA
        If you find any news on it, please let me know
        Last edited by MPF; 07-29-2009, 12:18 PM.

        Comment


        • #14
          Originally posted by bridgman View Post
          AFAIK the primary reason X needed root privileges was that the X drivers accessed hardware directly. Once that stops (KMS moves the hardware accesses into the kernel) then in principle you don't need root privileges for X any more. There are probably a few other things that need to be tweaked but airlied first ran non-root X over a year ago with early KMS.
          Cool! It is interesting when just a few key components gets implemented, tons of features comes along.

          Comment


          • #15
            Originally posted by MPF View Post
            When I first saw your question, I wanted to answer a big NO!
            Then, I would have answered "it is possible in the future to see it", because the biggest problem of catalyst over KMS would have been the simple fact that it would not have used it.
            Finally, I remembered that catalyst had its own kernel stack with its own memory manager. So, they will have to do everything twice. I don't think this will happen in a near future (unless they've been working on it for months already).
            Very iffy but got the impression some peeps are actually trying to figure out a solution to that.

            Comment


            • #16
              Originally posted by bridgman View Post
              AFAIK the primary reason X needed root privileges was that the X drivers accessed hardware directly. Once that stops (KMS moves the hardware accesses into the kernel) then in principle you don't need root privileges for X any more. There are probably a few other things that need to be tweaked but airlied first ran non-root X over a year ago with early KMS.
              Following the message chain, the "how to do it properly" is still somewhat of a work in progress. This post http://lists.x.org/archives/xorg-dev...ly/001296.html is imo one of the most interesting in the chain.

              Comment


              • #17
                Just wondering if any of this pulls have something to improve (KMS/GEM) AGP (PCIE Rialto Chipset) situation?

                As of yesterday, I still couldn't even boot using it.

                Monitor enters on save energy mode and the system freezes.

                AGP X1600pro (Karmic Koala)

                Anyone?

                Comment


                • #18
                  About implementing KMS in Catalyst:
                  Originally posted by mtippett View Post
                  There are no plans at this stage. Most people I have spoken to don't have an interest in seeing kernel messages appear on their screen. Last time I saw that in a production system was on old Sparc X Terminals.

                  Beyond that (which can already be achieved with a kernel based chvt + message to that console (aka the Linux BSOD)), it is about avoiding slow switches during boot and fast chvt's. We haven't seen any direct requirements for these. THe intel chvt takes a second or two, under fglrx takes about half a second.

                  The GEM/TTM/other parts of what people call KMS we have already had since the R6xx family was enabled.

                  Regards,

                  Matthew

                  Comment


                  • #19
                    Originally posted by NeoBrain View Post
                    About implementing KMS in Catalyst:
                    Then, I would have answered "it is possible in the future using radeon.ko" and so, catalyst would have switched to TTM and would have used radeon.ko for modesetting. But I don't really know if the main difficulty is in the kernel or in the driver :s
                    the main dificulty is of legal nature.

                    the way proprietary ati and nvidia drivers are right now - small interface compiled against the kernel which gets linked with closed source blob to make a kernel module - is still debatable to many people. it's already been discussed and remains a headache, because apparently every person has a different opinion on the subject (that's why there are distributions that don't even ship with firmware).

                    if the drivers would move to use kms that would mean that they would have to interface with the kernel even more than they do now. which might ignite the discussion yet again.

                    but that's a highly technical topic anyway. and i'm no expert.

                    of course it should be the way to go, since it would allow for root-less X server with proprietary drivers.

                    Comment


                    • #20
                      Originally posted by yoshi314 View Post
                      of course it should be the way to go, since it would allow for root-less X server with proprietary drivers.
                      I'm not sure the internals of the radeon DRM are compatible between the free and the closed driver. In fact, I'm pretty sure it is not.
                      So, we'll have to wait for AMD :s. But mtippett said r6xx and following are already using GEM, so, the transition to KMS should be less painful than what happened with the free driver.

                      Comment

                      Working...
                      X