KMS: how to do modesetting on console?

[panda84]

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/showthread.php?p=91813#post91813

[agd5f]

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.

[agd5f]

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.

[rohcQaH]

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.

[nanonyme]

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

[mlau]

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.

[panda84]

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/forum.php?thread_name=200909291404.05222.fatih%40pardus.org.tr&forum_name=dri-devel

[DuSTman]

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.

[curaga]

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.

[nanonyme]

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?