Differences

This shows you the differences between two versions of the page.

--- devsummit:201510:graphicsstack [2015/10/01 11:39] – Add a status report on the i915 driver as a topic JeanSébastienPédron
+++ devsummit:201510:graphicsstack [2021/04/25 07:12] (current) – Move to DevSummit namespace. JethroNederhof
@@ Line 1: / Line 1: @@
 ====== Graphics Stack Working Group ======
-==== Chair Person: Jean-Sébastien Pédron ====
+**Chair Person: [[/JeanSébastienPédron|Jean-Sébastien Pédron]]**
-===== Agenda: =====
+===== Agenda =====
 The goal of this working group is about the Graphics stack.
@@ Line 21: / Line 21: @@
 Attendees are welcome to add their own topics to the agenda.
-==== Etherpad ====
+<del>We will use this Etherpad to take notes:</del>
+<del>https://etherpad.net/p/201510DevSummit_GraphicsStack)--</del>
-We will use this Etherpad to take notes:
+===== Conclusions =====
-https://etherpad.net/p/201510DevSumit_GraphicsStack
-==== Attending ====
+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.
-In order to attend you need register for the [[/DevSummit|developer summit]] as well as by email for the session and be confirmed by the working group organizer.  Follow the guidelines described on the [[/201510DevSummit|main page]] or what you received by email.  For questions or if in doubt ask the session chairs.
+==== Presenting the Graphics stack ====
-**Please do NOT add yourself here.** Your name will appear automatically once you have received the confirmation email. You need to put your name on the general [[/201405DevSummit|developer summit]] attendees list though.
+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
-^ Name ^ Username / Affiliation ^ Topics of Interest ^ Notes ^
+Here is a picture of the architecture sketched on the board:
-| [[/JeanSébastienPédron|Jean-Sébastien Pédron]] | dumbbell | all | Session host |
+{{devsummit/201510/graphicsstack/architecture_of_the_graphic_stack?linkonly|Architecture of the graphic stack}}
-| [[/BaptisteDaroussin|Bapstie Daroussin]] | bapt | all |  |
-| [[/EdMaste|Ed Maste]] | emaste | all |  |
+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.
-| [[/NiclasZeising|Niclas Zeising]] | zeising | all |  |
+==== 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}}