Mark Kettenis <mark.kettenis@xs4all.nl> wrote:

> Right.  The whole idea here was that the driver would take over the
> firmware framebuffer and preserve it.  That is how other Sun
> framebuffers work.

I don't know if Ted has a sparc64 to see this in action.  It is quite
pretty.  SunOS always managed to preserve the display's layout consistantly
all the way from poweron, through the bootblocks, and into the kernel
without glitches.  Mark tried to do the same in OpenBSD sparc64.  It was
easy with early drivers but in the pci drm generation it becomes more
difficult.

But of course we don't do this on any other platform.  On a modern x86
laptop we can have 3-4 different visual phases which are different.  The
qualcomm arm64 laptops are even less consistant, with the boot text
showing up on the BIOS splash screen incorrectly, one line is at the
wrong place, some machines it starts to scroll, etc etc.  We then
proceed into the kernel with a different visual layout, and when the drm
layer initializes it clears the screen and jarringly jumps to a 4th, or
potentially 5th layout...

We can see that other operating systems are also trying to be consistant
on x86.  Not just windows and macos, but also the Linux systems are
managing it.

It would be prettier if this goal was met consistantly.  But of course
it is more important for the drivers to work correctly, first.