Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

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

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

    As we've been covering since the original patches back in October, SUSE has been working on a very interesting in-kernel bootsplash system. It's growing into an interesting alternative to the user-space-based Bootsplash, but one of the leading common criticism of it is the use of FBCON rather than interfacing with the DRM/KMS APIs...

    http://www.phoronix.com/scan.php?pag...sh-FB-Over-DRM

  • #2
    Originally posted by phoronix View Post
    It's growing into an interesting alternative to the user-space-based Bootsplash,
    Do you mean Plymouth?

    Comment


    • #3
      Originally posted by tildearrow View Post

      Do you mean Plymouth?
      Yep thanks.
      Michael Larabel
      http://www.michaellarabel.com/

      Comment


      • #4
        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.

        Comment


        • #5
          Would KMS even work for people on NVidia drivers?

          Comment


          • #6
            Originally posted by matthewtrescott View Post
            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, ...

            Comment


            • #7
              Originally posted by RealNC View Post
              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.

              Comment


              • #8
                Originally posted by Hibbelharry View Post

                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.

                Comment


                • #9
                  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.

                  Comment


                  • #10
                    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.

                    Comment

                    Working...
                    X