This post covers the RDP compositor in weston, the reference compositor for wayland.
About wayland / westonThis chapter does not pretend to cover all the differences between X11 and wayland, it just tries to give the big details. The goal of wayland is to replace X11, it is like the core of X11: an IPC (Inter Process Communication) mecanism between graphical applications. Taken from the wayland documentation, here's the workflow when an X11 application wants to notify a graphical change: You can see that you have plenty of communications and roundtrips until the modified bits reach the hardware. With wayland, it goes much faster: The philosophy of wayland is "every frame is perfect", the compositor will only send a finalized frame to the hardware. Forgot about tearing, flashes and graphical artifacts you can see under X11 when fastly moving a window.
The RDP backendThe weston project aims to be a reference compositor for wayland. The code should be clear and functional, and give enough material for people that want to implement their own compositor. The project implement a reference shell for a desktop (desktop-shell) and already have some backends for:
- DRM / KMS: to drive these API for video;
- udev: to access to input devices (mouse and keyboard);
- fbdev: the good old framebuffer;
- rpi: a backend to use that particular hardware.
Limitations and future
Client-side pointerTheoretically with RDP you can have client-side pointer support, but adding in weston is not that easy:
- for weston the mouse pointer surface is anonymous, so when rendering the full scene we should draw everything but this surface. Moreover with the multi-seat support we should maintain an image per seat, and draw everything but the surface of the current seat.
- RDP cursors can only be bitmaps or bitmasks so to support client-side pointer, we should scan the surface to check that it matches that requirement.
The futureSome ideas for the RDP compositors:
- map the RDP clipboard channel in wayland, to have copy'n paste between a RDP peer and the wayland applications;
- RDP8 has introduced mode switches initiated by the RDP client, everything is ready for that in weston and in the development branch of FreeRDP;
- implement a frame synchronization mecanism, as in the current code, weston sends as many frames as it can even if the network or the destination peer can't handle them;
- create a wayland extension of the protocol to access to RDP channels. I'm dreaming of a modified VLC that would use the TSMF channel (multimedia extension) and would play videos with the video decoding being done on the RDP client side.