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

Looking for hackers with the skills:

graphics drivers kernel drm

This project is part of:

Hack Week 22 Hack Week 24

Activity

  • 5 days ago: Pharaoh_Atem liked this project.
  • 22 days ago: llansky3 liked this project.
  • about 1 month ago: michals liked this project.
  • almost 2 years ago: vliaskovitis liked this project.
  • almost 2 years ago: wfrisch liked this project.
  • almost 2 years ago: achaudhary2 joined this project.
  • almost 2 years ago: tdz added keyword "graphics" to this project.
  • almost 2 years ago: tdz added keyword "drivers" to this project.
  • almost 2 years ago: tdz added keyword "kernel" to this project.
  • almost 2 years ago: tdz added keyword "drm" to this project.
  • almost 2 years ago: tdz started this project.
  • almost 2 years ago: tdz liked this project.
  • almost 2 years ago: tdz originated this project.

  • Comments

    • tdz
      almost 2 years ago by tdz | Reply

      I have pushed a skeleton driver to Gitlab. The does not display anything yet, but binds to a provided VGA device. The rsp kernel config for i586 is here.

      I use 32-bit Tumbleweed on qemu as testing environment. Here are some short setup instructions.

      • Download TW for 32-bit and install in a qemu guest
      • There are various emulated graphics devices available with qemu's 32-bit emulation. I use virtio, but anything with VGA should work
      • On the installed system, open /etc/default/grub and set 'GRUB_TERMINAL=console' to enable textmode. Also append 'console=ttyS0,115200n8' to 'GRUB_CMDLINE_LINUX_DEFAULT' to enable serial-console output.
      • Recreate grub's config with ' sudo grub2-mkconfig -o /boot/grub2/grub.cfg'. These steps will set grub to VGA text mode.
      • Build and install the provided kernel. I use 'make O=build-i586/' and then again with module_install and install to get it installed. This requires kernel development tools.
      • After a reboot, grub should start in text mode. The development kernel should load the vgadrm driver. It does not display anything. If you switch to the serial console and login, 'dmesg | grep drm' should mention vgadrm.

    • tdz
      almost 2 years ago by tdz | Reply

      Day 1: I started with the skeleton driver that binds to the VGA device without doing proper output. I added blitting code to copy the framebuffer data into the video memory. The driver also installs a default palette on each pageflip. The screen now turns dark, but at least it's obvious that something changed. Updating the video memory is somewhat complicated due to VGA's awkward memory layout and a number of register settings that modify the written framebuffer data.

      See https://gitlab.suse.de/tzimmermann/linux/-/commits/vgadrm-day1.

    • tdz
      almost 2 years ago by tdz | Reply

      Amit joined the project and is about to install and try the currently available driver code.

    • tdz
      almost 2 years ago by tdz | Reply

      Day 2: I've been fixing register settings for the whole day. The driver is still not functional, but there's at least noise displayed on the screen. The existing material at FreeVGA and osdev.net has been extremely helpful.

      See https://gitlab.suse.de/tzimmermann/linux/-/tree/vgadrm-day2.

    • tdz
      almost 2 years ago by tdz | Reply

      Day 3: I only did register debugging today, as I still don't see an image on the screen. VGA has plenty of settings for text mode; plus compatibility with the even older EGA and CGA cards. I guess those could interfere or I'm simply missing something trivial. The qemu emulator doesn't seems to tell me about possible problems. So I'm going to set up a regular BIOS-based PC to test the driver. Connecting a monitor should give a signal and a video mode. If the signal is there, the problem is in the screen update; if not it's in the mode setting.

      See https://gitlab.suse.de/tzimmermann/linux/-/tree/vgadrm-day3.

      • tdz
        almost 2 years ago by tdz | Reply

        And just after I typed this comment, I tried the driver on a PC and could not get a signal on the monitor. So the mode-setting code appears to be the problem.

    • tdz
      almost 2 years ago by tdz | Reply

      Day 4: I stepped through my commits and made them into smaller pieces until I found the reason why the screen remained dark. It turns out that it's necessary to activate the palette after filling it with colors. The bit the to that is non-intuitively hidden in the attribute controller's index register, which also serve as a data register. The VGA device's interface is often like this and small errors can quickly backfire.

      So there's still the noise on the screen, but with repeating patterns. It looks like the final problem is in the way the VGA chips reads from video memory.

      See https://gitlab.suse.de/tzimmermann/linux/-/tree/vgadrm-day4.

    • tdz
      almost 2 years ago by tdz | Reply

      Day 5: Today I finally got a working output on the screen! Upon boot, the kernel console is being displayed and it is possible to log in and use the command line. The screen flickers, has a few artifacts and sometimes the colors are off, but it mostly works. I assume that the remaining problems come from many little issue within the kernel's DRM framework. The helpers for color-format conversion and blitting are not prepared to handle 16-color palette modes. So a few fixes might be required. Nevertheless, the display output is there and I count this hackweek project as a success. If I find the time to fix the remaining bugs, I'll send the driver to upstream for inclusion in the official Linux kernel.

      See https://gitlab.suse.de/tzimmermann/linux/-/tree/vgadrm-day5.

    Similar Projects

    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 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.


    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.


    Modernize ocfs2 by goldwynr

    Ocfs2 has gone into a stage of neglect and disrepair. Modernize the code to generate enough interest.

    Goals: * Change the mount sequence to use fscontext * Move from using bufferhead to bio/folios * Use iomap * Run it through xfstests


    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


    Improve UML page fault handler by ptesarik

    Description

    Improve UML handling of segmentation faults in kernel mode. Although such page faults are generally caused by a kernel bug, it is annoying if they cause an infinite loop, or panic the kernel. More importantly, a robust implementation allows to write KUnit tests for various guard pages, preventing potential kernel self-protection regressions.

    Goals

    Convert the UML page fault handler to use oops_* helpers, go through a few review rounds and finally get my patch series merged in 6.14.

    Resources

    Wrong initial attempt: https://lore.kernel.org/lkml/20231215121431.680-1-petrtesarik@huaweicloud.com/T/


    Model checking the BPF verifier by shunghsiyu

    Project Description

    BPF verifier plays a crucial role in securing the system (though less so now that unprivileged BPF is disabled by default in both upstream and SLES), and bugs in the verifier has lead to privilege escalation vulnerabilities in the past (e.g. CVE-2021-3490).

    One way to check whether the verifer has bugs to use model checking (a formal verification technique), in other words, build a abstract model of how the verifier operates, and then see if certain condition can occur (e.g. incorrect calculation during value tracking of registers) by giving both the model and condition to a solver.

    For the solver I will be using the Z3 SMT solver to do the checking since it provide a Python binding that's relatively easy to use.

    Goal for this Hackweek

    Learn how to use the Z3 Python binding (i.e. Z3Py) to build a model of (part of) the BPF verifier, probably the part that's related to value tracking using tristate numbers (aka tnum), and then check that the algorithm work as intended.

    Resources


    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


    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.