[PATCH v4 0/3] console/fbcon: Add support for deferred console takeover

[Hans de Goede]

Hi,

On 27-06-18 11:47, Bartlomiej Zolnierkiewicz wrote:
> On Wednesday, June 27, 2018 11:15:20 AM Daniel Vetter wrote:
>> On Tue, Jun 26, 2018 at 08:36:09PM +0200, Hans de Goede wrote:
>>> Hi All,
>>>
>>> Here is v4 of my patch-set, to delay fbcon taking over the console (and
>>> binding to fbdev devices) until there actually is some text output to the
>>> console. This is intended for use with the "quiet" cmdline option, in
>>> combination with a bootloader which leaves the vendor's logo /
>>> EFI bootgraphics put up by the firmware intact on the EFI framebuffer.
>>>
>>> The end goal here is a boot where the firmware shows its boot graphics
>>> and these stay in place for a couple of seconds until the GUI loads and
>>> the GUI then smoothly takes over the framebuffer without any distruptions.
>>>
>>> This patch-set spans 2 subsystems.
>>>
>>> Petr, the printk subsys change is really trivial (1 line addition) can we
>>> get your Acked-by for merging all 3 patches through the fbdev tree?
>>>
>>> Changelog:
>>>
>>> Changes in v4:
>>> -Keep the comments about which fbcon functions need locks in place
>>>
>>> Changes in v3:
>>> -Export is_console_locke() for use in modules (as fbcon may be built as a .ko)
>>> -Use WARN_CONSOLE_UNLOCKED() in several places in the fbcon code to assert
>>>   proper locking (requested by Daniel)
>>> -Unregister the fbcon-dummycon-output-notifier on fbcon_exit() (req. by Daniel)
>>> -Document the fbcon=nodefer commandline option (req. by Emil)
>>>
>>> Changes in v2:
>>> -Check the whole string when checking for erases in putcs, instead of just
>>>   the first char
>>> -Make dummycon_blank return 1, so that a redraw gets triggered and any text
>>>   rendered while blanked gets output so that it can trigger a deferred
>>>   takeover if one is pending
>>
>> Wrt merging I think it'd be best if we stuff this into drm-misc-next -
>> that will increase testing by gpu drivers a lot, instead of a suprise when
>> the fbdev pull lands in upstream.
>>
>> Bart, is that ok with you?
> 
> Not really, since there are efifb changes in the queue which depend
> on this series I would really prefer to merge all patches through
> fbdev tree.
> 
> Also fbdev tree is pulled into -next kernels so testing coverage
> should be okay (I assume that everybody are testing -next kernels in
> addition to their own branches :-)..

If you are talking about the "efifb: Copy the ACPI BGRT boot graphics to the
framebuffer" series, I could push those to drm-misc-next too (once acked).

I think most GPU driver developers are running drm-tip and not
-next, so putting things in drm-misc-next would give the changes somewhat
more test-exposure on a wider range of GPUs I believe. Where as -next
testing will likely be more server use-case oriented.

Alternatively you could merge things in the fbdev tree, do an
unmutable branch and then that could be merged into drm-misc-next by
the drm-misc-next maintainers.

Note either way is fine with me. This is up to you and Daniel.

Regards,

Hans