Hardening consulting

Author:

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 and weston

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 compositor

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.

Read more…

Author:

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:

Juvéniles

http://www.youtube.com/watch?v=-3j6W3IWzsk

Manceau

http://www.youtube.com/watch?v=K7SNGG50VSU

O-safari

http://www.youtube.com/watch?v=ttQighnspkA

Author:

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.

Author:

wayland This post covers the RDP compositor in weston, the reference compositor for wayland.

About wayland / weston

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: Architecture avec X11 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 backend

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:
  • 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.
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. RDP compositor 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).

Limitations and future

Client-side pointer

Theoretically 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.
For now we disable the client-side pointer completely, so when moving the mouse, weston does refreshes by sending pixmap updates.

The future

Some 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.

Links

Here's some good links on the subject:
  • this conference by Daniel Stone is a good (and funny) introduction on wayland;
  • the official documentation of wayland;
  • source code for the RDP compositor (code is the best documentation isn't it ?);
  • official site for FreeRDP

Author:

waylandThat'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:
  • The first one does massive renaming.
  • The second one does the job
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.

Author:

qt5

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.

Author:

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)