Yes, there is. However is it a design from the 1990s and oriented towards the 2D acceleration features of the day: blitting rectangles, drawing a mouse cursor with an hardware sprite, video overlays, maybe horizontal and vertical lines tracing, rectangle filling, scrolling. And Haiku uses none of these anyway. So essentially we are left with the modesetting hook, and a partial implementation of multiple display support in some old drivers.
However, this interface does not go very far for 3D acceleration which is a completely different thing.
From there, we see two ways of doing things:
- One is extending this existing accelerant API
- The other is developing a separate interface, maybe as ioctls, more similar to what is done in Linux
I don’t know which way is better, not being familiar enough with DRI/DRM to see if it could be made to fit the existing accelerant interface. This interface is also accessible to applications quite directly (BWindowScreen allows pretty much direct access to the accelerant hooks), so it would be possible for Mesa to grab the hooks and talk with the driver directly. This makes things fit well with our existing model and allow to decide who gets access to 3D acceleration at the app_server level.
If we go with a more Linux-like interface, it would be possible for an application to bypass app_server and talk directly with the device driver. I don’t know if this is desirable/useful.