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...
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.
Thanks for your answers and comments!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
From: Rob Clark <hidden> Date: 2011-03-19 15:45:23
On Sat, Mar 19, 2011 at 6:20 AM, 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...
The KMS part of DRM has nothing to do with acceleration. So it could
be implemented on a dumb framebuffer. KMS is just about mode-setting,
and configuring framebuffer (memory) that is scanned out to one or
more displays.
BR,
-R
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.
Thanks for your answers and comments!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/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
Hello.
I have some rants and questions about fbdev, KMS and graphics stuff to
Linux. I'm just a mere user and occasional system administrator (and
going to start computer programming soon), but I hope to be able to
understand this situation better.
So if KMS is so cool and provides many advantages over fbdev and
such... Why isn't more widely used intead of still relying on fbdev?
Why still using fbdev emulation (that is partial and somewhat broken,
it seems) instead using KMS directly?
I know the graphic driver situation is quite bad on Linux, especially
on the embedded world. Fbdev seems is still quite used there by binary
blob drivers.
I was a fan of projects like DirectFB and such, but it seems they lack
the manpower or fuel to keep the project relevant. Maybe Wayland can
be their substitute and even have a broader usage too.
I hope KMS gets stronger and the graphic drivers get more into the
open source world (instead violating GPL and doing an attitude I think
should be illegal), that news about open source PowerVR SGX drivers
seems very positive (and surprising, because Imagination Technologies
seems quite against FOSS).
I hope all this gets to suck a bit less. Linux graphics stack
foundation based on KMS, TTM/GEM, advanced hardware accelerated video
decoding of most formats (by using OpenCL plus FFMpeg/LibAV, for
example), Gallium3D and full OpenGL 4.x support could make me very
happy as user and future developer...
Sadly, stuff like S3TC and such makes me very sad. I hope it gets
resolved sucessfully, patents are the nightmare of the technology...
Regards.
On Mon, Mar 21, 2011 at 6:00 PM, Jesse Barnes [off-list ref] wrote:
On Sat, 19 Mar 2011 12:20:24 +0100
Geert Uytterhoeven [off-list ref] wrote:
quoted
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.
quoted
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
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel