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.

[SystemCrasher]

DRM/KMS drivers become more dominant in the embedded world.

Actually it seems it is already the case, many SoCs have got their DRM/KMS drivers or there is work in progress to do so. And honestly, fucking shame on any SoC vendor/devs who do not implement KMS/DRM for their HW. This puts hell a lot of limitations on SoC use.

[SystemCrasher]

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.

Btw, user-mode splash screen implies inherent difficulties, which are difficult to fix. Look, at very least, we start kernel, it decompresses (at this point no splash). Then it have to mount filesystem, launch init and it would eventually kick plymouth. But it could be say initrd and plymouth may or may not be here, deferring splash appearance even further. Eventually this folly comes to behavior like this: system does load of heavy/slow actions before kicking plymouth. Then it kicks in, but system is switching to xorg already, so it isn't big deal. lol. The result is black screen most of time almost suddenly replaced by xorg. Oh, maybe you'll see plymouth for a second or two. Or maybe not. Either way it sucks.

Now let's take a look on kernel side. It could show splash soon after kernel has decompressed. Ideally without waiting for mounting something or loading external files, especially indirectly, by init, etc. So there is room to display it much earlier. Instead of nasty black screen.

Furthermore, even uboot could do it. It is really strange Linux kernel lacked this ability so long.

[Adarion]

Interesting. They're reasoning - as far as I see it - quite correctly with some old FB drivers to be the best common denominator for all chips. And yes, a lot of chips still does (sadly) not have a KMS driver. But then, does SuSE still offer x86_32 builds? Cancelling 32bit but still messing with GPUs that don't even have a KMS driver. Sounds a bit contradictory to me, but hey, whatever...

But then, it's just a nasty splash screen that hides all the important info during boot...

(I'm running Gentoo on "ancient" x86_32 platforms, some without KMS drivers as well as amd64 with Polaris chip and the likes, so I have all of them here. Without any splash screens. I want to see the errors in case they happen!)

[Charlie68]

Btw, user-mode splash screen implies inherent difficulties, which are difficult to fix. Look, at very least, we start kernel, it decompresses (at this point no splash). Then it have to mount filesystem, launch init and it would eventually kick plymouth. But it could be say initrd and plymouth may or may not be here, deferring splash appearance even further. Eventually this folly comes to behavior like this: system does load of heavy/slow actions before kicking plymouth. Then it kicks in, but system is switching to xorg already, so it isn't big deal. lol. The result is black screen most of time almost suddenly replaced by xorg. Oh, maybe you'll see plymouth for a second or two. Or maybe not. Either way it sucks.

Now let's take a look on kernel side. It could show splash soon after kernel has decompressed. Ideally without waiting for mounting something or loading external files, especially indirectly, by init, etc. So there is room to display it much earlier. Instead of nasty black screen.

Furthermore, even uboot could do it. It is really strange Linux kernel lacked this ability so long.

I explained myself badly, my intervention was in response to the user Awesomeness, I share everything you wrote and I am grateful to the developer of Suse for the work he is doing. I'm Italian and sometimes my English gets messed up.

[ruff]

I'd rather focus on instaboot. I don't have any ugly splashstuff and switching from grub to xDM looks natural to me. Oh yes, there're some kernel messages in between but i never even managed to read them through.

[starshipeleven]

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

Plymouth is broken since years, one way or another, depending on whatever thing each distro tried to do to workaround its issue of the week.

[starshipeleven]

Interesting. They're reasoning - as far as I see it - quite correctly with some old FB drivers to be the best common denominator for all chips. And yes, a lot of chips still does (sadly) not have a KMS driver. But then, does SuSE still offer x86_32 builds? Cancelling 32bit but still messing with GPUs that don't even have a KMS driver. Sounds a bit contradictory to me, but hey, whatever...

If they want to get this merged asap they must make sure to sway all support they can. Embedded devs will like a lot this feature, but embedded may or may not have KMS drivers. For x86 it's irrelevant, you can use whatever.

But then, it's just a nasty splash screen that hides all the important info during boot...

It's meant to be deployed to hide stuff from users that can't understand it anyway. And it's optional.

So yeah, it's more choice, all win, none loses.

[Charlie68]

It would be interesting to understand when we could have a preview in Tumbleweed of the new splash screen.

[Zan Lynx]

Plymouth is broken since years, one way or another, depending on whatever thing each distro tried to do to workaround its issue of the week.

Seems to work perfectly in Fedora.