[systemd-devel] [PATCH v2 6/8] add GOP mode setting and splash drawing support

[Joonas Lahtinen]

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 <kay at vrfy.org> wrote:
>> On Tue, Dec 10, 2013 at 10:23 AM, Joonas Lahtinen
>> <joonas.lahtinen at 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
>