A Call For Deprecating The Linux Frame-Buffer FBDEV

[phoronix]

Phoronix: A Call For Deprecating The Linux Frame-Buffer FBDEV

A call was made during the Linux Plumbers Conference on Wednesday to deprecate the Linux kernel FBDEV support...

http://www.phoronix.com/vr.php?view=MTE3MjI

[RealNC]

I think you forgot to tell us why? The other subsystems being more advanced isn't really a reason, IMO.

[Nogotheg]

I hope he will propose working alternatives for us unfortunate enough to have computers with poulsbo graphics.

[Gusar]

I hope he will propose working alternatives for us unfortunate enough to have computers with poulsbo graphics.

Does the gma500_gfx driver not work? From what I know it does.

[GreatEmerald]

Does the gma500_gfx driver not work? From what I know it does.

In my case, last time I checked, it worked but couldn't turn off the screen. And that's quite an important thing to have...

[curaga]

What is it with these lately... No, the DRM FB emulation is not even close to par to the actual fb drivers. v4l doesn't even attempt to support fbdev api.

Either might be a better API on its own, but programs aren't going to port themselves. There are these things called "existing usage", "backwards compatiblity", etc etc which all this calls to deprecate something lately seem to not to have heard of.

[curaga]

*all these

Editing still broken...

[Delgarde]

There are these things called "existing usage", "backwards compatiblity", etc etc which all this calls to deprecate something lately seem to not to have heard of.

Deprecating something doesn't break compatibility or existing usage, doesn't mean it will disappear overnight. It simply identifies it as not having a long-term future, advising developers that they should migrate away from it. There's stuff in Java 7 that's been deprecated since 1.0, and likewise, some of the functions removed in Gtk+ 3 had been deprecated for most of the ten-year lifespan of Gtk+ 2...

[pq__]

Fbdev is a public ABI between the kernel and the user space. That stuff is the most difficult (by the rules) stuff to change or drop in the world of Linux. That means, that if the decision was made today to drop fbdev completely, it will then take at least several years, before the first signs of actual removal in the code base could be done. Those are simply the kernel rules. You cannot break existing user space.

Just like what Delgarde said above.

[dfx.]

What is it with these lately... No, the DRM FB emulation is not even close to par to the actual fb drivers. v4l doesn't even attempt to support fbdev api.

Either might be a better API on its own, but programs aren't going to port themselves. There are these things called "existing usage", "backwards compatiblity", etc etc which all this calls to deprecate something lately seem to not to have heard of.

well, i've heard about how they like all that "existing usage" and "backwards compatiblity" stuff in the world of Windows?, and how that makes it a steaming pile of decomposing shit, so thank you, but i would prefer fot this deprecation to start someday and actually happen, or otherwise no change will be made at all.