Systemd 230 Opens Up A New Graphics Vulnerability & FBDEV Still Should Die

[SystemCrasher]

This is exactly why I don't want systemd. They introduce a bug and expect others to fix it.

Somehow, that's how software development works everywhere. Systemd isnt't unique in it. Root cause is the fact devs can't foresee everything, neither all use cases, nor all shortcomings, not to mention bugs. So if someone stumbles on bug or shortcoming, it is up to them to deal with it by default. That's how opensource works. OTOH nobody could force you to use systemd, Linux or whatever. You're perfectly free to use whatever. With some little caveat: it could turn out you have to maintain your favorite solution yourself if nobody else steps in. That's how it works.

Because they want systemd to do or don't do something the whole world has to change. Why not let systemd die and keep fbdev?

Nothing wrong with it. Someone have to introduce changes, and it happens all the time. I do not get why systemd devs should be unable to do something like this. Are they second-class citizens, or what? Though in this particular case they did quite strange thing. Still, fbdev appears to be poorly maintained these days. Yet it is eventually used in embedded devices, so it would be nice if there is reasonable replacement. This is especially true for small simplest i2c/spi/... LCDs where full fledged KMS driver looks like an overkill. There were patches floating around to provide simplified layer on top of KMS but it seems they haven't made it so far.

[SilverMachine]

This is exactly why I don't want systemd. They introduce a bug and expect others to fix it. Because they want systemd to do or don't do something the whole world has to change. Why not let systemd die and keep fbdev?

[RahulSundaram]

In some ways Linux was better when the idea was to support as many devices as possible.... Before we kill anymore functionality, can we make sure that there are viable pathways that actually work for everyone? Maybe that's too much to ask (?).

Linux (as in the kernel) still supports as many devices as possible as long as there is a maintainer. The situation is exactly the same for fbdev as well. If you care about this, you either have to ensure that fbdev continues being maintained or the alternative is viable. Can't ask other people to ensure this for you however

[cjcox]

In some ways Linux was better when the idea was to support as many devices as possible.... Before we kill anymore functionality, can we make sure that there are viable pathways that actually work for everyone? Maybe that's too much to ask (?).

[nanonyme]

Instead of killing it, has anyone considered a partial rewrite to fix it?

I understood the point is that the entire API is fundamentally illdesigned. Fixing it would be more effort than just going with KMS

[Ericg]

Please. implement a KMS driver for Geode GX, GX2 and LX before doing that.

Those are AMD SoCs, so they maybe (this is a giant maybe, i dont know what these chips actually look like architecture wise) could hook into the old R300 infrastructure

[Gusar]

You're wrong. That's KMS.

I am not. The console runs on fbdev. It's not and never was KMS that provided the high res console, it was always the fbdev compatibility inside KMS drivers.

[dh04000]

Instead of killing it, has anyone considered a partial rewrite to fix it?

[ihatemichael]

Does your console switch to a higher resolution when gma500 loads? If yes, that's the fbdev compatibility at play.

You're wrong. That's KMS.

[zboszor]

Also, can we just burn down fbdev please ;-)
-Daniel

Please. implement a KMS driver for Geode GX, GX2 and LX before doing that.