Page 5 of 5 FirstFirst ... 345
Results 41 to 44 of 44

Thread: Christmas Comes In July For An Open ATI

  1. #41
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,434

    Default

    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; 07-30-2008 at 11:44 AM.

  2. #42
    Join Date
    Apr 2008
    Location
    /dev/random
    Posts
    218

    Default

    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

  3. #43
    Join Date
    Jan 2008
    Posts
    299

    Default

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

  4. #44
    Join Date
    Jul 2007
    Posts
    403

    Default

    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.

Posting Permissions

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