Thread (4 messages) flat view 4 messages, 4 authors, 2011-03-21

Re: Future desktop on dumb frame buffers?

From: Jesse Barnes <hidden>
Date: 2011-03-21 18:00:44
Also in: dri-devel

On Sat, 19 Mar 2011 12:20:24 +0100
Geert Uytterhoeven [off-list ref] wrote:
As noone responded to my question in
http://www.spinics.net/lists/dri-devel/msg08851.html
(yes, it was a bit hidden in a thread), I'm asking it here again (and
also on the Wayland
mailing list).

Basically I'm still puzzled about this KMS thing. If the name "Kernel
Mode Setting"
covers it, then how does it compare to plain fbdev? Just additional frame buffer
memory management?
Also, some people may remember we did have kernel messages (e.g. oops, panic)
on graphical consoles with fbdev, until people started not liking them
showing up
on their X desktops...
We support panic these days as well, but people still don't like seeing
them. :)

The DRM KMS APIs provide everything fbdev provides, plus memory
management, a way to expose acceleration (via GEM or TTM), and a way to
manage multiple outputs reasonably.
Furthermore, everybody states that "future desktop" (that's
http://wayland.freedesktop.org/)
will require KMS drivers.
How do/will we handle this on dumb frame buffers? It's not like we can't do
"advanced" things like compositing using the CPU. Transparency may stretch
it a bit on lower end CPUs, but you don't always need that.
There's nothing in DRM that precludes doing simple fbdev-like drivers
as well, though for many embedded uses I wouldn't expect it to provide
a whole lot of benefit.

-- 
Jesse Barnes, Intel Open Source Technology Center
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help