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
On Sat, Mar 19, 2011 at 6:20 AM, Geert Uytterhoeven geert@linux-m68k.org wrote:
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
On Sat, 19 Mar 2011 12:20:24 +0100 Geert Uytterhoeven geert@linux-m68k.org wrote:
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.
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.
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 jbarnes@virtuousgeek.org wrote:
On Mon, 21 Mar 2011 19:19:43 +0000 timofonic timofonic timofonic@gmail.com wrote:
Used by what? All three major GPU device classes have KMS support (Intel, ATI, and nVidia). If you want it for a particular device, you can always port it over.
As for fbdev emulation, what's still using it? There's nothing stopping projects from converting over; X and Wayland can already handle KMS APIs just fine.
Probably for a couple of reasons: 1) inertia: fbdev has been around a lot longer, and provides most of what embedded devices need anyway 2) feature set: why bother doing a full KMS driver if you're not going to use any of the additional features it would provide (output management, memory management, execution management)
Jesse
On Mon, Mar 21, 2011 at 12:25 PM, Jesse Barnes jbarnes@virtuousgeek.org wrote:
Related: We are still missing basic userspace tools (kmsset, e.g.), some kind of direct KMS console (kmscon would work, if it existed), and an xf86-video-modesetting which compiles and works (this is actually possible now, with some patches that landed in 2.6.38 for generic KMS access.)
This is important to me, as the various old drivers I've been hacking on won't be accepted upstream without some sort of userspace which can work with them. One of the big goals of KMS was a generic userspace-facing API, like FB, but without the suck.
~ C.
On Mon, 21 Mar 2011 12:34:38 -0700 Corbin Simpson mostawesomedude@gmail.com wrote:
Yeah, we used to call that drmcon, and it's still a big open. I think there are some projects that sit on top of fbdev and provide a good text console with fancy character and input support, but I don't know if any of them have been ported to KMS to handle multiple outputs or with an aim toward integrating into a distro as a VT replacement.
kmsset or something would be pretty easy to do; the modetest program in the drm repo would be a good starting point for that. One limitation there is handling fbcon, which makes reallocation of the framebuffer somewhat difficult.
IIRC plymouth or whatever Fedora is using these days uses the KMS APIs though...
On Monday 21 March 2011 20:34:38 Corbin Simpson wrote:
On Mon, Mar 21, 2011 at 12:25 PM, Jesse Barnes jbarnes@virtuousgeek.org
wrote:
This looks interesting. If existing *fb drivers could be easily converted to KMS (including 2D acceleration) and then used in X with a common driver, it would be great. Let's say, convert cyber2000fb driver to KMS and use it in X with 2D acceleration.
On Mon, Mar 21, 2011 at 5:13 PM, Ondrej Zary linux@rainbow-software.org wrote:
You'd need to update the existing DDX to work with KMS. Generally you need some sort of userspace driver to allocate the buffers, deal with acceleration alignment, build the acceleration command buffers, and interface with X.
Alex
On Mon, Mar 21, 2011 at 20:25, Jesse Barnes jbarnes@virtuousgeek.org wrote:
The three major GPU device classes on PC...
Can Wayland handle fbdev APIs ...
... if no additional features of KMS are needed?
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
On Mon, 21 Mar 2011 20:50:20 +0100 Geert Uytterhoeven geert@linux-m68k.org wrote:
Yes, good point. :)
Yes. Fundamentally, the Wayland protocol just assumes a way to share buffers between processes. For the software raster version of the Qt port, Kristian created a shmem interface for doing that to allow the results of CPU rendering to be passed around without copying. On an embedded device that would be one way to go.
On Mon, Mar 21, 2011 at 3:50 PM, Geert Uytterhoeven geert@linux-m68k.org wrote:
Sadly it gets worse. A lot of the SoC vendors are adding an fbdev emulation layer on top of v4l rather than using fbdev directly or using KMS and v4l has grown it's own edid, hdmi, and cec handling.
Alex
On 21 March 2011 21:08, Alex Deucher alexdeucher@gmail.com wrote:
I agree, it is sad that as a SoC vendor there are different kernel/user API's(v4l2/fbdev/drm) to choose from when implementing say a Display controller driver. One must also remember that there are big differences between a desktop/PC multimedia/graphics system and the ones present on an embedded SoC. It is two very different cultures and HW designs now trying to merge into one Linux Kernel. Of course there will be some overlaps but I believe it can be sorted out as soon as we understand each others different possibilities/limitations. Doing duplicate work like HDMI will not benefit any party.
Just to list some of the differences.
- Developments within V4L2 has mainly been driven by embedded devices while DRM is a result of desktop Graphics cards. And for some extent also solving different problems. - Embedded devices usually have several different hw IP's managing displays, hdmi, camera/ISP, video codecs(h264 accellerators), DSP's, 2D blitters, Open GL ES hw, all of which have a separate device/driver in the kernel, while on a desktop nowadays all this functionality usually resides on ONE graphics card, hence one DRM device for all. - DRM is closely developed in conjunction with desktop/Xorg, while X11 on an embedded device is not very 2011...wayland on the other hand is :-), but do wayland really need the full potential of DRM/DRI or just parts of it. - Copying buffers is really bad for embedded devices due to lower memory bandwidth and power consumption while on a Desktop memory bandwidth is from an other galaxy (copying still bad but accepted it seems), AND embedded devices of today records and plays/displays 1080p content as well. - Not all embedded devices have MMU's for each IP requiring physical contiguous memory, while on a desktop MMU's have been present for ages. - Embedded devices are usually ARM based SoCs while x86 dominates the Desktop/Laptop market, and functionality provided is soon the very same. - yada yada....The list can grow very long....There are also similarities of course.
The outcome is that SoC vendors likes the embedded friendliness of v4l2 and fbdev while "we" also glance at the DRM part due to its de-facto standard on desktop environments. But from an embedded point of view DRM lacks the support for interconnecting multiple devices/drivers mentioned above, GEM/TTM is valid within a DRM device, the execution/context management is not needed,, no overlays(or similar), the coupling to DRI/X11 not wanted. SoCs like KMS/GEM but the rest of DRM will likely not be heavily used on SoCs unless running X11 as well. Most likely this worked on as well within the DRI community. I can see good features all over the place(sometimes duplicated) but not find one single guideline/API that solves all the embedded SoC problems (which involves use-cases optimized for no-copy cross media/drivers).
Last but not least...
On Linaro there is already discussions ongoing to solve one of the biggest issues from a SoC point of view and that is a "System Wide Memory manager" which manages buffer sharing and resolves no-copy use cases between devices/drivers. Read more on the following thread: http://lists.linaro.org/pipermail/linaro-dev/2011-March/003053.html.
BR /Robert Fekete st-ericsson
On Wednesday 23 March 2011 15:09:54 Robert Fekete wrote:
We're also evaluating the possibility of providing a generic fbdev emulation layer on top of V4L2 without requiring any device-specific fbdev code. fbdev isn't maintained and hasn't really evolved for quite some time now.
On Mon, 21 Mar 2011 21:20:08 +0000 Alan Cox alan@lxorguk.ukuu.org.uk wrote:
Jeez, some people want it all.
You looking for docs for the ioctls and such?
On Mon, Mar 21, 2011 at 9:20 PM, Alan Cox alan@lxorguk.ukuu.org.uk wrote:
My summer of code project's purpose was to create something of a tutorial for writing a KMS driver. The code, split out into something like 15 step-by-step patches, and accompanying documentation are available from Google's website.
http://code.google.com/p/google-summer-of-code-2010-xorg/downloads/detail?na...
My repository (doesn't include the documentation) is available here: http://git.kernel.org/?p=linux/kernel/git/mattst88/glint.git;a=summary
There's a 'rebased' branch that contains API changes required for the code to work with 2.6.37~.
It's nothing fantastic, but I've had a number of people tell me that it was useful for them.
Thanks, Matt
On 21 March 2011 20:25, Jesse Barnes jbarnes@virtuousgeek.org wrote:
The console and a few terminal emulators for it I guess.
Thanks
Michal
dri-devel@lists.freedesktop.org
-
Alan Cox -
Alex Deucher -
Corbin Simpson -
Geert Uytterhoeven -
Jesse Barnes -
Laurent Pinchart -
Matt Turner -
Michal Suchanek -
Ondrej Zary -
Rob Clark -
Robert Fekete -
timofonic timofonic