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@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
