Support for DRM platform drivers
an invention by tdz
Updated about 1 month ago. 3 hacker ♥️. 1 follower.

This project could get us rid of the last fbdev drivers we're stil shipping: efifb and vesafb.

Platform drivers handle hardware that is not auto-detected, but somehow there. For graphics this would be VGA, VESA, or UEFI framebuffers. In SUSE Linux, we currently support VESA and UEFI with fbdev drivers. Those load early in the boot process and maintain graphics hardware until the actual driver takes over.

It would be nice to support VESA and UEFI with modern DRM drivers. Doing so would give us basic support for very old, very modern or very obscure graphics hardware. This in itself is not complicated. The problem is the handover to the actual HW driver. For the old fbdev, there's a mechanism for the HW driver to disable the platform driver. Not such thing exists for DRM. Implementing this mechanism would be the main goal of the project.

Looking for hackers with the skills:

kernel drm fbdev graphics

This project is part of:

Hack Week 19

Activity

  • almost 5 years ago: tdz liked this project.
  • almost 5 years ago: MDoucha liked this project.
  • almost 5 years ago: vliaskovitis liked this project.
  • almost 5 years ago: tdz started this project.
  • almost 5 years ago: tdz added keyword "kernel" to this project.
  • almost 5 years ago: tdz added keyword "drm" to this project.
  • almost 5 years ago: tdz added keyword "fbdev" to this project.
  • almost 5 years ago: tdz added keyword "graphics" to this project.
  • almost 5 years ago: tdz originated this project.


    • Comments

    • vliaskovitis
      almost 5 years ago by vliaskovitis | Reply

      Interested though I only have limited kms experience (I have tested vkms/vgem, igt tools, and written a small vkms-like module in the past). Are the proposed drm drivers supposed to follow the fbdev->drm conversion from the fbconv helpers work https://gitlab.freedesktop.org/tzimmermann/linux/commits/fbconv , or are they meant to be from-scratch drm drivers? No idea about the handover mechanism though. If this is something that could be done and tested with VMs or a standard desktop without specific gfx cards (i assume so as vesafb is generic), and there are separable tasks that you don't plan on hacking, let me know.

      • tdz
        almost 5 years ago by tdz | Reply

        Hi!

        I started working on this idea today.

        The drivers are written from scratch. (1) The fbdev drivers are just trivial framebuffers that the screen image is being copied into. At least efifb cannot even do modesetting. It uses the display mode that has been set by the UEFI BIOS.

        The hand-over mechanism is similar to how fbdev does it. The platform driver claims a piece of I/O memory, and once the actual driver wants to take the memory range, it kicks out the platform driver.

        I was a bit optimistic about the number of fbdev drivers. There are 2 or 3 others besides efifb and vesafb. Yet, those would be a significant step forward.

        I don't know about testing in VMs. If the current kernel's efifb works in the VM, the new driver should work as well.

        Best regards Thomas

        (1) It's nice that you recognized my work on fbconv. :)

    • tdz
      almost 5 years ago by tdz | Reply

      Day 1: I made a skeleton driver for EFI and for the hand-over mechanism. The plan for tomorrow is to integrate the driver into the kernel's system-fb code and do a basic handover.

    • tdz
      almost 5 years ago by tdz | Reply

      Day 2: Reviewing efifb and vesafb shows that these drivers don't actually do any modesetting or even call much of their respective interfaces. They only pick up a preconfigured framebuffer. Therefore I'm changing goal slightly. Instead of recreating these drivers for DRM, I'm porting over simplefb. It also picks up a preconfigured framebuffer, but it's entirely agnostic to the platform and works with firmware, bootloader or device tree. It even support EFI and VESA. AFAICT all the setup is done by the platform and the kernel's boot code. Just as simplefb, the new DRM driver would take these settings and make them available within the graphics framework.

    • tdz
      almost 5 years ago by tdz | Reply

      Day 3: After two days of tinkering with the platform setup code, I typed down the driver today. The kernel fetches the framebuffer from GRUB and provides it as framebuffer device. My driver picks up the device and provides it via DRM. So far, the fbdev console emulation works and I was able to get GDM partially working. Apparently, X11 wants a PCI ID, which the device doesn't have. But there's probably a way around this limitation. All in all, this looks really good so far.

      • tdz
        almost 5 years ago by tdz | Reply

        And with a little weak, weston now works as well. add-emoji

        • tdz
          almost 5 years ago by tdz | Reply

          s/weak/tweak

    • tdz
      almost 5 years ago by tdz | Reply

      Day 4: I spent the day on cleaning up what I have and implementing the hand-over code. The hand-over is slightly tricky, as it requires to remove the DRM device while it's being used by the platform driver. And it's concurrent code that requires some locking. It's partially working ATM.

    • tdz
      almost 5 years ago by tdz | Reply

      Day 5: Today I finished the hand-over code. My test system is equipped with a Radeon graphics card. The bootloader, grub, configures a display mode before running the kernel. The built-in simplekms takes over early in the boot process and displays typical boot message. Once the radeon driver is ready, it kicks simplekms out and takes over the framebuffer. The hand-over is generic, so arbitrary drivers can kickout any platform driver.

      If there's no native DRM driver for the hardware, simplekms remains active and provides a basic framebuffer for Wayland compositors or the framebuffer console. I did not get native X11 running, as X11 requested a PCI device. I did not look further into this problem. However, Gnome runs fine in Wayland mode and X applications can be started via Xwayland.

      Yeah, I think this was a successful hackweek and the project is complete for now. After a bit more polishing, the driver could go upstream.

    • tdz
      almost 5 years ago by tdz | Reply

      I uploaded the current state of the project to the git branch at

      https://gitlab.suse.de/tzimmermann/linux/tree/simplekms

      • tdz
        almost 5 years ago by tdz | Reply

        Just an additional note: for simplekms to find the framebuffer, Grub has to run in graphics mode and forward the settings to Linux. The config options are something like:

        GRUBTERMINAL=gfxterm GRUBGFXPAYLOAD_LINUX=keep

    • vliaskovitis
      almost 5 years ago by vliaskovitis | Reply

      Thank you for the detailed journal and explanations!

    • favogt
      over 4 years ago by favogt | Reply

      I know that mstaudt was working on this as well before he left - is this based on his work?

      • tdz
        almost 4 years ago by tdz | Reply

        Hi!

        It's entirely new. The project moved from a hackweek thing to being one of my goals for this year. Hopefully it will hit upstream in autumn.

    Similar Projects

    Officially Become a Kernel Hacker! by m.crivellari

    Description

    My studies as well my spare time are dedicated to the Linux Kernel. Currently I'm focusing on interrupts on x86_64, but my interests are not restricted to one specific topic, for now.

    I also "played" a little bit with kernel modules (ie lantern, a toy packet analyzer) and I've added a new syscall in order read from a task A, the memory of a task B.

    Maybe this will be a good chance to...

    Goals

    • create my first kernel patch

    Resources

    Achivements

    RISC-V emulator in GLSL capable of running Linux by favogt

    Description

    There are already numerous ways to run Linux and some programs through emulation in a web browser (e.g. x86 and riscv64 on https://bellard.org/jslinux/), but none use WebGL/WebGPU to run the emulation on the GPU.

    I already made a PoC of an AArch64 (64-bit Arm) emulator in OpenCL which is unfortunately hindered by a multitude of OpenCL compiler bugs on all platforms (Intel with beignet or the new compute runtime and AMD with Mesa Clover and rusticl). With more widespread and thus less broken GLSL vs. OpenCL and the less complex implementation requirements for RV32 (especially 32bit integers instead of 64bit), that should not be a major problem anymore.

    Goals

    Write an RISC-V system emulator in GLSL that is capable of booting Linux and run some userspace programs interactively. Ideally it is small enough to work on online test platforms like Shaderoo with a custom texture that contains bootstrap code, kernel and initrd.

    Minimum:

    riscv32 without FPU (RV32 IMA) and MMU (µClinux), running Linux in M-mode and userspace in U-mode.

    Stretch goals:

    FPU support, S-Mode support with MMU, SMP. Custom web frontend with more possibilities for I/O (disk image, network?).

    Resources

    RISC-V ISA Specifications
    Shaderoo
    OpenGL 4.5 Quick Reference Card

    Result as of Hackweek 2024

    WebGL turned out to be insufficient, it only supports OpenGL ES 3.0 but imageLoad/imageStore needs ES 3.1. So we switched directions and had to write a native C++ host for the shaders.

    As of Hackweek Friday, the kernel attempts to boot and outputs messages, but panics due to missing memory regions.

    Since then, some bugs were fixed and enough hardware emulation implemented, so that now Linux boots with framebuffer support and it's possible to log in and run programs!

    The repo with a demo video is available at https://github.com/Vogtinator/risky-v

    Kill DMA and DMA32 memory zones by ptesarik

    Description

    Provide a better allocator for DMA-capable buffers, making the DMA and DMA32 zones obsolete.

    Goals

    Make a PoC kernel which can boot a x86 VM and a Raspberry Pi (because early RPi4 boards have some of the weirdest DMA constraints).

    Resources

    • LPC2024 talk:
    • video:

    Modularization and Modernization of cifs.ko for Enhanced SMB Protocol Support by hcarvalho

    Creator:
    Enzo Matsumiya ematsumiya@suse.de @ SUSE Samba team
    Members:
    Henrique Carvalho henrique.carvalho@suse.com @ SUSE Samba team

    Description

    Split cifs.ko in 2 separate modules; one for SMB 1.0 and 2.0.x, and another for SMB 2.1, 3.0, and 3.1.1.

    Goals

    Primary

    Start phasing out/deprecation of older SMB versions

    Secondary

    • Clean up of the code (with focus on the newer versions)
    • Update cifs-utils
    • Update documentation
    • Improve backport workflow (see below)

    Technical details

    Ideas for the implementation.

    • fs/smb/client/{old,new}.c to generate the respective modules
      • Maybe don't create separate folders? (re-evaluate as things progresses!)
    • Remove server->{ops,vals} if possible
    • Clean up fs_context.* -- merge duplicate options into one, handle them in userspace utils
    • Reduce code in smb2pdu.c -- tons of functions with very similar init/setup -> send/recv -> handle/free flow
    • Restructure multichannel
      • Treat initial connection as "channel 0" regardless of multichannel enabled/negotiated status, proceed with extra channels accordingly
      • Extra channel just point to "channel 0" as the primary server, no need to allocate an extra TCPServerInfo for each one
    • Authentication mechanisms
      • Modernize algorithms (references: himmelblau, IAKERB/Local KDC, SCRAM, oauth2 (Azure), etc.

    Linux on Cavium CN23XX cards by tsbogend

    Before Cavium switched to ARM64 CPUs they developed quite powerful MIPS based SOCs. The current upstream Linux kernel already supports some Octeon SOCs, but not the latest versions. Goal of this Hack Week project is to use the latest Cavium SDK to update the Linux kernel code to let it running on CN23XX network cards.

    Create DRM drivers for VESA and EFI framebuffers by tdz

    Description

    We already have simpledrm for firmware framebuffers. But the driver is originally for ARM boards, not PCs. It is already overloaded with code to support both use cases. At the same time it is missing possible features for VESA and EFI, such as palette modes or EDID support. We should have DRM drivers for VESA and EFI interfaces. The infrastructure exists already and initial drivers can be forked from simpledrm.

    Goals

    • Initially, a bare driver for VESA or EFI should be created. It can take functionality from simpledrm.
    • Then we can begin to add additional features. The boot loader can provide EDID data. With VGA hardware, VESA can support paletted modes or color management. Example code exists in vesafb.

    Create a DRM driver for VGA video cards by tdz

    Yes, those VGA video cards. The goal of this project is to implement a DRM graphics driver for such devices. While actual hardware is hard to obtain or even run today, qemu emulates VGA output.

    VGA has a number of limitations, which make this project interesting.

    • There are only 640x480 pixels (or less) on the screen. That resolution is also a soft lower limit imposed by DRM. It's mostly a problem for desktop environments though.
    • Desktop environments assume 16 million colors, but there are only 16 colors with VGA. VGA's 256 color palette is not available at 640x480. We can choose those 16 colors freely. The interesting part is how to choose them. We have to build a palette for the displayed frame and map each color to one of the palette's 16 entries. This is called dithering, and VGA's limitations are a good opportunity to learn about dithering algorithms.
    • VGA has an interesting memory layout. Most graphics devices use linear framebuffers, which store the pixels byte by byte. VGA uses 4 bitplanes instead. Plane 0 holds all bits 0 of all pixels. Plane 1 holds all bits 1 of all pixels, and so on.

    The driver will probably not be useful to many people. But, if finished, it can serve as test environment for low-level hardware. There's some interest in supporting old Amiga and Atari framebuffers in DRM. Those systems have similar limitations as VGA, but are harder to obtain and test with. With qemu, the VGA driver could fill this gap.

    Apart from the Wikipedia entry, good resources on VGA are at osdev.net and FreeVGA

    Create DRM drivers for VESA and EFI framebuffers by tdz

    Description

    We already have simpledrm for firmware framebuffers. But the driver is originally for ARM boards, not PCs. It is already overloaded with code to support both use cases. At the same time it is missing possible features for VESA and EFI, such as palette modes or EDID support. We should have DRM drivers for VESA and EFI interfaces. The infrastructure exists already and initial drivers can be forked from simpledrm.

    Goals

    • Initially, a bare driver for VESA or EFI should be created. It can take functionality from simpledrm.
    • Then we can begin to add additional features. The boot loader can provide EDID data. With VGA hardware, VESA can support paletted modes or color management. Example code exists in vesafb.

    New openSUSE-welcome by lkocman

    Project Description

    Let's revisit our existing openSUSE welcome app.

    My goal was to show Leap 16 in a new coat. Welcome app adds to the first time use experience. We've recently added donation button to our existing welcome.

    Some things that I recently wanted to address were EOL and possibly upgrade notification.

    I've already done some experiments with mint welcome app, but not sure if it's better than the existing one.

    There is also a PR to rework existing app https://github.com/openSUSE/openSUSE-welcome/pull/36 (this should be considered as an option too)

    Goal for this Hackweek

    New welcome app, possibly with EOL notification for Leap.

    1) Welcome application(s) with (rebrand changes) maintained under github.com/openSUSE

    2) Application is submitted to openSUSE:Factory && openSUSE:Leap:16.0

    3) Updated needles in openQA (probably post hackweek)

    Resources

    Reddit discussion about the best welcome app out there.

    Github repo for the current welcome app.

    Finish gfxprim application multiplexor (window manager) by metan

    Project Description

    I've implemented drivers for a few e-ink displays during the last hackweek and made sure that gfxprim widgets run nicely on e-ink as well. The missing piece to have a portable e-ink computer/reader/music player/... is a application that can switch between currently running applications and that can start new applications as well. Half of the solution is ready, there is a proxy gfxprim backend where applications render into a piece of a shared memory and input events (e.g. keyboard, mouse) can be multiplexed. What is missing is an interface (possibly touchscreen friendly as well) to make it user friendly.

    Goal for this Hackweek

    Make nekowm usable "window manager".

    Resources

    Create a DRM driver for VGA video cards by tdz

    Yes, those VGA video cards. The goal of this project is to implement a DRM graphics driver for such devices. While actual hardware is hard to obtain or even run today, qemu emulates VGA output.

    VGA has a number of limitations, which make this project interesting.

    • There are only 640x480 pixels (or less) on the screen. That resolution is also a soft lower limit imposed by DRM. It's mostly a problem for desktop environments though.
    • Desktop environments assume 16 million colors, but there are only 16 colors with VGA. VGA's 256 color palette is not available at 640x480. We can choose those 16 colors freely. The interesting part is how to choose them. We have to build a palette for the displayed frame and map each color to one of the palette's 16 entries. This is called dithering, and VGA's limitations are a good opportunity to learn about dithering algorithms.
    • VGA has an interesting memory layout. Most graphics devices use linear framebuffers, which store the pixels byte by byte. VGA uses 4 bitplanes instead. Plane 0 holds all bits 0 of all pixels. Plane 1 holds all bits 1 of all pixels, and so on.

    The driver will probably not be useful to many people. But, if finished, it can serve as test environment for low-level hardware. There's some interest in supporting old Amiga and Atari framebuffers in DRM. Those systems have similar limitations as VGA, but are harder to obtain and test with. With qemu, the VGA driver could fill this gap.

    Apart from the Wikipedia entry, good resources on VGA are at osdev.net and FreeVGA