lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 20 Dec 2017 17:52:20 +0100
From:   Max Staudt <mstaudt@...e.de>
To:     Ray Strode <halfline@...il.com>
Cc:     b.zolnierkie@...sung.com, linux-fbdev@...r.kernel.org,
        michal@...kovi.net, sndirsch@...e.com, oneukum@...e.com,
        tiwai@...e.com, dri-devel@...ts.freedesktop.org,
        "Linux-Kernel@...r. Kernel. Org" <linux-kernel@...r.kernel.org>,
        Bero Rosenkränzer 
        <bernhard.rosenkranzer@...aro.org>, philm@...jaro.org
Subject: Re: [RFC PATCH v2 03/13] bootsplash: Flush framebuffer after drawing

On 12/20/2017 04:35 PM, Ray Strode wrote:
> Hi,
> 
>> Actually, I don't want that :)
>>
>> This was a design decision that I've made to keep the code small and simple to audit.
>> As it is, the simple bootsplash code will make 99% of people happy.
> You think only 1% of linux users have more than one monitor or a 4k screen?

No, I think 99% will be glad to see a splash at all, and it's a 99% probabililty that the splash will look alright on at least one screen, if not more.

By the simple virtue that dual-monitor setups tend to use identical screens, it's okay if these are cloned while the splash is shown. So maybe 95% of these users are fine, as well.

As for 4k screens - a logo that looks okay on 800x600 will probably look fine, even though it's physically smaller, on a 4k screen.


If there really, really, really is a need, HiDPI can be retrofitted to the format later on.


>> I've made this decision from the point of view of someone who wants to ship a general
>> purpose distribution. If you have a look around and compare this to e.g. the Windows or
>> Mac OS X bootsplashes, the possibilities that my kernel code provides already
>> surpasses them.
> I haven't looked specifically, but I don't believe you :-)  You're
> telling me the apple boot
> splash isn't scaled up on machines with retina displays?  I don't use
> OSX (or windows),
> so I don't know, but I'd be really surprised.

Admittedly, my knowledge is aging as well. My pre-retina MacBook certainly didn't scale anything.

And Windows XP booted in 640x480, then went black, switched modes, and drew the desktop.


>> If you really want such sophisticated features, supplanting the initial bootsplash  with
>> Plymouth (or not using it at all) is a better solution. In my opinion, it is overengineering,
>> at least for kernel code.
> disagree..it's support for basic, commodity hardware these days.

Hmm. I guess it's a matter of taste, and we have to agree to disagree on this one. See above.

Also, like pointed out in the other email, it's meant as an alternative to Plymouth. Maybe I should have made this clear from the beginning - it's an option, not a replacement. We're in the FOSS ecosystem after all, where it's all about choice, and that choice exists because we admit that sometimes, not everyone can be made happy with the same solution.


>> As for HiDPI, if you're working on an embedded device with a fixed screen size -
>> say a phone - you can easily include a huge picture the size of the screen in the
>> bootsplash.
> I'm talking about a situation where you have a dell xps or whatever
> with an external
> monitor attached.  Each monitor should be able to show the splash
> without deforming
> it, and without making it huge or microscopic. pretty basic stuff...
See above. I doubt any other system cares.

And we can't even care before native driver KMS comes up, which may take a while, depending on the system.

I'd like to have this as an alternative to Plymouth in such setups.



Max

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ