Proposals To Split KMS & GPU Drivers, 2D Kernel API
The notes in full from last week's kernel display and video API consolidation meet-up from the Linux Foundation's embedded event in Redwood Shores can be found on the dri-devel mailing list. There's a few items worth mentioning that are likely of interest to Phoronix readers.
Split KMS and GPU Drivers: One of the goals coming out of this mini-summit is to "Split KMS and GPU drivers with in kernel API inbetween." The reasoning for allowing KMS/GPU drivers to be split is that with SoCs the graphics processor and display controller tend to be separate devices. If there was a split between the GPU/KMS (display) portions with a defined interface to tie them together, it would be possible to re-use GPU drivers on different devices. The example given by the developers is that there could be a single common PowerVR kernel driver for the many devices out there using this Imagination Technologies graphics core. The different devices could then have different display (KMS) drivers where needed. Basically it's allowing for a more modular kernel graphics stack, but would end up being optional whether or not the vendors/developers comply.
While this is with a mobile focus, there are also possible desktop benefits. "The same approach can be used on the desktop for the multi-GPU case and the USB display case." Basically it would be a different way of doing the GPU hot-plugging and display with DispalyLink devices on Linux, etc.
Those coming up with this splitting idea acknowledge that one of the biggest challenges would be getting the GPU vendors to use this new split model. Rob Clark of Texas Instruments is beginning work on a reference implementation for this new design while Jesse Barker of Linaro is going to try to convince ARM to split their Mali kernel driver.
DMA-BUF V4L2: There's work being done to implement the DMA-BUF API inside V4L2. For those not familiar with the DMA-BUF buffer sharing mechanism, read and watch DMA-BUF Is Ready To Push Forward Linux Drivers.
2D Kernel Acceleration API: The embedded developers talked briefly about exposing a 2D acceleration API to user-space for devices with kernel drivers supporting hardware-accelerated 2D rendering. However, for any modern graphics processor relying upon a command stream, a user-space library is necessitated in order to assemble the stream, which would eliminate in large-part the usefulness of a unified 2D acceleration kernel API. This item is likely dead in the water.
HDMI CEC: There's interest in supporting HDMI CEC within the kernel and then providing a user-space API for applications. There's already some developers working on this code which would span multiple sub-systems or lead to the creation of a CEC sub-system. There's plans to push CEC mainline support this calendar year. HDMI CEC (Consumer Electronics Control) allows users to command and control CEC-enabled devices via HDMI through one remote. The CEC specification also allows one CEC device to command/control another CEC device automatically all over HDMI.
Common Video Mode Data Structure / EDID Parser: A call to share a common EDID parser between DRM/KMS, fbdev, and V4L2. The Linaro-backed developers plan to use the DRM EDID parser as it's the most advanced and then work it into the other sub-systems while coming up with a new common video mode/timing data structure. The desire to have a common EDID parser in the kernel has been expressed in the past by developers.
21 Comments
