Fedora 30 To Finish Polishing Off Their Flicker-Free Boot Experience

[phoronix]

Phoronix: Fedora 30 To Finish Polishing Off Their Flicker-Free Boot Experience

Fedora 29 succeeded at a long elusive and rather mystical flicker-free boot experience that has continued to improve since release. With Fedora 30, that flicker-free boot experience should be in even better standing...

http://www.phoronix.com/scan.php?page=news_item&px=Fedora-30-More-Flicker-Free

[Girolamo_Cavazzoni]

On my laptop (Intel GPU) it works as intended with the expected interruption when I have to enter the LUKS passphrase. On the other hand on my desktop computer the POST logo isn't even shown in the monitor's native resolution, this is why I guess a flicker-free transition will never be possible (AMD GPU).

[finalzone]

AMD part for flickering free hasn't been started yet unless someone is doing it already

[Luke]

I just found a way to not only get Plymouth to work with the AMDGPU driver, but also to remove the flicker between the Grub background I use and the Plymouth background I use, both of which are copies of my desktop background. Not a UEFI machine and no way to flash the image in as a boot logo to the firmware, and still have to take one flicker as X starts.

For AMDGPU on Southern Islands, I had to force AMDGPU on the kernel command line, which breaks Plymouth normally, leaving Plymouth hung but passphrase entry working silently. I then modified my /etc/dracut.conf (I use dracut) to exclude all the DRM drivers from the initramfs and added GFX_PAYLOAD_LINUX=keep (think that's correct but I am on the road and don't have the file right now) in /etc/default.grub and already have grub set to force a 1920x1080p resolution. With Linux 4.20, this gives the GRUB background persisting until Plymouth silently writes the same background over it, so the appearance is that the passphrase dialog is drawn over the same image. A flicker theoretically exists but is invisible.

I had to reduce the plymouth timeout on looking for DRM drivers to 1 second so it would find the framebuffer(which needs less than that but not zero to start) but not wait for the non-existant DRM drivers. When Lightdm starts the modeswitch and DRM driver load takes place (pretty sure this is a delayed KMS load that looks like a UMS start), and I get a slightly but barely noticeably slower startup of X as the DRM driver also has to start.

If the boot logo on the firmware could be changed to my desktop background), I would be in turn able to have GRUB silently draw over that, and the whole boot would flicker only when the DRM driver and X start up. Normally Plymouth does not work with AMDGPU at all, but by treating it like an Nvidia driver at boot I got this to work and work very well

[caligula]

Uefi is not good for Linux when you can copy your OS to a new disk.

Does not parse. You can clone uefi using Linux just as easily. the EFI system partition is just a FAT partition with a special id.

Use MBR for easier maintenance and faster boot.

A hard limitation of 4 primary partitions results in easier maintenance? Faster? Got any proof? Ever tried the UEFI fast boot modes? It is MBR/legacy boot compatible?

Systemd hides things under uefi firmware loading. Hiding things is good for buggy fedora and intel gpu drivers.

What does it hide?

Decades old Bios API is stable while Uefi implementatios can vary and be buggy.

So you think they are using the same BIOS binary for modern motherboards?

To disable Debian Efi installer when using simple-cdd, have export BOOT_METHODS="BIOS" in you conf file in the profiles folder.

How about no?

[V10lator]

Show us the web link that works 100% when you want to copy your old efi disk to a new disk.

You need a link for that? With legacy BIOS you have to create a new boot partition, copy the files and copy the MBR, with UEFI you need to create a EFI partition and copy the files... For both you can do direct disc clones (i.e. dd). Now tell us why it's more simple with legacy BIOS.

With uefi, you have the firmware loading time. It was 15 seconds for me and it is the time from the power button press to the kernel startup. Really stupid to use the term firmware loading time.

With BIOS you have firmware loading time, too, systemd-analyze is just unable to show it as there's no BIOS API to get it. In fact firmware loading time should be higher as CSM has to be loaded. So your Benchmarks are biased from the beginning.

Systemd hides entropy calculation and that is solved by installing the haveged package. Did not notice that until I started to use a MBR disk. Systemd starts a lot of internal services that you see with systemd-analyze dot. Redhat stuff is like windows, hiding things to make the maintenance harder.

How did you notice it only by switching to MBR? What has systemd-analyze to do with that? Could you show us a diff of dmesg with MBR and EFI?

BIOS has a long history and better compatibility. It is simpler than UEFI and more standardized. Modern motherboards do have support for old BIOS.

The support is done by CSM - Compatibility Support Module. This is a EFI binary translating BIOS API to EFI API which means with it enabled there's more running between OS and bare metal than without and UEFI is still doing the heavy work. How can that translate to less bugs?

[caligula]

With BIOS you have firmware loading time, too, systemd-analyze is just unable to show it as there's no BIOS API to get it. In fact firmware loading time should be higher as CSM has to be loaded. So your Benchmarks are biased from the beginning.

Exactly. One can't magically turn off UEFI from a modern PC unless replacing the ROM with CoreBoot or something.

[towo2099]

What you all forget, it's debianxfce, so it's a waste of time telling him facts. He knows everything better, all of you here, since he is the greatest software developer and debian user.

[uid313]

Fedora still uses X.Org Server?
They don't default to Wayland yet?

[arokh]

What you all forget, it's debianxfce, so it's a waste of time telling him facts. He knows everything better, all of you here, since he is the greatest software developer and debian user.

Yes and don't forget he compiled his own non debug kernel from amd wip tree and also has oibaf mesa. Better give up any discussions as we are dealing with the best here.