Boost your windows WMs
Windows VMs are so slow under KVM. When you're a FreeRDP developper, you always end up with being forced to have windows
VMs to test that old features are still working, or to test new shiny features (yes I love unicorns).
Windows VMs are so slow under KVM. When you're a FreeRDP developper, you always end up with being forced to have windows
VMs to test that old features are still working, or to test new shiny features (yes I love unicorns).
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.
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.
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): ret.addCallback(treatRet) else: ret = treatRet(ret) return ret
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 !
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,
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.
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.
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:
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.
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.
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...
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.