New Coreboot Frame-Buffer Driver For The Linux Kernel

[phoronix]

Phoronix: New Coreboot Frame-Buffer Driver For The Linux Kernel

A new Coreboot frame-buffer driver has been published for the Linux kernel that allows reusing of the frame-buffer setup by Coreboot during the hardware initialization process...

http://www.phoronix.com/scan.php?page=news_item&px=New-Coreboot-FB-Linux-Driver

[Adarion]

Does something like this feature energy management (savings)?

[rene]

never can have enough dump system frame buffer drivers, ... maybe they should re-use some existing simple API instead, ...

[MoonMoon]

never can have enough dump system frame buffer drivers, ... maybe they should re-use some existing simple API instead, ...

So they write a new driver with functionality that wasn't present in any other driver before and your comment is that they should have used an existing API instead?
How should that even work? Any chance that you aren't a developer?

[polarathene]

So if you have a coreboot supported machine, what's required to get the fb reused? Any requirements in the kernel version or just use the latest coreboot?, or something else needs to be installed/setup?

[tildearrow]

Typo:

other patches for expsoing Coreboot table support

[rene]

So they write a new driver with functionality that wasn't present in any other driver before and your comment is that they should have used an existing API instead?
How should that even work? Any chance that you aren't a developer?

this are like 4 integers and a pointer (w, h, stride, bits, fbptr*) and at least EFI has some FB struct, maybe even the multi boot spec. the amount of simple and system FB drivers in the linux kernel really is getting out of hands, ...

they even write there:

> [coreboot] exports information about this framebuffer, along with various other information, in a table
discoverable via ACPI or a device tree.

PS: And all this cruft is even going into directories name: drivers/firmware/google/
So is this google, or is it core boot, and why not share with efifb or whatever? And will we get google, facebook, sony, microsoft et al. directories all over the kernel now? And drivers/firmware/google/framebuffer-coreboot.c - should that not be drivers/video/fbdev/coreboot.c?

PPS: not talking to a developer, ... ;-) https://youtube.com/renerebe

[starshipeleven]

why not share with efifb or whatever?

I doubt UEFI firmware can be relied upon for this to work according to spec or at all.

[rene]

I doubt UEFI firmware can be relied upon for this to work according to spec or at all.

they already pass ACPI tables, there is for sure other code to base upon. And I do not mean full EFI implementation, of course you can rely on the simple struct you fill out yourself, nothing to do with vendor EFI implementation not used here. E.g fake some efi memory table to reuse efifb, or whatever. As I said the kernel already has multiple simple firmware FB implementations, and the google namespace cluttering also stinks, ...

[hax0r]

they already pass ACPI tables, there is for sure other code to base upon. And I do not mean full EFI implementation, of course you can rely on the simple struct you fill out yourself, nothing to do with vendor EFI implementation not used here. E.g fake some efi memory table to reuse efifb, or whatever. As I said the kernel already has multiple simple firmware FB implementations, and the google namespace cluttering also stinks, ...

You realize that when using Coreboot both a BIOS and UEFI firmwares become irrelevent? Linux already implements similar logic/features/services (the sane parts) that are found in BIOS/UEFI and _works_ without them fine. GRUB already is able to take over the framebuffer that Coreboot hands over, next logical step is to have similar support in Linux. I think that this is awesome and can't wait till it lands in mainline Linux. I myself use Coreboot on T430s laptop with GRUB payload (no BIOS/UEFI, no Intel ME blob) running FSF endorsed flavor of Archlinux called Parabola.