Announcing flicker-free boot for Fedora 29
hansdegoede.livejournal.com
hansdegoede.livejournal.com
My Ubuntu 16.04 machine does this weird thing where it shows my login in 1/4 of the screen then suddenly it stretches to fill. Really sets the tone for how janky the experience is going to be.
The startup experience sets the tone for the entire thing. I know some engineers who won't get why it's a big deal. It's a _big_ deal.
OSx does the same thing, but hides it all behind a single load screen, as if all of those elements from hardware to DE were a monolithic "mac".
It feels like lying to the user to me. Bios isn't in control anymore, why is the motherboard logo still on the screen? How do I know when the OS takes over from grub if both are hidden under the motherboard logo?
I understand I'm completely out of touch with how normal people use computers. I don't care.
What's wrong with dmesg?
Personally, I wish serial-over-USB (and serial-over-Lightning) cables were more common. (I don't mean that they're expensive—they're dirt cheap. It's just that nobody has any idea they exist.)
They used to be a kind of arcane thing—why would you need serial access over USB when the PC already has a serial port? And why are you debugging a PC on another PC—(taking up a quite lot of space on your desk, eh?)—when you could instead debug the PC on the PC itself?
But these days, almost nothing has a serial port, and we have perfect "secondary PCs" to serve as the recipient of the serial input: our phones and tablets. (Heck, they probably have space reserved for them on your desk already!)
Imagine: sit an iPad or some cheapo Android tablet below your monitor. Plug the "send" end of the serial-over-USB cable into the USB hub built into your monitor. Plug the "receive" end of the cable into your tablet. Open a terminal-emulator app on your phone/tablet. Bam: console logs, flowing along below your PC, as needed.
Best of all, it's not unidirectional; your phone/tablet is now a VT100, and you can log into your computer over it, even if the display server or login manager or desktop environment is wedged.
If owning these little cables was common, I'd honestly suggest just turning off the Linux text-console virtual framebuffers entirely for the Desktop versions of distributions. You want to see what's going on underneath the gloss? Tap in.
And wanting to interact is the least of the reasons to not want to hook up an external screen for something that could easily be on your main screen.
In a lot of these cases, it should be pretty obvious that there are also no permanent input peripherals attached to the target device, and perhaps not enough ports to conveniently plug them in.
So, tell me what’s more convenient: lugging a secondary display, mouse and keyboard around to plug into your devices to debug them? Or just plugging your laptop into the server and opening a terminal emulator?
The advantages of serial access are exactly the same as the advantages of SSH access, except that serial access doesn’t require an active network stack and daemon running to facilitate it, and so is usable even in a post-crash single-user mode, or in an unable-to-begin bootstrap stage.
Plus, with serial, the solution is universal—anything that supports serial output can be attached to anything that supports serial input. Whereas those peripherals aren’t guaranteed to do anything much if you plug them into a crashed PC.
Oh, and one more advantage: if you’ve ever tried writing your own kernel driver or unikernel (or game on a game console), you’ll have experienced the fact that a kernel crash that happens while the display is in graphical mode is very hard to get displayed on the screen, since you can’t know what subsystems (like the framebuffer, or the scheduler) are still in a valid state. Spewing lines onto the serial console, on the other hand, works perfectly. (And for this sort of development you can usually go even further, producing a debug build of your kernel or game that will crash into a debugger breakpoint accessible via the serial console, expecting something like gdb to be running on the other end of the serial connection. The main difference between a game console and its development kit is basically the presence of serial debugging.)
>In a lot of these cases, it should be pretty obvious that there are also no permanent input peripherals attached to the target device, and perhaps not enough ports to conveniently plug them in.
You are now describing almost the opposite of your original scenario, which was plugging ancillary devices into a PC to see the kernel messages of the PC.
>So, tell me what’s more convenient: lugging a secondary display, mouse and keyboard around to plug into your devices to debug them? Or just plugging your laptop into the server and opening a terminal emulator?
That's a weird response when I was the one arguing for having one screen instead of two.
> Oh, and one more advantage: if you’ve ever tried writing your own kernel driver or unikernel
Oh of course but that's <1% of the time.
I think it's fair to say that in general, users want to be lied to. That's why UX patterns like screenshots of suspended apps being displayed while the app actually loads became standard. The appearance of speed is effectively as valuable as actual speed, just like the appearance of polish is valuable regardless of the cruft that lies beneath it.
The suspended app screenshot is way more that appearance. We all need a moment to remember to context of what we were doing. Showing us a screenshot of the suspended state enables us to use the loading time productively so that we are immediately ready to interact once it's up.
The speaker was vital to inform the user as to what was happening. If the phone line was in user, if there was a dialing problem, if you called the wrong number, etc. And it also gave you an indication of the connection speed and line quality.
Pressing a key to get the "full dump" is in fact how plymouth works, which many Linux distributions use from the kernel up until gdm/display-manager.
The only time I want to see these handoffs and a ugly text dump is when things are broken and I’m debugging it, which should never happen anyway.
Why do we expect such mediocrity out of our software?
Experience
A ridiculous amount of modern products have gained a boot sequence that should not need one, and didn't used to. Hiding it doesn't fix the real issue.
five seconds, year 2008: https://lwn.net/Articles/299483/
two seconds, year 2017: https://www.youtube.com/watch?v=IUUtZjd6UA4&t=17
"The major difference between a thing that might go wrong and a thing that cannot possibly go wrong is that when a thing that cannot possibly go wrong goes wrong it usually turns out to be impossible to get at or repair." -Douglas Adams
I do also turn off the splash screen in linux so that I can watch the service startups fly by.
There is nothing stopping any of these components from changing the display framebuffer. The "news" here, so to speak, is that finally we'll have things working where you can avoid any buffer changes and simply start drawing on the old background.
If you want, you could have grub2/etc change the framebuffer and now that could persist up to the gdm hand-off.
What this is doing is telling the driver to ignore it's normal reset procedure because someone else, but specifically not you, has already done the super complex modesetting and you are to trust it implicitly.
So next year, when the sales people come up with the idea that they want to show an animation across all your DisplayPort chained monitors at boot, the guys at Apple buckle down for a month, hack that into the bootloader and then hack their kernel to recognize it, ships the same year. On Linux, for the first ten years, nobody cares because there are much larger fires to put out, then ten years are spent on a vendor and display technology agnostic VR ready boot up animation description format, ten more years pass for a critical mass of boot firmware and kernel graphics drivers to support it, then it ships with Ubuntu but every third boot has flicker or a weird rotation issue.
But mumbled sheared terminal output is none of that.
Every distinct piece of Apple's boot process (firmware, boot loader, kernel, desktop) can have the correct video driver, be aware of the desired final video resolution, and trust that any previous piece has left the video card in the proper state. It all ships together.
The PC BIOS doesn't know you want 2560x1600 for your desktop. It just picks a mode suitable for the BIOS. If anything, the BIOS is required to leave the screen in VGA text mode. The boot loader faces the same issue. At best, a Linux distribution might decide to use a VESA mode, but that can't cover the desired 2560x1600. (VESA doesn't go that high)
That's why we switched to UEFI around a decade ago; I'm pretty sure it doesn't have all those problems. So a modern PC can boot directly into the correct resolution.
–Matthew Garrett (he wrote a lot of the Linux kernel UEFI implementation)
Mines an Asus Gene VIII and using a 1080Ti and I don't even get anything appearing at all until the Windows logon.
UEFI graphics drivers usually support much more fine grained modesetting than VESA, assuming you have a native UEFI graphics driver rather than one that's thunking down to a legacy BIOS option ROM. They're also (usually) capable of reading and parsing EDID and will set a native mode if possible. The number of people not running their desktop at their display's native mode is sufficiently low that it's not really worth worrying about.
In fact, I think you could choose to set it up this way from the Ubuntu installer directly. By default, it just encourages you to sign in manually in addition to setting up FDE.
EDIT: To clarify, my setup requires inputting passwords twice: once for decrypting the root partition, and once to login after everything has booted. During the boot process the system needs to remount everything, so I had the encrypted partition(s) also be decrypted with a key file (typically `dd if=/dev/urandom of=keyfile bs=1M count=4`; LUKS encryption can have multiple keyfiles/passwords to decrypt) and had the key file(s) put in the initramfs so after GRUB has decrypted root and loaded /boot/grub.cfg, the booted system could decrypt and mount everything needed with the key file(s).
More than once having the kernel boot visible has helped diagnose hardware failure or other OSI layer 1 issues with the system.
The level of disruption can vary greatly depending on your particular hardware; some external monitors take multiple seconds to show an image after the display mode is changed.
Never seen it with Arch with https://wiki.archlinux.org/index.php/Slock mind
Bad idea, security-wise.
But if the GPU driver is broken about command committal, then there is only so much you can do short of fixing those .
I get the same problem on Fedora, its irritating.
And I hadn't that problem in KDE.
Invariably I miss the fact that the disk-activity light is still lit, start typing my password and then become annoyed because it only caught the last few characters. So then I have to wait AGAIN whilst it proudly announces an authentication failure and punishes me with a further delay.
I got so used to that jankiness that I didn’t notice it until I was showing someone my laptop who was interested in buying the same model.
(there are other security fixes by adopting Wayland)
I've seen this behavior with the old 'gnome-screensaver' (which I think ubuntu hasn't used for quite a while), but with the current gnome-shell lock screen it behaves properly and doesn't black out the screen when I open my laptop.
wow, a lucky person, Ubuntu on my Desktop never wakes up :)
// p.s.: still better than macOS/Windows for development, I just don't turn it off, that's all
Once logged in you get the full 5k. So it's still not 100% over in Mac land. :D
Then again, dependint on the distro, they don't really cater to the average user.
For the most part, though, I just don't notice it. One way or the other.
It didn't happen in early versions on Windows 10. It started with one of the major updates. My guess is if you don't have a screen on when the login page first shows, it down-samples your background image to some low resolution, and then just stretches it out to fit to your actual screen res when you do turn your screen on.
And classic Mac. First time I saw Windows 3.1.1 boot my jaw dropped. What an ugly hack. That’s what’s conquering the world? The monitor wouldn’t even turn itself on. Never mind having to manually eject a floppy after you just told the computer to do it for you.
But- I'd rather they fix a bunch of other things first.
I'd put "things that don't work" in the first todo bucket, then move on to "things that are painful to endure", followed by "things that make it feel janky"
I wanted to use Fedora recently and it totally failed to handle my perfectly common laptop graphics card. Ubuntu did it fine.
I don't think it's a big deal at all. Or rather, I think it's important, but it's the last bit of polish that you put on things after the rest of your house is in order. It's a nice-to-have.
Meanwhile, I installed Debian buster on a 2016 MacBook Pro -- a two year old laptop -- and sound and suspend-to-RAM don't work (hell, the keyboard and trackpad didn't even work at all without installing an out-of-tree driver post-OS-install; I had to do the install using a USB keyboard). Yes, I get that this probably isn't super common hardware, and it's also a bit exotic, but... c'mon. I just don't care if my screen jumps between text and graphics mode or changes resolution a couple times before I get to the login screen. It just isn't on my radar at all.
The Xorg touchpad drivers are a mess: libevent is one-size-fits-none, synaptics is buggy and unmaintained, and the fork of mtrack that's still maintained might be able to come close to something decent, but I'm not sure because I've already spent a couple hours tweaking its settings, and I still can't get it to not randomly send scroll and button events while I'm typing.
So no, I don't care at all about something useless like "flicker free boot". I want my laptop to be actually polished in ways that are functional first.
And I get it: it's not up to me to tell people what to work on during their free time. Everyone has their own itch to scratch, and that's a very personal thing. But to then (as you have) arbitrarily decide that visual polish during a functionally-irrelevant period of the machine's operation is more important than day-to-day functional polish while I'm actually interacting with the machine? Nope... not buying it.
It seems unfair to compare your mac experience on a mac to your GNU Linux experience on a mac.
And I agree with you that the basics need to run well first, but in my experience many common distros got that covered. Debian is one of the exceptions, it's pretty much the only Linux distro where not everything runs fine out of the box on my laptop.
See that "I", that IMO shows you missed the point.
So it's up to me now to tell you: If you want to run Linux on Apple hardware, help getting it to work! Otherwise please just use hardware with Linux supported by its vendor instead of complaining here.
One great thing about open source is that everybody can work on what he needs or what he enjoys. So if people enjoy working on flicker free boot, that's great. Other people enjoy reverse engineering Thunderbolt adapters to get them to work with Linux or dig into the depths of the state machine required for touch pads to properly work. In the end we all benefit from such work, as each little piece gets us closer to the completed puzzle where everything works smoothly.
Flicker-free boot is nice to have, but it's not a _big_ deal.
I can live just fine if the boot flickers twice. But somehow doing animation with tearing for the rest of the work-day is quite a bit more annoying.
UX isn't about what you as a user feel, it's about what users feel, and OP is probably talking about UX for all users, not just those comfortable with Linux and it's tendency to have a janky UI.
But flicking screens or flicking resizing windows are like nails on a chalkboard to some of us.
Or you put on the radio and the first track is random snippets of talking/music/sound at various volumes.
People put luxury goods in expensive packaging for a reason ... and no, _I_ don't like expensive packaging.
(Now, actually a book like that would be intriguing to me, but ...)
I know it looks very polished when all this is hidden. But when something stops working, the repair option might then be hidden as well though. The UX of having a dysfunctional system for days or weeks is even worse. In fact this is the reason I switched to Linux, everything is so much more predictable and transparent. Of course stuff looks more stitched together and sometimes things are harder to get running. But once things are set up properly, it just works and works.
Windows has improved a lot over the years, but still, if you keep an installation over time, you end up having more and more spyware and crappy software on your system, even on the Mac it's advisable to reinstall everything from time to time. This means backing up all data, not forgetting anything and also taking care of App reinstallations. For anyone using Computers for things they depend on, this is nightmarish UX.
Structural expressionism isn't a mainstream design aesthetic; people seem to tend towards minimalism.
This tends to be the general sentiment in both communities (outside of people who recommend that cause it’s all they know, but I wouldn’t listen to them regardless) if you keep good computer/internet hygiene practices and barring any widespread corruption/systemic malware/other external factors.
Aside from that, I’m always a huge advocate for the polished UX. As long as the options aren’t removed, the users who need them will be able to use them perfectly fine, everyone else won’t be offput by them, especially when the need for clean installs is only necessary for specific use cases as I mentioned before and doesn’t come up often at all.
Yes, I know the menu disappears - but that’s only going to be true for some subset of BIOSes, and it’s not an indicator that most people would be expecting.
You know when Windows has started to boot when the distinctive Microsoft spinner appears beneath.
> 2. Write a new plymouth theme based on the spinner theme which used the vendor logo as background and draws the spinner beneath it. Since this keeps the logo and black background as is and just draws the spinner on top this avoids the current visually jarring transition from logo screen to plymouth, allowing us to set plymouth.splash-delay to 0. This also has the advantage that the spinner will provide visual feedback that something is actually happening as soon as plymouth loads.
Another benefit of sbupdate (besides Secure Boot) is that it allows running Linux kernel directly as a UEFI executable, no GRUB or systemd-boot needed!
Like rEFInd?
I have a <3yo laptop that boots NVME OSes fine, Windows and Linux alike ... except for the Windows feature-upgrade process, which just hangs indefinitely on the OEM logo.*
I also have a desktop whose UEFI firmware doesn't output anything to its PCI videocard, and also refuses to boot at all if anything is connected to its integrated videocard. So getting Linux installed on that silly thing at all, was an exercise in frustration.
I furthermore used to have a little "mini PC" that utterly refused to allow its UEFI boot entries to be modified at all - on top of having no boot-time video output and a soldered-on bootable storage. So I had to abandon and rollback my efforts to install Linux on it, lest I brick it. Brick, an x86-based system. Ugh!
In short, I don't respect manufacturers' UEFI firmware any farther than I can defenestrate their products.
-
* I would say something about how imaging from a SATA SSD onto an NVME SSD even required a reinstall of Windows, whereas the dual-booted Linux install worked perfectly; but that's probably just Windows being its usual stupid self.
BIOS vendors support this because otherwise the BIOS boots so fast (with modern system requirements) that they don't get as much branding opportunity.
OS vendors love this because then when you're waiting around for your system to boot, you're looking at the BIOS logo and blaming the BIOS, not the OS.
>BIOS vendors support this because otherwise the BIOS boots so fast (with modern system requirements) that they don't get as much branding opportunity
So that the speed of my computer isn't decided by a marketing team, that's why.
(I would still love to see more open BIOSes, though.)
I'm just wondering if features like this can be used as a carrot/stick for AMD/NVIDIA -- "Hey, look what we can build and provide for Intel customers because their driver devs are at the table."
On a separate note, insert here unending words of praise for the money and effort that Red Hat puts into Linux, and specifically technologies related to Linux on the desktop. systemd/logind, pulseaudio, pipewire, gnome, wayland (including porting various other projects)... all critical stuff that I see go unappreciated sometimes.
Not really - it's more that the functionality for copying the firmware's mode configuration into the kernel exists for the Intel gpu driver and nobody's done the work for the others. I spent a while back in 2011 or so looking at doing this for nouveau but never got things working sufficiently well to merge it.
I recently bought an amd card. I just pop'ed in the card, booted the machine and the mesa drivers included with fedora worked without a hitch. The only thing I had to do was install vulkan to play f1 2017, other than that it has been plug'n'play with good performance.
Some other ideas: a little ball rolling around the infinity logo (maybe eventually rolling back to center and unfolding into the "f"), a pair of "tubes" moving around which occasionally intersect to make the "f" shape, etc. I think this is a good opportunity to do something interesting with the boot screen!
Let the mustard once again indicate progress!
(The Plymouth splash for Beefy Miracle had a friendly hotdog with arms waving at you while a mustard squiggle filled itself in up it’s body. Once the hotdog was fully dressed, you were booted!)
https://media.giphy.com/media/1dHYPKjEW1vKZyBORH/giphy.gif
(the animation is very quick in this gif, on a slow machine the contour of the fedora logo fills up slowly from low left to top right)
sudo nvram boot-args="-v"
The magician engineers at the core of making things like this just work and be pleasant do not get anywhere near the credit they deserve - this is a herculean task to have Just Work(tm) on white box hardware.
Hans deserves a huge thanks from all of us for slogging through this thankless work.
I want to see the scary boot log, I don't need the system to be pretty, I need it to be functional.
If one considers a grub menu to be 'ugly' and wishes to hide it, that is directly at odds to its usefulness.
To me, this is an entirely reasonable behavior that optimizes for the 99% of time where you just want your computer to boot quickly and start using it.
It might require storing the target color as a kernel param, but it might be worth it for the wow factor.
When displays jank and bump and jump it says to ordinary users "this is hard and technical and not really easy and possibly not designed for you".
Glad to hear this magic is coming to Linux too, although as a Ubuntu-user I guess I’ll have to wait a few releases before this is the standard.
The native display kicks in with the login screen. (For some reason, UEFI doesn't initialize my graphics card to the panels native resolution, so the change with the login screen is visible).
This should help with that.
1) Press power 2) Get motherboard/manufacturer logo 3) Switch to a text-based Grub interface 4) Actual Linux kernel starts booting, sometimes flashing some text, sometimes setting a video mode directly 5) Plymouth loads a graphic screen showing an Ubuntu/Fedora/whatever logo, hiding the rest of the kernel loading output 6) The login manager (GDM or something similar) loads, displaying a different background from the previous logo.
Each one of those steps introduces a somewhat jarring "flicker". The new process looks like this:
1) Press power 2) Get motherboard/manufacturer logo 3) Login manager shows up
Personally, I don't care that much about something that only happens during boot. What does bug the crap out of me is how scaling for HiDPI displays is still all kinds of broken and you still get tiny cursors every now and then. Or how some applications decide to ignore which audio sink is currently setup in PulseAudio. Or how battery life is still better in Windows.
Has there been regressions because of architecture changes since then?
The video is using intel's onboard vga chipset which plays extra nice with intel's onboard EFI. You can bet the framebuffer code between the EFI and 3rd party hardware(AMD/NVidia) sucks much, much worse
I expect ServerFault posts about grephic instability in fedora 29 any minute now...
> There have been changes to plymouth to allow pressing ESC as soon as plymouth loads to get detailed boot messages
(with Plymouth being the graphical boot system)
This is a huge deal!
Especially as Fedora moves towards Silverblue (aka Atomic/OSTree) which uses a content-store, hard-link farm, and pivot-root at boot for atomic upgrades.
Systems using A/B partition flipping (such as ChromeOS) would also benefit from this.
There are patches by other desktop team members for chrom(ium), Firefox, and WebKit to work with desktop sharing using Wayland/pipewire but it takes time to get upstream to merge them into their products. Fedora 29, I believe, will be shipping with some of them applied so that even various commercial desktop streaming applications work.