(was: Create a DRM driver for Matrox G200)

Even after 20 years, the Matrox G200 series is still an excellent 2d graphics card. Unfortunately, there's only an fbdev driver and a user-space driver. Both are obsolete, as modern Linux uses the DRM framework for managing graphics cards. There already is a DRM driver for the G200 server series. This driver is under-maintained and doesn't work with desktop chips.

I intend to work on a DRM driver for the G200 during the hackweek. Let's see how far one can get within a few days. :)

Looking for hackers with the skills:

kernel graphics retro hardware

This project is part of:

Hack Week 17 Hack Week 21

Activity

  • over 2 years ago: ismaell liked this project.
  • over 2 years ago: tdz added keyword "hardware" to this project.
  • over 2 years ago: tdz added keyword "retro" to this project.
  • over 2 years ago: tdz liked this project.
  • over 6 years ago: ptesarik added keyword "kernel" to this project.
  • over 6 years ago: ptesarik added keyword "graphics" to this project.
  • over 6 years ago: ptesarik joined this project.
  • over 6 years ago: ptesarik liked this project.
  • over 6 years ago: tdz started this project.
  • over 6 years ago: mbrugger liked this project.
  • over 6 years ago: mwilck liked this project.
  • over 6 years ago: tdz originated this project.

  • Comments

    • ptesarik
      over 6 years ago by ptesarik | Reply

      G200 is also found in Fujitsu Primergy. Anyway, having a DRM driver sounds like a good step towards a unified graphics stack.

    • tdz
      over 6 years ago by tdz | Reply

      Oh, interresting! I found this: http://www.fujitsu.com/de/products/computing/servers/primergy/os/linux/suse/ and it specifically mentions Primergy. Do we have one of these devices around for testing?

      My plan is to start with desktop cards (because I can do that locally) and at some point merge support for the server. The differences are minor. I mentioned this earlier, the current server-chipset driver is under-maintained and not up to today's DRM. Having desktop support should also help to keep this maintained for the longer term.

    • tdz
      over 6 years ago by tdz | Reply

      From some earlier spare-time work, I already have the power-up code and the DDC code. Next is memory mgmt and modesetting.

    • tdz
      over 6 years ago by tdz | Reply

      Here's what's there so far, not cleaned up:

      https://gitlab.suse.de/tdz/linux/tree/mga-kms

    • tdz
      over 6 years ago by tdz | Reply

      Here's the state after day 1; not cleaned up:

      https://gitlab.suse.de/tdz/linux/tree/mga-kms-day1

      It can do DDC and power-up the device if the BIOS didn't already do so. The fbdev tries to initialize a video mode, but the actual modesetting code is not yet present.

    • tdz
      over 6 years ago by tdz | Reply

      The state of the driver after day 2 is at

      https://gitlab.suse.de/tdz/linux/tree/mga-kms-day2

      I've added code for computing a mode's required memory bandwidth and VCLK (actually Pixel PLL config). This is part of the check-phase of applying a mode. The commit phase is next. Once that works, a lot of clean-up will have to be done.

    • tdz
      over 6 years ago by tdz | Reply

      The state of the driver after day 3 is at

      https://gitlab.suse.de/tdz/linux/tree/mga-kms-day3

      I didn't make much visible progress today, as I was busy with debugging and reading code in the DRM framework.

    • tdz
      over 2 years ago by tdz | Reply

      I think it's time to revive this hackweek project with a slightly different spin.

      Egbert's patches for desktop G200 have landed in the kernel's DRM driver for server G200 a few releases ago. But there's more Matrox desktop hardware that can be supported. I have some half-done patches for G400, etc that I wanted to get finished.

    • tdz
      over 2 years ago by tdz | Reply

      Day 1: The current kernel driver for Matrox supports the various flavors of the G200 chipset. The overall modesetting pipeline is the same for all Matrox cards, but each version's hardware has it's own peculiarities. Therefore, I studied the old userspace driver to understand how it sets up hardware for the G400.

    • tdz
      over 2 years ago by tdz | Reply

      Day 2: I had to do bug fixing in the upstream kernel, so I couldn't commit the morning to the hackweek project. In the afternoon, I went through the old X11 mga driver and tried to transfer the G400's register values and DAC setup code to the kernel driver.

    • tdz
      over 2 years ago by tdz | Reply

      Day 3: I got the G400 working with the mgag200 kernel driver. I took the driver's existing G200 code and adapted it with parameters for the G400. The parameters come from the X11 userspace driver. In the afternoon, I started working on G450 support. The G450 and G550 use a different argorithm for programming the PLL. I'll have to port the existing code from one of the other Matrox drivers into mgag200.

    • tdz
      over 2 years ago by tdz | Reply

      Day 4: I got the Matrox G450 working.

      As I mentioned, the PLL setup algorithm is different from previous cards. The PLL produces an output frequency from a fixes input frequency plus a few circuits that modify it. Such modifications apply divider or multiplier operations to the input frequency in a predefined way. The result is not a 100% match, but usually close enough. Drivers typically take the setting that results in the least difference to the target frequency. (That's why 60 Hz displays usually run with ~59.xx Hz)

      The existing Matrox G450 code is different in that it computes all possible combinations of PLL settings that produce the target frequency and then apply them one by one until the graphics card reports success. Taking this code from the existing fbdev driver requires quite a bit of refactoring to fit it into DRM's atomic modesetting scheme.

    • tdz
      over 2 years ago by tdz | Reply

      Day 5: I worked on cleaning up the G450 code. As I mentioned, the PLL setup algorithm is much more elaborate than for the other models. Integrating this into DRM patterns requires several refactor-debug cycles.

      Overall, I made good progress with the Matrox cards. I have added support for the G400, G400 MAX and the G450. The one left is the G550. Looking at other existing Matrox drivers, it seems very similar to the G450, so it should be relatively easy to support after the G450 code has fallen into place.

      Maybe I'll take the time to finish this and submit the code upstream inclusion.

    Similar Projects

    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


    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


    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


    Contributing to Linux Kernel security by pperego

    Description

    A couple of weeks ago, I found this blog post by Gustavo Silva, a Linux Kernel contributor.

    I always strived to start again into hacking the Linux Kernel, so I asked Coverity scan dashboard access and I want to contribute to Linux Kernel by fixing some minor issues.

    I want also to create a Linux Kernel fuzzing lab using qemu and syzkaller

    Goals

    1. Fix at least 2 security bugs
    2. Create the fuzzing lab and having it running

    The story so far

    • Day 1: setting up a virtual machine for kernel development using Tumbleweed. Reading a lot of documentation, taking confidence with Coverity dashboard and with procedures to submit a kernel patch
    • Day 2: I read really a lot of documentation and I triaged some findings on Coverity SAST dashboard. I have to confirm that SAST tool are great false positives generator, even for low hanging fruits.
    • Day 3: Working on trivial changes after I read this blog post: https://www.toblux.com/posts/2024/02/linux-kernel-patches.html. I have to take confidence with the patch preparation and submit process yet.
      • First trivial patch sent: using strtruefalse() macro instead of hard-coded strings in a staging driver for a lcd display
      • Fix for a dereference before null check issue discovered by Coverity (CID 1601566) https://scan7.scan.coverity.com/#/project-view/52110/11354?selectedIssue=1601566
    • Day 4: Triaging more issues found by Coverity.
      • The patch for CID 1601566 was refused. The check against the NULL pointer was pointless so I prepared a version 2 of the patch removing the check.
      • Fixed another dereference before NULL check in iwlmvmparsewowlaninfo_notif() routine (CID 1601547). This one was already submitted by another kernel hacker :(
    • Day 5: Wrapping up. I had to do some minor rework on patch for CID 1601566. I found a stalker bothering me in private emails and people I interacted with me, advised he is a well known bothering person. Markus Elfring for the record.
    • Wrapping up: being back doing kernel hacking is amazing and I don't want to stop it. My battery pack is completely drained but changing the scope gave me a great twist and I really want to feel this energy not doing a single task for months.

      I failed in setting up a fuzzing lab but I was too optimistic for the patch submission process.

    The patches

    1


    Improve various phones kernel mainline support (Qualcomm, Exynos, MediaTek) by pvorel

    Similar to previous hackweeks ( https://hackweek.opensuse.org/projects/improve-qualcomm-soc-msm8994-slash-msm8992-kernel-mainline-support, https://hackweek.opensuse.org/projects/test-mainline-kernel-on-an-older-qualcomm-soc-msm89xx-explore-mainline-kernel-qualcomm-mainlining) try to improve kernel mainline support of various phones.


    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


    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


    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.


    Framework laptop integration by nkrapp

    Project Description

    Although openSUSE does run on the Framework laptops out-of-the-box, there is still room to improve the experience. The ultimate goal is to get openSUSE on the list of community supported distros

    Goal for this Hackweek

    The goal this year is to at least package all of the soft- and firmware for accessories like the embedded controller, Framework 16 inputmodule and other tools. I already made some progress by packaging the inputmodule control software, but the firmware is still missing

    Resources

    As I only have a Framework laptop 16 and not a 13 I'm looking for people with hardware that can help me test

    Progress:

    Update 1:

    The project lives under my home for now until I can get an independent project on OBS: Framework Laptop project

    Also, the first package is already done, it's the cli for the led-matrix spacer module on the Framework Laptop 16. I am also testing this myself, but any feedback or questions are welcome.

    You can test the package on the Framework 16 by adding this repo and installing the package inputmodule-control

    Update 2:

    I finished packaging the python cli/gui for the inputmodule. It is using a bit of a hack because one of the dependencies (PySimpleGUI) recently switched to a noncommercial license so I cannot ship it. But now you can actually play the games on the led-matrix (the rust package doesn't include controls for the games). I'm also working on the Framework system tools now, which should be more interesting for Framework 13 users.

    You can test the package on the Framework 16 by installing python311-framework16_inputmodule and then running "ledmatrixctl" from the command line.

    Update 3:

    I packaged the framework_tool, a general application for interacting with the system. You can find it some detailed information what it can do here. On my system everything related to the embedded controller functionality doesn't work though, so some help testing and debugging would be appreciated.

    Update 4:

    Today I finished the qmk interface, which gives you a cli (and gui) to configure your Framework 16 keyboard. Sadly the Python gui is broken upstream, but I added the qmk_hid package with the cli and from my testing it works well.

    Final Update:

    All the interesting programs are now done, I decided to exclude the firmware for now since upstream also recommends using fwupd to update it. I will hack on more things related to the Framework Laptops in the future so if there are any ideas to improve the experience (or any bugs to report) feel free to message me about it.

    As a final summary/help for everyone using a Framework Laptop who wants to use this software:

    The source code for all packages can be found in repositories in the Framework organization on Github

    All software can be installed from this repo (Tumbleweed)

    The available packages are:

    • framework-inputmodule-control (FW16) - play with the inputmodules on your Framework 16 (b1-display, led-matrix, c1-minimal)

    • python-framework16_inputmodule (FW16) - same as inputmodule-control but is needed if you want to play and crontrol the built-in games in the led-matrix (call with ledmatrixctl or ledmatrixgui)

    • framework_tool (FW13 and FW 16) - use to see and configure general things on your framework system. Commands using the embedded controller might not work, it looks like there are some problems with the kernel module used by the EC. Fixing this is out of scope for this hackweek but I am working on it

    • qmk_hid (FW16) - a cli to configure the FW16 qmk keyboard. Sadly the gui for this is broken upstream so only the cli is usable for now


    SUSE Prague claw machine by anstalker

    Project Description

    The idea is to build a claw machine similar to e.g. this one:

    example image

    Why? Well, it could be a lot of fun!

    But also it's a great way to dispense SUSE and openSUSE merch like little Geekos at events like conferences, career fairs and open house events.

    Goal for this Hackweek

    Build an arcade claw machine.

    Resources

    In French, an article about why you always lose in claw machine games:

    We're looking for handy/crafty people in the Prague office:

    • woodworking XP or equipment
    • arduino/raspi embedded programming knowledge
    • Anthony can find a budget for going to GM and buying servos and such ;)


    Build a split keyboard from scratch by mpagot

    Description

    I'm getting older... this summer I experienced an annoying and persistent tingling in one hand and arm. That was the initial motivation to get more interested in ergonomic work gadgets, and from that to split keyboards. And that was the entrance in a rabbit hole.

    Which keyboard I like to create:

    • Split keyboard for ergonomic (I'm not primary interested in having it portable)
    • I have big hands: I like it to fit as much as possible my hands measures
    • Columnar stagger keys position
    • Not too few keys (at the moment I'm at 24 + 24)
    • One row thumb cluster
    • No wireless, not to have batteries and for security reason
    • CherryMX, or generally speaking no low profile/corne choc
    • Hot swap Socket switches

    Goals

    • Create PCB design for a split keyboard
    • Get it produced
    • Mount it
    • Evaluate FWs

    Resources

    Progress

    Day1

    Get the existing Ergogen project working on my TW machine Get Kicad as flatpack Go back to the https://flatfootfox.com/ergogen-part3-pcbs/ Join the #ergogen Discord channel and ask for help about the nets

    Day2

    Redesign the keyboard matrix on Inkscape Implement it in the Ergogen YAML format Create a Kicad PCB file Start routing it Iterate over the matrix arrangement to try to implement it like 2 layer board and ideally with not vias Get some Kicad tutorials

    Day3

    Get my hand dirty building a 2x2 key matrix --> welcome to nne Look at ZKM and how to configure it --> https://github.com/michelepagot/zmk-config-nne Get the FW built by github, try to flash it: get matrix scan pulse but no keys to the PC Get in contact with ceoloide, an Ergogen maintainer, about net issue.


    Capyboard, ESP32 Development Board for Education by emiler

    Description

    Capyboard 3D

    Capyboard is an ESP32 development board built to accept individual custom-made modules. The board is created primarily for use in education, where you want to focus on embedded programming instead of spending time with connecting cables and parts on a breadboard, as you would with Arduino and other such devices. The board is not limited only to education and it can be used to build, for instance, a very powerful internal meteo-station and so on.

    I already have one initial prototype ready and tested. The next iteration addresses several issues the first prototype had. I am planning on finishing up the mainboard and one of the modules this week.

    This project is also a part of my master's thesis.

    Goals

    • Finish testing of a new prototype
    • Publish source files
    • Documentation completion
    • Finish writing thesis

    Resources