Commit d3ef5974 authored by Léo Grange's avatar Léo Grange
Browse files

Update with raw content, not formated

parent 54071f9e
Implement KMS driver for Cirrus cards
Leo Grange
View revisions
Organization: The OpenBSD Foundation
Abstract: With the current progress done on the graphic stack on many operating systems, the DRM/KMS infrastructure is now used by several BSDs, including OpenBSD. The aim of this project is to write a new KMS driver to handle a Cirrus CLGD 5446 card, and to document the process, to make writing new KMS driver for OpenBSD easier. In addition, the choice of this card will allow usage of KMS drivers when running OpenBSD through QEMU.
Personal overview
Name: Léo Grange
Phone: +336xxxx8647
Country of residence: France (timezone +1)
IRC: Kristaba on EFnet and Freenode
Why this project
First of all, I like low-level hacking and being able to understand how hardware is controlled. DRM/KMS is a very interesting driver model from many points of view, and contributing to it in OpenBSD may improve its robustness and security.
By writing a relatively simple driver, and documenting the process in the same time, it will also help OpenBSD to gradually port KMS drivers for other, less common video cards. As the current direction taken by the X.Org project is to encourage KMS drivers, it's a good thing for OpenBSD to be ready for whatever happens in the middle and long term.
Technical details
DRM infrastructure has existed in OpenBSD for some time, but the implementation of the various KMS drivers, which are mainly ported from Linux kernel, is a long and difficult process. OpenBSD earned KMS support for Intel[1] and then Radeon[2] cards in 2013.
Unfortunately, the many other cards supported by X.Org[3] are still fully implemented in userspace. They need some ugly hacks to have direct access to the underlying hardware, like the aperture driver[4], in order to have the whole X server running as an unprivilegied user.
The goal of this project is at the same time to implement a new KMS driver, targetting Cirrus CLGD 5446 card, and to write a bit of documentation about porting existing, userland driver. The reasons of the choice of this card are the following : it is relatively simple[5] (at least compared to recent GPUs), and it is one of the video cards emulated by QEMU[6]. As a consequence, it is virtually used by almost everybody running OpenBSD in a QEMU box, and very simple to test.
The X.Org userspace Cirrus driver[7] should be a good start and reference implementation. Also, as DRM/KMS drivers design differs a lot from userspace ones, existing drivers[8] will be another good knowledge base. Also, there is an existing KMS driver for this Cirrus card for the Linux kernel[9], but as it is licensed under GNU GPL, it is preferable to avoid looking too much into its code, to avoid any (even unvoluntary) license infringement. As mentioned above, this driver will also be used as a well-documented KMS driver, as it is expected to be relatively small and easy to understand. It may be used as a "template" to implement other drivers, with the additionnal help of the documentation of the process itself.
During the period covered by GSoC, I expect to be free almost all the time, as my last examinations are on April 30. I should therefore be able to work full-time during almost all this period, with two exceptions :
a possible resit exam session of a maximum of 4 days in the end of June (no reason to have to resit, but I prefer to signal the worst case)
a few days (4 or 5) in the middle of July that I will spend in a place without an Internet connection, so I will be able to work on code, but difficult to contact
Schedule and milestones
Here is my planned schedule, from the announcement of accepted proposal (April 27) to the suggested pencil down time (August 17), or 16 weeks.
Week 1-3: Introduce myself to the community, establish contact with people who ported intel and radeon DRM drivers to OpenBSD. Read more documentation on the QEMU-emulated Cirrus card, take a deeper look to xf86-video-cirrus code and exiting DRM drivers.
Week 4: Design the general architecture of the driver, check most difficult parts of DRM APIs with relevant people if anything is not clear.
Week 5 (GSoC 'begin coding'): Write 'stub' files, using the general architecture designed, to prepare the implementation.
Week 6-8: Implement a minimal driver, able to detect the QEMU Cirrus card and to attach to it at boot time.
Not expected to be usable, but should allow libdrm to interact with the underlying driver.
Week 9-10 (mid term evaluation): Finalization of the minimal driver, make sure it passes some critical tests from the libdrm's testsuite. If possible, have a first draft of the documentation, with important notes about what I learned to this point.
Week 11: Focus on redacting a more formal documentation on the work done before to have a minimalist DRM driver. In the same time, prepare the next part of the implementation by checking manually some settings of the card.
Week 12-13: Get a first partially working driver, with minimal framebuffer and CRTC support. It will probably not be stable enough to start X server on it, but wsdisplay should attach to this driver and provide a provide a console using its framebuffer.
Week 14-15: Fix every thing needed in order to run the X server, improve stability. Try to have a X server starting without using aperture driver.
Week 16: Check and fix the driver to have a working X server, enough stable to use it with common X client applications.
Week 17 (Pencil down): Improve the quality of the documentation and prepare for evaluation...
Personal details
I am a student in first year of Master in Computer Sciences (specialized on computer architecture and embedded systems), at Paul Sabatier University, Toulouse (France).
I did my last year internship in a public research laboratory, working on a "energy-aware" Linux CPU governor for high performance computing.
A previous internship was about source-to-source compiler for automatic parallelization of C code, and I was working in a research team of KPIT Cummins, in Pune, India.
I didn't contribute to any well known open-source project, but during my free time I created and developped a simple UNIX-like kernel[10] (and some userspace tools[11]) for a specific embedded platform.
This project, named FiXos, is mainly a personnal project, but some other people contributed to it.
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment