Announcement

Collapse
No announcement yet.

Gallium3D Gets Xorg, DRI2 State Trackers

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

  • #16
    Originally posted by drag View Post
    VGA/Framebuffer - I donno. Gallium can probably provide for that also. Maybe the kernel will keep seperate drivers for it. I don't know. Not really that important anymore.
    I think the idea is to update the current FB drivers so that they will use KMS+GEM if present.

    Comment


    • #17
      Originally posted by some-guy View Post
      VESA will always be necessary as a fail-safe option
      VESA is not fail-safe. Both of my last two video card/monitor combinations were totally unusable with the VESA driver. In one case the driver simply refused to use any mode the monitor would accept, and in the later case I had the bottom 1/6th of the screen blank and no mouse cursor visible. For the nvidia hardware, the nv driver wouldn't even work right (I literally had to use the binary driver, which worked flawlessly) and for the ati hardware I had to use the radeon driver (the radeonhd driver did the same thing the VESA driver did).

      Comment


      • #18
        Originally posted by bridgman View Post
        I think the idea is to update the current FB drivers so that they will use KMS+GEM if present.
        This is something that I've found a bit confusing. What's the difference between a "kernel modesetting" driver and a "framebuffer device" driver? Different userland API?

        Comment


        • #19
          Originally posted by Ex-Cyber View Post
          This is something that I've found a bit confusing. What's the difference between a "kernel modesetting" driver and a "framebuffer device" driver? Different userland API?
          KMS is just code for setting the actual modes (resolution, depth, etc.). The framebuffer driver is a very limited drawing API (I think just for pushing pixels to video memory, more or less) and a very limited VESA/VGA mode selector. It is used by the text console and by Xorg when no other driver is available. Right now the framebuffer driver does its own mode setting, as does Xorg, which is what makes VT-switching from X to console (or even X to X) such a bitch.

          The framebuffer interface (and possibly the individual drivers, not sure) are not going away. The kernel needs them to render text consoles and to render OOPS messages and the like. The plan is to just remove the mode-setting portion of the framebuffer drivers and make them use KMS so that we have only a single mode setting framework in the kernel.

          Comment

          Working...
          X