Connect a pixelflut screen as another (virtual) monitor. Set a monochrome background and drag windows onto it. Use your own WM as a pixelflut client.

Usage:
  sudo kernelflut [options...] [HOST [PORT]]

Arguments:
  HOST            pixelflut hostname (default localhost)
  PORT            pixelflut port (default 1337)

Options:
  -a              use async i/o
  -b RRGGBB       occasionally blit every pixel except this one
  -c CONNECTIONS  size of pixelflut connection pool (default 8)
  -d WxH          scale down to width W and height H
  -o X,Y          move the top-left corner down by Y pixels and right by X pixels
  -s              increase SO_SNDBUF socket buffers by 2x (can pass multiple times)
  -p              do a performance test (time five screen updates)

You need to build and install the evdi kernel module, then build and install the evdi userspace library, then build and install kernelflut itself. This looks something like:

1. make insmod to build and install the EVDI kernel module. This must be done on each boot.
2. make evdi_install to build and install the EVDI userspace library. This only needs to be done once.
3. make run to build and run kernelflut.

• sudo kernelflut
• open a display configuration tool for projectors or external monitors (I like lxrandr)
• enable the (virtual) monitor and place it somewhere with respect to your other monitors
• drag stuff to the new "screen" and you'll see it begin to send to pixelflut

Can't run it?

• is the evdi module loaded? it should be
• is your kernel new enough for evdi? update it
• is your kernel TOO new for evdi? try updating evdi, but beware this may break kernelflut. make update_evdi
• have you fiddled with the kernel's DRM (direct rendering manager) subsystem? please return to mainline for now

Nothing happens/runtime errors?

• are you using a displaylink USB-C dock? this could interfere because it also uses evdi. I don't own one so I have no clue

When playing pixelflut, the bottleneck is almost definitely network transmission. You can try these things to optimize this:

• Run tests with various options using the kernelflut -p flag. Without data, your performance is speculation. Control the testing environment—make sure traffic to the pixelflut server stays relatively constant during and across your tests. The best way to do this is by ensuring you're the only user. Beware testing against a local pixelflut server; because your machine is handling the load of the send and receive simultaneously, performance will decrease more quickly as a factor of traffic.
• Blit to a smaller area using -d and -o options to kernelflut. Performance will improve dramatically.
• Set a single, very bright solid color desktop wallpaper for the kernelflut virtual screen (#ff00ff works well) and register it with -b ff00ff (or whatever color you chose) when running kernelflut. This will refuse to send pixels of that color to pixelflut, which will avoid ever blitting your background to the screen. This can improve performance on very busy pixelflut displays, but will also cause windows to linger as you move them (win xp style).
• Enable the kernelflut -s flag to increase system socket send buffer length. You can pass it multiple times, each time doubling the amount of memory allocated to each socket send buffer. Your system maximum is ignored. Beware extreme, difficult-to-track RAM usage! Consider decreasing the number of connections (-c) to compensate!
• Increase or decrease the number of connections using the -c flag to kernelflut. Connections are established on program start.
• Enable the kernelflut -a flag to enable asynchronous I/O. I don't think this is actually useful—let me know how it changes the performance on your system!

In case network is not the bottleneck, try:

• disabling redshift
• fiddling with your compositor: disable or enable it. Turn really fancy stuff off. Compton seems to work ok.

• userspace application
• connects to evdi (root required 🙁)
• requests a virtual display and requests updates
• sends changed pixels to pixelflut

• easier build
• warn if uid != 0
• pictures
• multithreading with worker threads and shared memory