Why SUSE Is Using FBCON Rather Than DRM/KMS For Their In-Kernel Boot Splash

[Yoshi]

I'm currently struggeling with an embedded device at work, among other things also with a decent splash screen/bootlogo. I really appreciate the work of Max because it will make my life much easier if it gets merged. I don't care about KMS and stuff in this project because we use direct FB access and that's why it would be really helpful to have such a mechanism for displaying a bootlogo.

[Charlie68]

We'll see that, as far as I'm concerned, Plymouth has been broken for years on all distributions. If instead of criticizing every project, doing something would be good for the entire Linux universe. Instead in 2017 we have a ridiculous splash screen.

[Awesomeness]

Plymouth is broken since years on openSUSE: https://www.reddit.com/r/openSUSE/co...in_tumbleweed/

I doubt a company that messes even Plymouth up can do a working new boot splash.

[Thaodan]

No, not as long as the binary blob from nvidia is used and it's not beeing changed. There is no good way to cater for Nvidia users and their alien driver, caused by missing driver features, so you can't care. Nvidia users are second class citizens these days.

But it does the blob supports KMS even early KMS.

[Hibbelharry]

Would KMS even work for people on NVidia drivers?

No, not as long as the binary blob from nvidia is used and it's not beeing changed. There is no good way to cater for Nvidia users and their alien driver, caused by missing driver features, so you can't care. Nvidia users are second class citizens these days.

[rene]

Presumably this could allow drawing the bootsplash over the vendor logo like Windows does on UEFI. I recall that that info is exported via ACPI somehow. But that would depend on efifb, which means preventing loading of e.g. inteldrmfb, which means ugliness when finally switching to KMS when the display manager comes up. Maybe the solution would be to have a KMS equivalent of efifb. But then, how would this be any better than Plymouth? Maybe it's good for embedded use-cases but I can't really see how it would solve the flickering, etc. that people blame on Plymouth (though I've never seen that myself).

Then, assuming any flickering caused by switching to KMS for the display manager is solved by this project switching to KMS itself, how will smooth transition to the DM work? I assume Plymouth relies on dbus for that, and unless BUS1 and the dbus<-->BUS1 broker become mainstream, this bootsplash won't be able to emulate Plymouth very easily at all.

No need to depend on efifb, many platforms export the low level address, stride, bits, ... even on SPARC, and PowerPC and such. Could still be a simple early FB API for all of them until the real X server / Wayland takes over, ...

[RealNC]

Would KMS even work for people on NVidia drivers?

[matthewtrescott]

Presumably this could allow drawing the bootsplash over the vendor logo like Windows does on UEFI. I recall that that info is exported via ACPI somehow. But that would depend on efifb, which means preventing loading of e.g. inteldrmfb, which means ugliness when finally switching to KMS when the display manager comes up. Maybe the solution would be to have a KMS equivalent of efifb. But then, how would this be any better than Plymouth? Maybe it's good for embedded use-cases but I can't really see how it would solve the flickering, etc. that people blame on Plymouth (though I've never seen that myself).

Then, assuming any flickering caused by switching to KMS for the display manager is solved by this project switching to KMS itself, how will smooth transition to the DM work? I assume Plymouth relies on dbus for that, and unless BUS1 and the dbus<-->BUS1 broker become mainstream, this bootsplash won't be able to emulate Plymouth very easily at all.

[Michael]

Do you mean Plymouth?

Yep thanks.

[tildearrow]

It's growing into an interesting alternative to the user-space-based Bootsplash,

Do you mean Plymouth?