https://github.com/qguv/kernelflut
Connect a pixelflut screen as another (virtual) monitor in userspace using kernel evdi
https://github.com/qguv/kernelflut
c driver drm evdi kernel linux pixelflut
Last synced: 2 months ago
JSON representation
Connect a pixelflut screen as another (virtual) monitor in userspace using kernel evdi
- Host: GitHub
- URL: https://github.com/qguv/kernelflut
- Owner: qguv
- Created: 2019-02-17T16:19:49.000Z (over 7 years ago)
- Default Branch: master
- Last Pushed: 2023-02-16T09:03:19.000Z (over 3 years ago)
- Last Synced: 2026-03-27T11:45:30.282Z (2 months ago)
- Topics: c, driver, drm, evdi, kernel, linux, pixelflut
- Language: C
- Homepage:
- Size: 97.7 KB
- Stars: 8
- Watchers: 1
- Forks: 3
- Open Issues: 1
-
Metadata Files:
- Readme: README.md
Awesome Lists containing this project
README
# kernelflut
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
```
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)
```
## building
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.
## running
- `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
## troubleshooting
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
## performance optimizations
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.
## implementation
- userspace application
- connects to [`evdi`](https://github.com/DisplayLink/evdi) (root required 🙁)
- requests a virtual display and requests updates
- sends changed pixels to pixelflut
## todo
- easier build
- warn if `uid != 0`
- pictures
- multithreading with worker threads and shared memory