Re: [RFC][PATCH 0/9] drm: Support simple-framebuffer devices and firmware fbs

[Hans de Goede <hdegoede@redhat.com>]

Hi,

On 7/1/20 3:48 PM, Thomas Zimmermann wrote:
> Hi Hans
> 
> Am 29.06.20 um 11:38 schrieb Hans de Goede:
>> Hi,
>>
>> On 6/25/20 2:00 PM, Thomas Zimmermann wrote:
>>> This patchset adds support for simple-framebuffer platform devices and
>>> a handover mechanism for native drivers to take-over control of the
>>> hardware.
>>>
>>> The new driver, called simplekms, binds to a simple-frambuffer platform
>>> device. The kernel's boot code creates such devices for firmware-provided
>>> framebuffers, such as EFI-GOP or VESA. Typically the BIOS, UEFI or boot
>>> loader sets up the framebuffers. Description via device tree is also an
>>> option.
>>>
>>> Simplekms is small enough to be linked into the kernel. The driver's main
>>> purpose is to provide graphical output during the early phases of the
>>> boot
>>> process, before the native DRM drivers are available. Native drivers are
>>> typically loaded from an initrd ram disk. Occationally simplekms can also
>>> serve as interim solution on graphics hardware without native DRM driver.
>>
>> Cool, thank you for doing this, this is a very welcome change,
>> but ... (see below).
>>
>>> So far distributions rely on fbdev drivers, such as efifb, vesafb or
>>> simplefb, for early-boot graphical output. However fbdev is deprecated
>>> and
>>> the drivers do not provide DRM interfaces for modern userspace.
>>>
>>> Patches 1 and 2 prepare the DRM format helpers for simplekms.
>>>
>>> Patches 3 to 7 add the simplekms driver. It's build on simple DRM helpers
>>> and SHMEM. It supports 16-bit, 24-bit and 32-bit RGB framebuffers. During
>>> pageflips, SHMEM buffers are copied into the framebuffer memory, similar
>>> to cirrus or mgag200. The code in patches 6 and 7 handles clocks and
>>> regulators. It's based on the simplefb drivers, but has been modified for
>>> DRM.
>>>
>>> Patches 8 and 9 add a hand-over mechanism. Simplekms acquires it's
>>> framebuffer's I/O-memory range and provides a callback function to be
>>> removed by a native driver. The native driver will remove simplekms
>>> before
>>> taking over the hardware. The removal is integrated into existing
>>> helpers,
>>> so drivers use it automatically.
>>>
>>> I tested simplekms with x86 EFI and VESA framebuffers, which both work
>>> reliably. The fbdev console and Weston work automatically. Xorg requires
>>> manual configuration of the device. Xorgs current modesetting driver does
>>> not work with both, platform and PCI device, for the same physical
>>> hardware. Once configured, X11 works.
>>
>> Ugh, Xorg not working OOTB is a bit of a showstopper, we cannot just go
>> around and break userspace. OTOH this does seem like an userspace issue
>> and not something which we can (or should try to) fix in the kernel.
> 
> Xorg is an important use case, but simplekms does not "break userspace."
> If you're not using simplekms, nothing changes; if simplekms is replaced
> by the native driver, nothing changes. Simplekms works with Xorg of the
> device is auto-configured. Xorg is not able to auto-configure simplekms
> devices ATM.

As I already mentioned in my replay to Daniel: If there is no native driver,
or the native driver fails to load (e.g. nvidia binary driver dkms build
fails with a nwer kernel) then having simplekms enables changes the user,
experience from Xorg on fbdev, slow but usable to search for a solution
to no GUI. I agree that we cannot solve this on the kernel side, but it
is a real problem which we need to keep in mind.

>> I guess the solution will have to be to have this default to N for now
>> in Kconfig and clearly mention in the Kconfig help text that this needs
>> a fixed Xorg modesetting driver before it can be enabled.
> 
> Sure, but simplekms is just a driver. Shouldn't it default to N anyway?

I guess so.

>> Any chance you have time to work on fixing the Xorg modesetting driver
>> so that this will just work with the standard Xorg autoconfiguration
>> stuff?
> 
> I'll do if somehow possible. See my reply to Daniel for a description of
> the problem.

Great.

>>> One cosmetical issue is that simplekms's device file is card0 and the
>>> native driver's device file is card1. After simplekms has been kicked
>>> out,
>>> only card1 is left. This does not seem to be a practical problem however.
>>>
>>> TODO/IDEAS:
>>>
>>>      * provide deferred takeover
>>
>> I assume you mean akin to CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER ?
>> I don't think you need to do anything for that, as long as you just
>> leave the fb contents intact until requested to change it.
> 
> Great. If it's that easy; even better.
> 
>>
>> Right now with flickerfree boot we have fbcon on top of efifb and
>> efifb does not do anything special wrt
>> CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER
>> ATM it does draw/restore the ACPI BGRT logo since since some firmwares
>> don't draw that themselves, but that is not necessary in most cases
>> and other then that all the deferred takeover magic is in the fbcon
>> code, it does not bind to the fbdev (and thus does not draw to it)
>> until the first time the kernel tries to output text to the console,
>> together with the "quiet" kernel commandline argument that ensures
>> that the fb is kept unmodified until e.g. a panic happens.
>>
>> With simplekms we would replace "fbcon on top of efifb" with
>> "fbcon on top of emulated-fbdev on top of simplekms" so as long
>> as the emulated-fbdev and simplekms code defer from say clearing
>> the screen to black, but keep it as is. Then the fb contents
>> should be preserved until fbcon decides to takeover the fbdev
>> and draw to it.
>>
>>>      * provide bootsplash DRM client
>>
>> Hmm, I guess this might be interesting for simple cases, but
>> although I would love to kill plymouth (I've become one of the
>> upstream maintainers for it) I'm afraid it is not that easy,
>> it does a bunch of stuff which will be tricky to do in the kernel:
> 
> The whole bootsplash thing is really a follow-up project.
> 
> What I have in mind for the bootsplash is the ACPI BGRT logo restoration
> that is currently in efifb. Maybe other sources for boot logos could be
> considered as well. And if nothing else, it could show a penguin. As
> soon as plymouth is ready, it would take over the display and do its thing.
> 
> Noralf made a prototype of an in-kernel bootsplash client that displays
> a colored rectangle. That's already half of the work, I guess.

Ok, this sounds good.

Regards,

Hans

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel