A New Proposal For Supporting DRM Linux Drivers In User-Space

The discussion has come up before about supporting Direct Rendering Manager (DRM) drivers in user-space rather than having to be tied within the Linux kernel while that outlook was reignited today with a new patch series wiring in said support.

Noralf Trønnes sent out a "request for comments" on a set of patches published today that allow for user-space DRM drivers. Trønnes explained of this latest attempt for supporting DRM drivers in user-space, "This patchset includes all the pieces necessary to get a userspace driver working that is compatible with the fbtft/fb_ili9341 driver. It is tested with a SPI interfaced display hat/shield for the Raspberry Pi, which has an eeprom with a Device Tree fragment on it (merged by the bootloader). With the help of udev and systemd, the driver is able to autoload when the display is connected. Performance wise, the kernel driver can do ~19fps on a 320x240 spi at 32MHz display, whereas the userspace version does ~18fps. So performance is not an argument to keep the driver in the kernel."

One of the comments on the patches explaining more of a technical overview:

Userspace driver usage:
Open /dev/udrm
Ioctl create drm driver/device passing in mode, formats and optional dma-buf as transfer buffer
Read/poll for events:
framebuffer: create, destroy, dirty
pipe: enable, disable
Write back status value from the event execution
Closing file will delete the drm driver.

The reason for doing buffer copy in the kernel is that on a Raspberry Pi
copying (actually reading) a mmap'ed 150k dma-buf in userspace took 32ms
while in-kernel was 13ms.

This proposal isn't about trying to punt all DRM kernel drivers into user-space, but rather to support such for in cases where it makes sense, such as also with USB GPU devices being another area. His results are interesting of roughly similar performance with his particular driver performing close to the same while in user-space.

The patch series can be found on dri-devel. The patches also extend DMA-BUF for supporting generic user-space allocations.

Intel DRM maintainer Daniel Vetter was the first to respond to the series calling it "a pretty nifty thing" and pointing out this could be useful for Miracast implementations and other special cases. Intel developer Martin Peres also commented that an engineer at Intel Finland had worked on a similar DRM user-space driver approach and did receive approval for open-sourcing it, but time is the reason why their code hadn't been published yet.