Graphics Stack Working Group

Chair Person: Jean-Sébastien Pédron


The goal of this working group is about the Graphics stack.

It will address the following items:

  1. Give a short status report on the i915 kernel driver.
  2. Present the work we (the graphics team) do, past, present and future. The idea is to clarify the scope of this graphics stack (ie. it is not limited to showing 3D games), give an overview of the components and what we do on them, and last but not least, eliminate bias toward the collaboration between communities (ie. Linux).

  3. Discuss what we should do to attract contributors. Today, we are two active developers: one in the kernel, one in the Ports tree. On DragonFly, they are now several kernel developers working on the drivers. Same in OpenBSD and Solaris. We need to list what is wrong with our workflow and communication and find solutions so contributors feel welcome to work on the graphics stack.

  4. Discuss the remaining issues with the Linux KPI shim and find solutions for them. This layer will ease updates to the kernel video drivers, so it is critical.

  5. Talk about the input stack and define a roadmap to catch up in this area. Our input stack shows its age. Our support for touchpads is very limited. This is also true for programmable mices or multiple plugged-in keyboards. We need to detail what is required to have evdev, udev and libinput on FreeBSD and how we reach this goal.

Attendees are welcome to add their own topics to the agenda.

We will use this Etherpad to take notes:


Around 20 people attended the working group. Allan Jude put in place a live stream on for people who could not be there;, thank you very much Allan! It was a very productive session with more people than Jean-Sébastien expected.

Presenting the Graphics stack

Jean-Sébastien gave an overview of the architecture of the graphics stack:

Here is a picture of the architecture sketched on the board: Architecture of the graphic stack

One important question was: why is the input stack considered part of the graphics stack? This is because the display servers (and toolkits above) integrate the input stack in the service they provide. Both the graphics and input stacks are the basis for offering an interactive session to the user.

Attracting contributors

This topic was in fact mostly covered by the "Recruiting contributors" working group by Deb Goodkin. Therefore, we skipped it in the Graphics stack session. That said, here is a summary:

The Linux shim license issues

Somes files, such as ktime.h are directly copied from Linux. They do not even retain the original license header. This is wrong and we can't use this in the default FreeBSD kernel and therefore in DRM.

Meny Yossefi from Mellanox will contact his employer's lawyers to audit the code again. The FreeBSD Foundation may do the same. In the meantime, Hans Petter and Jean-Sébastien are going to look at the DragonFly Linux shim (made private to DRM). François Tigeot said that it probably needs an audit too as the code comes from OFED too.

The input stack

Jean-Sébastien started with a presentation of the current state in FreeBSD:

He then detailed what the Linux community is aiming at:

Jakub Klama made a port of evdev which is quite stable. We discussed this with him, he will put it in Phabricator as soon as he has spare time.

To address udev, we will continue the work on libdevq and add a wrapper above it to provide a udev API. This will be useful to libinput but other components such as Mesa. What we need with libdevq are:

Another requirement for libinput is Linux' timerfd API.


DevSummit/201510/GraphicsStack (last edited 2021-04-25T07:12:27+0000 by JethroNederhof)