Announcement

Collapse
No announcement yet.

KMS: how to do modesetting on console?

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

  • #11
    Originally posted by mlau View Post
    Going back to my original question: Is it possible to set another videomode on the KMS-driven linux framebuffer console?
    See also:
    http://www.phoronix.com/forums/showt...1813#post91813

    Comment


    • #12
      Originally posted by nanonyme View Post
      Actually fbcon is using DRM framebuffer. I recall hearing security concerns related to using eg blits there.
      Not a security problem, just not really worth the hassle. If you want accel, do it like the ddx or GL.

      Comment


      • #13
        Originally posted by mlau View Post
        Going back to my original question: Is it possible to set another videomode on the KMS-driven linux framebuffer console?
        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.

        Comment


        • #14
          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.

          Comment


          • #15
            Originally posted by agd5f View Post
            Not a security problem, just not really worth the hassle. If you want accel, do it like the ddx or GL.
            My misunderstanding probably then. I guess we'll see if anyone gets bored enough to do that. ^^

            Comment


            • #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

                      Working...
                      X