I'm currently working on a remoting KMS backend, and now I thought it would be a good time to get some feedback on a very rough design:

The idea is that we want to be get enough information on the backend side of KMS to be able to remote the display system over VNC or something similar. Initially I'd plug in an open-source VNC server as the "reference" user-space.

The solution should be general enough to plug into any driver, including VKMS, either mirroring an existing crtc/connector or adding a virtual one. The driver would typically only have to implement an efficient readback command, optionally with a diff-map or damage rect that tracks changed content for the VNC server to be able to do its work efficiently.

This would all be forwarded to a user-space interface and protocol with a slightly more elaborate user-space event-mechanism than the one we have in drm now. In particular we want to be able to read partial events, and resume event reading after a partial event. We would also want to be able to send commands either through an ioctl() or using write(). Current test code is using write().

Since the VNC server in our application typically will be system-wide, we need to resurrect a control-node functionality. I was trying to use sysfs attributes for this, but while sysfs supports rudimentary poll functionality. It's a bit too rudimentary and tracking client lifetime becomes racy. Perhaps control nodes renamed to "remoting" nodes or something similar. It might be that masters want to attach a VNC server to their current display and in that case we probably would want to expand primary nodes with this functionality as well.

Now to the open-sourceĀ  problem. As mentioned, the reference user-space will be a solution based on libvncserver. In fact there will be a small user-space interface library that libvncserver can interact with, similar to libdrm. However, I envision in the long run VMWare would be interested to use other remoting protocols with closed source protocol encoders, using the open source reference library. In theory, this solution would also allow for simple (open- or closed source) user-space display drivers, very similar to DisplayLink's evdi solution, even if that's not a use-case VMWare is currently interested in.

Thoughts and comments appreciated.


dri-devel mailing list

Reply via email to