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 :-).. > Hans, if Bart acks this you can directly push this imo. > -Daniel Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
