On Wed, Jun 27, 2018 at 1:13 PM, Hans de Goede <hdegoede@xxxxxxxxxx> wrote: > 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 :-).. Ime this is a rather unrealistic assumption ... > 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. Yeah pull request for a topic branch works too. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
