KMS as anext-gen Framebuffer?

[timofonic]

Hello.

I'm planning to make some embedded systems not using X or related dependencies. In the past I used Linux Framebuffer (I'll use fbdev next times), but it seems Kernel mode-setting (KMS) gained a lot attention lately.

The key is making a minimalist system, avoiding dependencies and bloat at all so getting easier to maintain and more lightweight.

In the past people used framebuffer and were able to play videos by using mplayer of cvlc plus other stuff.

I see fbdev is still quite used in the embedded world, but mostly using binary blobs.

I would like to know if KMS can be the successor to fbdev.

Whats the future of projects like DirectFB and GGI?

What about running a totally xless environment but still providing accelerared 2D and 3D? Will it be possible being 100% Open Source?

What will happen to fbdev? I see there are some commits there, but the project seems stagnating.

Regards.

[rohcQaH]

I would like to know if KMS can be the successor to fbdev.

KMS *is* the successor to fbdev, though I'm not sure if there will be a compatibility mode or if any application has to switch over to the new API.
It certainly doesn't seem like any of the current OS gfx driver developers consider fbdev a priority.

What about running a totally xless environment but still providing accelerared 2D and 3D? Will it be possible being 100% Open Source?

possible. Once you have KMS, you can just use DRI to draw stuff. An experiment to provide such things without an X server is called Wayland. It even provides windowing, compositing etc with less bloat than X.


In short, the technology is there, everything you want should be possible, but it's still missing all the duct tape to make your favourite application work with the new APIs. I guess SDL-applications could be ported by porting SDL, but that's not done yet, either.
The majority of users just use X, it works fine with everything(tm).

[timofonic]

Hello.

Sorry for the subpar writing, I fixed it but the 1 minute editing limit made the text improvement unavailable

KMS *is* the successor to fbdev, though I'm not sure if there will be a compatibility mode or if any application has to switch over to the new API.
It certainly doesn't seem like any of the current OS gfx driver developers consider fbdev a priority.

Yes, fbdev times were quite sad. Lots of under-developed frame buffer drivers and propietary ones on embedded platforms (set top boxes, mobile devices...).

possible. Once you have KMS, you can just use DRI to draw stuff. An experiment to provide such things without an X server is called Wayland. It even provides windowing, compositing etc with less bloat than X.

Wayland looks fine, but it's somewhat a lighter X. Windowing and compositing could be totally unuseful in certain situations. The project indeed looks experimental and lacks stronger support from some Linux distro or company, so it's still not a good candidate other than being a nice geek toy

Excuse me, but isn't using DRI a bit overkill in certain circunstances? Maybe it's just me, but DRI looks too much low level for most of the average application development.

Where's the possibility on KMS of mixing console text and graphics? And having the possibility of a more advanced console with better drawing of unicode characters, antialising and more.

Other of the nice things about fbdev is being somewhat easy to access by the /dev/fb[0-9] and such.

Maybe the key is a new back-end for Gallium3D's MESA? Probably video acceleration APIs like VA-API could fix this partially, I don't know.

In short, the technology is there, everything you want should be possible, but it's still missing all the duct tape to make your favourite application work with the new APIs. I guess SDL-applications could be ported by porting SDL, but that's not done yet, either.
The majority of users just use X, it works fine with everything(tm).

I'm really worried about KMS suffering the lack of support fbdev lately had. Today it lacks a proper support page featuring a list of important software using it, for example.

Porting stuff like SDL could be interesting, of course.

[curaga]

In my experience the fb interface to kms is not perfect, and I don't think there's much incentive to making it so. For me things like SDL and bootsplash don't work with a KMS fb, yet work just fine with any true fbdev driver.

Mplayer's fb output seems to work w/ kms, but it's fairly useless in actual video playing due to the high cpu usage. If you need good video playing without X, do what Geexbox 1.x series did, use vesa bios + vidix on a supported card.

[timofonic]

In my experience the fb interface to kms is not perfect, and I don't think there's much incentive to making it so. For me things like SDL and bootsplash don't work with a KMS fb, yet work just fine with any true fbdev driver.

Mplayer's fb output seems to work w/ kms, but it's fairly useless in actual video playing due to the high cpu usage. If you need good video playing without X, do what Geexbox 1.x series did, use vesa bios + vidix on a supported card.

That's what I'm worried about. I did see lots of forum threads by users complaining of KMS under certain circustamces, like video playing with Mplayer or cvlc.

[timofonic]

Finally, some DRI devs gave me some info:

• Libkms is the interface for KMS, the fbdev interface is a compatibility layer. They say the current fbdev compatibility layer is not perfect, but it's not in their priority to improve it.
  
• Fbcon works good, so not interested in making it "kmscon". Fbcon lives inside the kernel and making it using KMS would need to make it user space.

I hope this helps others, in the future a nice article about KMS for not so technically skilled users could be quite interesting for Phoronix.