I have recently posted a first version for a FreeRds backend for weston, the reference compositor for wayland. In this post, I will talk about that new compositor, if you have already read my post on the FreeRdp compositor you won't be lost.
FreeRds is a work-in-progress project that aims to provide a RDP server using the FreeRDP library. Xrdp was based on rdesktop, you can see FreeRds like its successor but with FreeRDP as the foundation classes.
Here's the architecture of FreeRds with weston providing the content to display:
FreeRds and the weston backend communicate with a unix socket and a shared memory. The socket is used for commands and the shared memory for the shared framebuffer. FreeRds takes care of all RDP related stuff, and the job of weston is to create the content to display.
This page saved my time for doing it, if it can help someone else...
This funny article gives some clues of why it is so hard to give a time estimation for a project.
Listening music during coding makes you remember the piece of code you were hacking when you listen back to that music. For me hearing the climax album of Alain Bashung makes think of voiceXml.
So here's some bands from Rennes that do electronic music:
http://www.youtube.com/watch?v=-3j6W3IWzsk
http://www.youtube.com/watch?v=K7SNGG50VSU
http://www.youtube.com/watch?v=ttQighnspkA
This is a yearly conference, I really like it. The content is often original and interesting. The slides and videos are available from this week. In all the interesting things I have read, my preferred were:
All the slides are located here.
This post covers the RDP compositor in weston, the reference compositor for wayland.
This 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 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:
In weston a backend implements access to seats (mouse, keyboard, ...) or output devices (GPU most of the time). The RDP compositor is based on the FreeRDP project to provide the RDP transport. This backend is headless, it uses a memory buffer as a video card and wires a seat per connected RDP peer. It uses the pixman renderer that will use the surfaces sent by wayland clients and will compose the desktop's picture. That means that even before we have any connected RDP client, the full picture is already computed.
The backend listens for incoming RDP connections, and instantiates a seat (mouse and keyboard) for each incoming peer. Each connected peer has its own pointer and focus (having 2 pointers is really funny).
When a wayland client as some activity, it notifies the compositor that will rebuild the desktop picture. It takes all the list of surfaces in z-index order and compose until the full screen has been painted (or when there's no more surfaces). The touched part of the screen are sent to the RDP peers, they're encoded either in raw format or using the NS or remoteFx codecs depending of the client capabilities. The compositor also handle the SUPPRESS_OUTPUT message sent by RDP clients when they don't want screen updates (this is the case when the window of a RDP client is iconified).
Theoretically with RDP you can have client-side pointer support, but adding in weston is not that easy:
For now we disable the client-side pointer completely, so when moving the mouse, weston does refreshes by sending pixmap updates.
Some ideas for the RDP compositors:
Here's some good links on the subject:
That's one month I'm working on a patch to fix the weston_switch_mode() function in weston, the reference wayland compositor. I didn't spend a month on that piece of code, but a few hours splitted over the last month. I had many discutions on IRC, worked on it, had comments on my patches, and finally the code should land in wayland/weston 1.3.
The commits:
So now when a RDP client connects on the RDP compositor and its resolution does not match the desktop resolution, it's the desktop that adjust its size and no more the client.
I've worked recently with my qfreerdp_platform plugin, and I've added some code to set the width or the height of the emulated screen as plugin arguments.
The code looks like that:
class QFreeRdpIntegration : public QPlatformIntegration {
public:
QFreeRdpIntegration(const QStringList& paramList);
~QFreeRdpIntegration();
/** ..... */
}
Then a trivial question came to me: how do I pass the plugin arguments ? Obviously the parameters will end in paramList but what's the name of the command line argument ?
After an hour of googling and searches in obscure Qt4 forum, the solution:
# myapp -platform plugin:arg1:arg2:...
Hope it helped.
A small video for geeks.
http://www.youtube.com/watch?v=TAJBc7gW-Vc
Other videos from the same author are cool too (my children liked the one with robots)