uwerat / vnc-eglfs Goto Github PK

Using cmake instead of qmake

We need to have some sort of support for the Authentication/Security being defined in the RFB specification.
makes sense to support V3.3, V3.7 and V3.8 then as the RFB protocol differs for this functionality.

Support for the pseudo encoding "Cursor with Alpha" ( -314 ) should be low hanging fruits

Let's see how to make better use of the GPU: https://intel.github.io/libva/index.html

• JPEG encoding
• H.264 encoding
• ???

When resizing a window we need to remove all rectangles from the dirtyRegion.

At the moment the framebuffer is grabbed on the scene graph thread, but converting it into the format being requested by the client happens in the GUI thread.

Probably the best way to solve this is to move each instance of VncClient in its own thread. This also allows to use blocking reads, when waiting for client messages.

There are problems with special keys like "Shift", that end up as an extra character in the text input field

/usr/bin/ld: cannot find -lvncgl

Instead of flipping the grabbed framebuffer we could invert the order of the lines when iterating in inverted order when sending the lines to the wire. ( minor performance improvement )

Let's see if libjpeg-turbo ( https://libjpeg-turbo.org ) is that faster

How to deal with cursors being updated by shaders ?

zlib encoding should be an easy to have compression

Got this error:

../../git/src/VncServer.cpp:235:17: error: 'class QImage' has no member named 'convertTo'

According to the doc, this method exists starting from Qt 5.13. I don't know if there are other methods which require even superior releases, but this for sure requires something newer than 5.12.

Considering that the image composition happens on the GPU and many modern GPUs offer H.264 encoding this sounds like an interesting approach to solve low bandwidth problems, when always sending fullscreen updates.

Not sure if there is a VNC viewer on te market that supports H.264 and we might need to implement our own client - at least for testing.

We could offer an optional platform plugin, that creates a headless environment ( using gbm ) and starts VNC support.

We would have the same limitations as with the Qt VNC platform plugin ( local/remote access are mutually exclusive ), but we would have VNC support for applications without any adjustments to the source code.

Maybe we even find another type of plugin that is loaded by every Qt/Quick applicaton, that could be used.

Currently clients, that do not have true color support are rejected. Not sure how important such feature is in 2022 - but anyway.