On 12/31/2017 01:44 PM, Alan Cox wrote:
>> So fundamentally I don't think an in-kernel bootsplash is a bad idea.
>> But most likely you want this on a highly embedded system, which
>
> It wouldn't be in kernel on such a device, it'll be in the bootstrap
> before (or on a dual core device quite pos
On 12/31/2017 01:35 PM, Alan Cox wrote:
> For embedded every KB counts. That is likely to remain the same for some
> time because at the end of the day small devices are constrained about the
> amount of SRAM you can put on die and the amount of power you can afford
> for DRAM.
Fascinating, thank
On 12/29/2017 06:13 PM, Jani Nikula wrote:
> I think the first issue is the boot manager (e.g. grub) messing up
> whatever the BIOS or GOP or whatever drew. If I don't touch any buttons,
> I'd prefer the Lenovo or VAIO or NUC or whatever logo stay there. IIRC
> some BIOSes let you set up your own s
> So fundamentally I don't think an in-kernel bootsplash is a bad idea.
> But most likely you want this on a highly embedded system, which
It wouldn't be in kernel on such a device, it'll be in the bootstrap
before (or on a dual core device quite possibly while) the kernel data is
being uncompress
On Tue, 19 Dec 2017 19:40:12 +0100
Max Staudt wrote:
> On 12/19/2017 06:26 PM, Daniel Vetter wrote:
> > On Tue, Dec 19, 2017 at 6:04 PM, Max Staudt wrote:
> >> Well, those could enable fbcon if they want the bootsplash. Shouldn't make
> >> a difference anyway if they're powerful enough to run
On Tue, 19 Dec 2017, Daniel Vetter wrote:
> On Wed, Dec 13, 2017 at 08:47:42PM +0100, Max Staudt wrote:
>> Dear fbdev and fbcon developers,
>>
>> Thank you very much for your input for the first patch series.
>>
>> I've included your feedback into this second roll, and kindly ask for
>> your opi
Hi Max,
from Manjaro-side we have implemented it now in our v4.14 kernel series
and started to test out some themes. Current progress and feedback may
be found in our forum:
https://forum.manjaro.org/t/bootsplash-provided-by-the-kernel/34467
Best, Philip
On 12/21/2017 10:48 AM, Daniel Vetter wrote:
> Ok, here's my expectation:
>
> - fix plymouth and driver loading
>
> If the plymouth maintainer tells me that's impossible, I'll look at this
> again. And no, this does not require killing drivers with SIGBUS, at least
> not with drm. Meanwhile I don
On 12/21/2017 03:51 PM, Ray Strode wrote:
> Hi,
>
> On Wed, Dec 20, 2017 at 11:44 AM Max Staudt wrote:
>> It'd be nice to see this bug fixed, as it happens only occasionally (as is
>> the nature of a
>> race condition), and was thus really hard to debug. I'm sure it can drive
>> people insane,
Hi,
On Wed, Dec 20, 2017 at 11:44 AM Max Staudt wrote:
> It'd be nice to see this bug fixed, as it happens only occasionally (as is
> the nature of a
> race condition), and was thus really hard to debug. I'm sure it can drive
> people insane,
> as they try to find out whether they've disabled C
On Wed, Dec 13, 2017 at 08:47:42PM +0100, Max Staudt wrote:
> Dear fbdev and fbcon developers,
>
> Thank you very much for your input for the first patch series.
>
> I've included your feedback into this second roll, and kindly ask for
> your opinion on the new patch series.
>
>
> Changes from
On Wed, Dec 20, 2017 at 11:22:36AM +, Daniel Stone wrote:
> > Also plymouth grabs the escape character of HPE iLOs, which is a serious
> > no-go.
>
> I'm not entirely sure what this means, but maybe it's best addressed
> as a bug report to the Plymouth developers? One of them is in this
> thre
On Tue, Dec 19, 2017 at 05:16:30PM +0100, Daniel Vetter wrote:
> Ok I've realized that my assumptions about why you need this aren't
> holding up.
>
> So from reading these patches it sounded like you want an in-kernel boot
> splash because that would be on the display faster than a userspace one
On 12/20/2017 04:21 PM, Ray Strode wrote:
> If we've reached the scenario you're discussing above, the real
> failure is that the KMS
> driver took too long to load. DRM is the platform graphics api. If
> it's not loading
> timely enough to show graphics then that's the problem! It sounds
> like
On 12/20/2017 04:19 PM, Daniel Vetter wrote:
> On Wed, Dec 20, 2017 at 4:11 PM, Daniel Vetter wrote:
>> On Wed, Dec 20, 2017 at 3:55 PM, Max Staudt wrote:
>>> On 12/20/2017 11:14 AM, Daniel Vetter wrote:
btw since I'm probably sounding a bit too grumpy here: I'd very much
support this.
On 12/20/2017 04:11 PM, Daniel Vetter wrote:
> So fundamentally I don't think an in-kernel bootsplash is a bad idea.
> But most likely you want this on a highly embedded system, which
> probably is compiled for your exact hw, with pretty much everything
> built in. Also, no fbcon, maybe even no vt
On Wed, Dec 20, 2017 at 4:19 PM, Daniel Vetter wrote:
> On Wed, Dec 20, 2017 at 4:11 PM, Daniel Vetter wrote:
>> On Wed, Dec 20, 2017 at 3:55 PM, Max Staudt wrote:
>>> On 12/20/2017 11:14 AM, Daniel Vetter wrote:
btw since I'm probably sounding a bit too grumpy here: I'd very much
supp
Hi,
> The problem that I am stumbling upon is different:
> - the system starts with an FB driver
> - after the ShowDelay time, Plymouth opens /dev/fb0
> - the system finally loads the DRM driver, which tries to kick the previous
> FB driver
> - loading the DRM driver fails because Plymouth st
On Wed, Dec 20, 2017 at 4:11 PM, Daniel Vetter wrote:
> On Wed, Dec 20, 2017 at 3:55 PM, Max Staudt wrote:
>> On 12/20/2017 11:14 AM, Daniel Vetter wrote:
>>> btw since I'm probably sounding a bit too grumpy here: I'd very much
>>> support this. I think bootsplash in kernel has a bunch of uses, a
On Wed, Dec 20, 2017 at 3:55 PM, Max Staudt wrote:
> On 12/20/2017 11:14 AM, Daniel Vetter wrote:
>> btw since I'm probably sounding a bit too grumpy here: I'd very much
>> support this. I think bootsplash in kernel has a bunch of uses, and it
>> shouldn't be hard to get non-suse people to cheer f
On 12/20/2017 11:14 AM, Daniel Vetter wrote:
> btw since I'm probably sounding a bit too grumpy here: I'd very much
> support this. I think bootsplash in kernel has a bunch of uses, and it
> shouldn't be hard to get non-suse people to cheer for it (makes merging
> easier if it's not just a one-off
On 12/20/2017 11:06 AM, Neil Armstrong wrote:
> My 2cents about this patchset:
> You did a good job about all the animation and splash logic, but for me all
> this fbcon
> stuff is a huge hack, please use a standard and modern display subsystem en
> leave fbcon
> die alone
Thanks for the com
On 12/20/2017 10:43 AM, Daniel Vetter wrote:
> On Tue, Dec 19, 2017 at 07:40:12PM +0100, Max Staudt wrote:
>> On 12/19/2017 06:26 PM, Daniel Vetter wrote:
>>> So essentially you're telling me that on a current general purpose
>>> distro the gfx driver loading is a dumpster fire, and we're fixing
>>
On 12/19/2017 09:30 PM, Ray Strode wrote:
> Hi,
>
>> For example, having a userspace splash that starts as early as it can
>> (thus on vesafb/efifb on a PC) will cause the KMS driver to fail
>> reserving the entirety of video RAM, and thus fail loading. This cannot be
>> fixed.
> well the fix the
Hi Johannes,
On 20 December 2017 at 11:08, Johannes Thumshirn wrote:
> On Tue, Dec 19, 2017 at 05:16:30PM +0100, Daniel Vetter wrote:
>> Ok I've realized that my assumptions about why you need this aren't
>> So from reading these patches it sounded like you want an in-kernel boot
>> splash becaus
On Wed, Dec 20, 2017 at 11:06:34AM +0100, Neil Armstrong wrote:
> On 20/12/2017 10:43, Daniel Vetter wrote:
> > On Tue, Dec 19, 2017 at 07:40:12PM +0100, Max Staudt wrote:
> >> On 12/19/2017 06:26 PM, Daniel Vetter wrote:
> >>> On Tue, Dec 19, 2017 at 6:04 PM, Max Staudt wrote:
> Well, those
On 20/12/2017 10:43, Daniel Vetter wrote:
> On Tue, Dec 19, 2017 at 07:40:12PM +0100, Max Staudt wrote:
>> On 12/19/2017 06:26 PM, Daniel Vetter wrote:
>>> On Tue, Dec 19, 2017 at 6:04 PM, Max Staudt wrote:
Well, those could enable fbcon if they want the bootsplash. Shouldn't make
a dif
On Tue, Dec 19, 2017 at 07:40:12PM +0100, Max Staudt wrote:
> On 12/19/2017 06:26 PM, Daniel Vetter wrote:
> > On Tue, Dec 19, 2017 at 6:04 PM, Max Staudt wrote:
> >> Well, those could enable fbcon if they want the bootsplash. Shouldn't make
> >> a difference anyway if they're powerful enough to
Hi,
> For example, having a userspace splash that starts as early as it can
> (thus on vesafb/efifb on a PC) will cause the KMS driver to fail
> reserving the entirety of video RAM, and thus fail loading. This cannot be
> fixed.
well the fix there is to use drm devices... like this:
https://cgit
On 12/19/2017 06:26 PM, Daniel Vetter wrote:
> On Tue, Dec 19, 2017 at 6:04 PM, Max Staudt wrote:
>> Well, those could enable fbcon if they want the bootsplash. Shouldn't make a
>> difference anyway if they're powerful enough to run Linux. As long as the
>> bootsplash is shown, no fbcon drawing
On Tue, Dec 19, 2017 at 6:04 PM, Max Staudt wrote:
> On 12/19/2017 05:16 PM, Daniel Vetter wrote:
>> On Wed, Dec 13, 2017 at 08:47:42PM +0100, Max Staudt wrote:
>>> Dear fbdev and fbcon developers,
>>>
>>> Thank you very much for your input for the first patch series.
>>>
>>> I've included your fe
On 12/19/2017 05:16 PM, Daniel Vetter wrote:
> On Wed, Dec 13, 2017 at 08:47:42PM +0100, Max Staudt wrote:
>> Dear fbdev and fbcon developers,
>>
>> Thank you very much for your input for the first patch series.
>>
>> I've included your feedback into this second roll, and kindly ask for
>> your opi
On Wed, Dec 13, 2017 at 08:47:42PM +0100, Max Staudt wrote:
> Dear fbdev and fbcon developers,
>
> Thank you very much for your input for the first patch series.
>
> I've included your feedback into this second roll, and kindly ask for
> your opinion on the new patch series.
Ok I've realized tha
Unfortunately I've forgotten to rebase this patchset to 4.15, so it still
builds on top of 4.14.
I'll rebase it for the next roll.
Max
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
34 matches
Mail list logo
