# Using FreeRDP logging facility

When you're working on FreeRDP, it's quite usual to increase the log level and to have to collect a massive amount of logs. And most often it doesn't fit in the terminal backscroll history, or it is so slow (terminal rendering is CPU intensive) that you need a file storage. Another case is when you're on a remote host and you want to retrieve the log over the network.

As each time I want to use the WLog capacities I'm looking at the source code, I had the idea to write that post on the subject, so that next time I will look at this text.

# Twisted tricks

While working on topka, I've used the twisted framework. Twisted tutorials are really good with lots of practical examples, anyway after using the framework for weeks, I gain enough experience to write a post about some tricks I've discovered.

Disclaimer: you will not find here something that is not already in the twisted docs.

## Using deferred

While using twisted, it happens that you can be a situation where you can either return a final value or do the computation asynchronously and return a Deferred. The code looks like:

import twisted.internet.defer as defer

def myFunc():
def treatRet():
...

ret = functionThatProcess(...)
if isinstance(ret, defer.Deferred):
else:
ret = treatRet(ret)

return ret


# Ogon opensourcing

Better late than never. Four years ago I was giving a talk on FreeRDS at the XDC 2014 and I was announcing that we would opensource the project at the end of the year. The opensourcing is finally here but in April 2018, you can observe a kind of delay !

### We were late

So obviously lots of things have occured since 2014. First the project's name has changed: it was initially FreeRDS but the name was owned by one of the project's member. And our fork has diverged a lot, so there was the necessity for a new name. We thought at fireRDS,

# Let's play with meson

After watching a video on meson, it made me want to play with this software to see how it was in practise. So I did a first shot on a OGON subproject that uses cmake as build system.

## Lovely CMake

I often hear that everybody hates cmake, but lots of projects use it anyway. So most probably it's for bad reasons. I'm not an exception, and as soon as I have to touch these lovely CMakeFile.txt, I always feel dirty, or at least I never have the impression to have done some nice job. This happens even when everything goes as I wanted. Not even talking of when things go wrong, with epic debugging sessions. I must be missing the cmake pĥilosophy because everytime I suspect a behaviour, cmake does it the opposite way. So everytime there's some cmake involved I'm reticent to go in that work.

# Linux Conference Australia 2018

The LCA (inux Conference Australia) is one of my favorite conference, with talks of good technical level. Some years ago, it's a talk by Daniel Stone that lead me to start playing with Wayland.

A selection of my preferred talks:

• The talk by Keith Packard on VR helmet in X, it was very interesting. A nice trip in the Xorg world;

# Resizing FreeRDP window

Let's start this new year (best wishes) with some RDP stuff, in this post I will talk of an implementation to resize the window in xfreerdp.

## Context

FreeRDP already had the smart-sizing option, it allows to see the window with a given aspect ratio: 100, 150 ou 180 percent.

With the MS-RDPEDISP specification, the client can send its monitors layout to the server in real time, that allows the server to react when an output is plugged or unplugged, or when the resolution changes. You can experiment that with mstsc in fullscreen mode, if you change resolution while the mstsc window is iconized, when you uniconize, it is supposed to resize.

You can also use that specification to make the RDP window resizable: you announce a monitor that has the size of the client window.

# Using the VAAPI with ffmpeg

For some project I had the opportunity to look at H264 decoding and the hardware decoding using VAAPI. An ideal excuse to write a post on that subject...

## What is VAAPI ?

Taken from Wikipedia:

The main motivation for VA API is to enable hardware-accelerated video decode at various entry-points
(VLD, IDCT, motion compensation, deblocking) for the prevailing coding standards today (MPEG-2, MPEG-4
ASP/H.263, MPEG-4 AVC/H.264, H.265/HEVC, and VC-1/WMV3). Extending XvMC was considered, but due to its
original design for MPEG-2 MotionComp only, it made more sense to design an interface from scratch that
can fully expose the video decode capabilities in today's GPUs.


This API is also usable directly with a DRM device, a DRI render node for example: very neat to offload the GPU decoding without a X server. You can also use it from Wayland of course.

The idea is to feed the GPU with a video stream (H264, VP9 ou MPEG) and the GPU will do the decoding and the rendering in a surface.

# Supporting reconnection in RDP

Yes, another post on RDP ! I did some experiments with automatic reconnection, so this post talks about that project.

## Automatic reconnection

Automatic reconnection allows a RDP client to automatically reconnect to the server without the need to re-authenticate. The typical example is when you close the lid of your laptop with an active RDP session, when you open it again, the client will reconnect automagically. This can also be the case with a network problem.

# The DJI Phantom 3 protocol

Looking at my Piwik stats I've seen some interest with my previous DJI Phantom 3 posts. I've also seen a guy that has quite the same goal as me: writing a PC-based ground station software to drive a phantom 3.

So I guess it's time to speak of my discoveries regarding the protocol that is spoken between the remote controller, the camera, the mobile app and the drone.

## Protocol basics

First the packets are split in two parts: a header and a payload.

The header has the following format:

-------------------------------------------------------------------------
| 0 0 0 0 0 0 0 0 | 0 0 1 1 1 1 1 1 | 1 1 1 1 2 2 2 2 | 2 2 2 2 2 2 3 3 |
| 0 1 2 3 4 5 6 7 | 8 9 0 1 2 3 4 5 | 6 7 8 9 0 1 2 3 | 4 5 6 7 8 9 0 1 |
|-----------------------------------------------------------------------|
|  magic - 0x55   |    payload length    |  version   |     crc8        |
-------------------------------------------------------------------------


There's the 0x55 magic on 1 byte. Followed by a lenVer field on 2 bytes, it contains length of the payload and version of the protocol in the 6 upper bits. And then you have
a custom crc8 of the first 3 bytes.

The payload size is limited to 4096 bytes. As magic and protocol version never change, you can notice that only the size of the payload influence the crc8. So you can have a table that list some lengths and give the expected crc8 result.

The crc8 is there to be sure we have a header and that we may read the payload (well we can't be sure as it's just a crc8 but at least it give a good level of confidence).

# xfreerdp /v:myserver /multimon /f