DisplayLink and some other USB and wireless displays no longer work on macOS 10.13.4 Learn More.

Linux kernel framebuffer rendering APIs

The Linux framebuffer interface has at least four different sets of APIs for rendering to the screen. Here they are mapped against the some important fbdev client “applications”.

DescriptionLinux consolefbdev X servermplayer, fbi, some others

fb_write and fb_readpasses a buffer to copy to/from usernonono
image_blit, fillrect, copyareablit passes buffer to copyyesnono
mmapassuming writes go directly to devicenoyesyes
mmapwith extra ioctl to report damagenonono

A “no” in the above table means the client application will fail if that’s the only API option supported by the kernel framebuffer driver.

udlfb supports all four, with some limitations (e.g. defio is required to support mmap without damage reports).

The custom displaylink X server is the only client today which supports the last option, which is the most performant option on indirect displays (like USB displays) – and hopefully will become a standard interface as it’s useful in many cases.

Unfortunately for the DisplayLink udlfb framebuffer, each API has different constraints it places on the driver. Those constraints aren’t easily met all at once for a driver rendering to USB. AFAICT, it looks like the driver actually needs to figure out what kind of client it’s dealing with, and assume that client will stick to that sub-set of the API. That seems to be a safe assumption for the major fbdev apps today, but betting on something like this is always ugly.

Any misconceptions?

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.