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.

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

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

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

1. 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: https://etherpad.net/p/201510DevSummit_GraphicsStack)–

Around 20 people attended the working group. Allan Jude put in place a live stream on https://bsdnow.tv 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.

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

• the video drivers in the kernel
• their userland counterpart in X.Org DDX (xf86-video-*) and Mesa
• the display servers above (X.Org server, Wayland compositors) with a large number of libraries
• the input stack: kernel drivers, X.Org DDX (xf86-input-*), evdev, libinput

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.

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:

• Attracting contributors means attracting users first
• A lot more efforts must be put into the Junior jobs list
• We should provide VM images with a complete graphical development environment preinstalled
• FreeBSD must work out-of-the-box on current hardware: of course, for the graphics stack specific case, this is a chicken and egg problem.

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.

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

• Keyboard input comes from the TTY (from the X.Org server point of view). All physical keyboards (atkbdc(4) and ukbd(4)) are by default merged under kbdmux(4). Out-of-the-box, we can't have separate layout for each keyboard. Furthermore, programmable mices, which expose a keyboard, could cause troubles.
• Mices are supports through psm(4) or ums(4). By default, moused(8) is started automatically for all ums(4), but not for psm(4). Configuring the X.Org server can be complicated. Support for touchpads is lagging behind; it can be even worse for other input pointing devices.
• We lack proper integration and sensitive default configuration for input devices.
• Keyboards can't be exposed directly (ie. without kbdmux(4)) if the user wants to use them all in VT. With kbdmux(4) disabled, plugging a programmable mouse would render the VT unusable because the fake keyboard would become the active one.

He then detailed what the Linux community is aiming at:

• evdev is the kernel API exposed to userland to handle all input devices.
• libinput is a new project from Red Hat to have a uniform input library, independent from the X.Org server. This library reached version 1.0 recently. It will be used by both Wayland compositors and the X.Org server. Eventually, it could replace all xf86-input-*.
• libinput uses evdev and udev to access the hardware.

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:

• a way to enumerate devices (video, input, storage, etc.);
• a way to query those devices to get informations;
• a way to attach global and per-user properties to devices.

Another requirement for libinput is Linux' timerfd API.