How to ignore user input (view-only mode) for a VNC server in Qt?
I have an embedded Qt application that is started as a GUI server using the -qws parameter. In addition to the framebuffer a VNC connection is also in use. I now want to restrict the VNC client to only be able to view the content of my application suppressing any user input (keyboard, mouse,...).
Can I configure this somehow for my Qt application via command line parameters or in the source code?
It would also help if I could detect if a key event was sent via the VNC connection but I cannot image how to get this information from Qt's event system. Any ideas in that direction?
If this is only possible with alternative VNC server approaches instead of Qt's one, I would also like to hear it :-)
@raven-worx Thanks for the response. I was not clear enough about my intention. I want to forbid the user interaction via VNC. The interaction via the actual interface should still be possible. The system should work in a "presentation-only" mode. Filtering the input events would render the application useless ;-)
well than this has nothing to do with Qt or? But is rather a VNC (server) setting?!
I assumed you are using the Qt VNC platform plugin...
I am using the Qt VNC Server. I want to use it to connect a client to the application but only be able to view the content not sending any commands. When setting up the VNC server in my application I need to configure it but it seems that I cannot setup the VNC so that no input is allowed.
- I'm using Qt with VNC on an embedded device
- In addition to the VNC "display" I'm using the regular embedded framebuffer
- The user on the embedded device should be able to interact with the device as usual
- The user connected via VNC should only be able to watch and not to interact/mess with the application
From a quick look at the VNC plugin source, you would need to modify it and add a parameter for "read-only" mode.
@SGaist said I was afraid that this would be the case. As far as I know the Qt VNC support should be used for debugging only and not offered to a customer. It works great so we wanted to use it anyways.
Do you have any idea how I could determine if an event was sent via the VNC connection without modifying Qt's source? Then I could filter those events and ignore them. I thought about querying the sender of the event somehow. Using the QObject::eventFilter does not work because the QObject* is actually the receiver and the QEvent* does not contain any information of it origin/sender. Do you have any ideas on that?
Sorry, I don't see a quick and clean way to do it.
@FrozenTarzan Which version of Qt is being used?
@SGaist Thanks for your quick answers anyways! :-)
@jeremy_k Qt for embedded Linux 4.8.6
Could you guys point me to a documentation of the QVNCServer? I could not find one that talkes about the C++ part or how to interact with the VNC server within the code. One can create a Qt server application by using the QApplication::GuiServer flag but it seems that I still need to configure it via the command line arguments or environment variables. Right now we use this:
export QWS_DISPLAY="Multi: transformed:Rot180:LinuxFb:tty=/dev/null VNC:0"
I would like to configure everything from source code or at least be able to enable/disable the VNC connection. It would even be ok for me to do it only in the constructor of the application since I'm afraid it is impossible to do that at run-time?
Aaaaaah... Crucial missing bit of information... I was assuming Qt 5...
Nevertheless the answer is the same BUT adding the code that would enable that is not that hard.
The files of interest are in
src/plugins/platforms/vnc/. The QVNCIntegration class is what handles the command line arguments specific to the VNC plugin. There you could add the read-only flag handling. Then add a property to QVNCServer that will allow you to ignore input related events.
To do it at run time you would need to modify Qt a bit more but it is doable also.
On a side note, you might want to consider 4.8.7 which is the latest and last version of the Qt 4 series.
@SGaist Thanks a lot for all the valuable input! :-)