Announcement

Collapse
No announcement yet.

KMS: how to do modesetting on console?

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

  • #16
    Originally posted by rohcQaH View Post
    if speed is a problem, there's always a properly accelerated X server with a fullscreen XTerm.

    I haven't found much use for VT consoles except as a fallback, and I'd like my fallback to stay as simple (and robust) as possible.
    X isn't that terribly fast with this resolution either, but you're right.
    Bringing X up takes ages on this laptop so I use VTs whenever I need to rebuild
    something.

    Comment


    • #17
      Originally posted by agd5f View Post
      As I said earlier in this thread:

      "Dave recently posted some patches to dri-devel for setting the console modes on via the command line."

      See the dri-devel ML archives for more info.
      I think it's this one:
      http://sourceforge.net/mailarchive/f...name=dri-devel

      Comment


      • #18
        Originally posted by nanonyme View Post
        My misunderstanding probably then. I guess we'll see if anyone gets bored enough to do that. ^^
        I've looked at it. The function table for the fb device has the blitting and panning functions resolve to the generic software version, hence unaccelerated console scrolling, etc.

        I've looked into implementing hardware versions of these functions, but I couldn't find a relevant function in the GEM or TTM apis to wrap, and I didn't want to directly target the hardware from the fbdev code, as it would break the abstraction. Me fail.

        Comment


        • #19
          One more con to KMS fb vs. the existing fb drivers. Anyone want to try how fun will using Xorg fbdev driver on top of unaccelerated KMS fb be?

          I also use the VT consoles a lot. HW accel there, scrolling mostly, is important to me as well.

          Comment


          • #20
            Originally posted by DuSTman View Post
            I've looked at it. The function table for the fb device has the blitting and panning functions resolve to the generic software version, hence unaccelerated console scrolling, etc.
            Sounds like trouble. Afaik a big part of the blitting code is done in userspace for both EXA and OpenGL drivers for new cards because the stuff is just too bloody huge. (requires setting the 3D engine in the GPU in a specific state to work)
            Maybe the framebuffers also need hardware-specific userspace acceleration libraries for that to work sanely?
            Last edited by nanonyme; 10-03-2009, 10:04 AM.

            Comment


            • #21
              Originally posted by nanonyme View Post
              Sounds like trouble. Afaik a big part of the blitting code is done in userspace for both EXA and OpenGL drivers for new cards because the stuff is just too bloody huge. (requires setting the 3D engine in the GPU in a specific state to work)
              Maybe the framebuffers also need hardware-specific userspace acceleration libraries for that to work sanely?
              Had another look. There are actually blit functions for both the r100-500 and r600 series, and yes, the r600 version seems to involve setting up shaders to do the move.

              Thing is, these blit functions just move a contiguous block of memory, without the per-line offsets and such that you need to move an arbitrary rectangle from one part of the framebuffer to the other. I'd need to add another function to the dispatch tables of each of the chipsets.

              The good news is that it looks like one implementation would be sufficient for r100-r500. I'll have a go at implementing this when I get set up (half-way through moving house). I can't do anything about the r600+ versions as I don't have one to mess with.

              Comment

              Working...
              X