(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

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

  • Comments

    • ptesarik
      almost 4 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
      almost 4 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
      almost 4 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
      almost 4 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
      almost 4 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
      almost 4 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
      almost 4 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
      2 months 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
      1 day 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
      about 19 hours 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.

    Similar Projects

    Poking technologies for enrolling customer key to kernel trusted keyring by joeyli

    [comment]: # (Please use the project descriptio...


    Modular kernel packaging by mwilck

    Project Description

    Create a PoC for a mo...


    mac80211_hwsim tool by cfconrad

    Project Description

    Write a userland tool...


    early stage kdump support by mbrugger

    [comment]: # (Please use the project descriptio...


    generic zswap dedup by ailiopoulos

    [comment]: # (Please use the project descriptio...


    Blog about our ScummVM Freeware games packages by sndirsch

    Blog about ScummVM Freeware games of our open...


    retrocomputing: learn the architecture of MIPS for PS1 and build an assembler by david.anes

    [comment]: # (Please use the project descriptio...