Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 21

Thread: KMS: how to do modesetting on console?

  1. #11
    Join Date
    Jun 2008
    Posts
    172

    Default

    Quote 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

  2. #12
    Join Date
    Dec 2007
    Posts
    2,404

    Default

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

  3. #13
    Join Date
    Dec 2007
    Posts
    2,404

    Default

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

  4. #14
    Join Date
    Nov 2008
    Posts
    784

    Default

    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.

  5. #15
    Join Date
    Aug 2008
    Location
    Finland
    Posts
    1,806

    Default

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

  6. #16
    Join Date
    Sep 2006
    Posts
    216

    Default

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

  7. #17
    Join Date
    Jun 2008
    Posts
    172

    Default

    Quote 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

  8. #18
    Join Date
    Jan 2009
    Posts
    86

    Default

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

  9. #19
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    5,334

    Default

    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.

  10. #20
    Join Date
    Aug 2008
    Location
    Finland
    Posts
    1,806

    Default

    Quote 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 at 11:04 AM.

Posting Permissions

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