Hi,
Sorry for quite a delay in replying, I've was backpacking in Southeast
Asia for a month, now back working.
On 16.12.2013 00:54, Kay Sievers wrote:
On Sun, Dec 15, 2013 at 2:54 PM, Kay Sievers <k...@vrfy.org> wrote:
On Tue, Dec 10, 2013 at 10:23 AM, Joonas Lahtinen
<joonas.lahti...@linux.intel.com> wrote:
Add support for two new configuration directives gfxmode and splash
which respectively allow setting the screen graphics mode and drawing
splash image during gummiboot execution. See README.gop for more
details.
+ gfxmode 1920x1080
What the reason for that? It looks wrong to require the resolution to
be specified, we need to be able to move disks around between systes
and there are also still systems with external monitors. :)
Maybe I was bit unclear, specifying the resolution is an optional step,
which allows setting the mode of the display to a non-native mode from
the beginning, and that set mode would be kept all the way to the desktop.
This option is mainly there to make certain monitors work that have the
the native mode information wrong or missing (in which case a fallback
list of resolutions is provided by BIOS). As a good example that many
will run into are HDMI-to-VGA adapters (which have not been tested, only
one misbehaving monitor). Use of the i915.fastboot parameter moves the
responsibility of forcing the modeline from kernel to UEFI. So those
monitors could not be used in combination with fast booting if some UEFI
application wouldn't set the correct modeline.
With well behaving monitors, and with intent to run at native
resolution, the option is not needed.
Almost all hardware sets up the native resolution and we should just
query that instead of writing it to disk. What's different on the
machines you work with?
I've implemented very basic BMP support and commited it.
The custom format was there for best possible speed to be achieved when
displaying the splash, as the original use case is extremely time
critical. I will look into the speed differences and see if there's
still need to use the custom format.
Regards, Joonas
There is currently no support for modelines, and unless there is a
good reason, we should not do that. The firmware is expected to init
the native resolution which we should not touch.
Kay
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel