Announcement

Collapse
No announcement yet.

Christmas Comes In July For An Open ATI

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

  • #41
    So I've just pushed my initial radeon kms code to the "gem-modesetting" branch of the drm git tree.
    The corresponding DDX code is in the radeon-gem-ms branch of my personal xf86-video-ati repo.
    http://airlied.livejournal.com/

    So I think that would be :

    DRM - mesa/drm, "gem-modesetting" branch
    X driver - users/airlied/xf86-video-ati, "radeon-gem-ms" branch

    Dave might pop in and say more but I would consider it highly experimental for now.
    Last edited by bridgman; 30 July 2008, 11:44 AM.
    Test signature

    Comment


    • #42
      So that means the difference between radeonhd and radeon will be even less now, if I understand correctly, the only *real* differences will be 2D acceleration and video acceleration.

      It would be awesome if fglrx could be stripped down to a replacement DRI interface, that way ATi's hidden 3D features could be utilized without their buggy DDX

      Comment


      • #43
        Originally posted by TechMage89 View Post
        A generic VESA KMS would make a fair amount of sense, but I haven't heard anyone talk about it yet. I must say, good idea yohsi!
        I think you misunderstand what VESA is. It is a common interface for graphics cards.

        Kernel Modesetting uses the card's proprietary wake up sequence to initialize it into a state where its full capabilities can be used.

        VESA, being the common denominator for graphics cards, is a generic interface for graphics cards.

        These two are inherently different, and as I see it, mutually exclusive.

        Comment


        • #44
          No, I don't misunderstand, and no, they are not mutually exclusive.

          VESA is a common interface for graphics cards for modesetting as a fallback option. However, there still needs to be a driver to communicate with the graphics card using VESA. Right now, there are separate kernel and X drivers to do the task. This involves duplication of code, slow terminal to X switching, and much of the other ugly stuff involved in this. A VESA KMS module would provide modesetting support for both the framebuffer and for X, and give *some* of the benefits of not having a separate X driver (like for example, not having to run X as root.)

          In short, if we want the KMS way to be universal, we need a fallback interface, so that things don't get fouled up if a card is not supported. Basically, we need to make a VESA KMS.

          Comment

          Working...
          X