====== Graphics Stack Working Group ======

**Chair Person: [[/JeanSébastienPédron|Jean-Sébastien Pédron]]**

===== Agenda =====

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

It will address the following items:

  - Give a short status report on the i915 kernel driver.

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

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

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

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

<del>We will use this Etherpad to take notes:</del>
<del>https://etherpad.net/p/201510DevSummit_GraphicsStack)--</del>

===== Conclusions =====

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.

==== Presenting the Graphics stack ====

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:
{{devsummit/201510/graphicsstack/architecture_of_the_graphic_stack?linkonly|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:
  * Attracting contributors means attracting **users** first
  * A lot more efforts must be put into the [[/JuniorJobs|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.

==== 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%%:
  * 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.

[[/JakubKlama|Jakub Klama]] made [[SummerOfCode2014/evdev_Touchscreens|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.

----

{{tag>Historical}}