On 2020-05-28 13:44, bugzilla-nore...@freebsd.org wrote:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246121
--- Comment #6 from Peter Grehan <gre...@freebsd.org> ---
TigerVNC in ports is v1.10.1, which is the latest official release. The
Qemu
key event code has been in there for a couple of years now.
I'll have a look at how much work it is to support that extension, but
I grant
that a) it isn't supported by other VNC clients, and b) the performance
of
TigerVNC is worse than TightVNC. So, the keymap change is still likely
worthwhile. I'll take a closer look at your patch.
Regarding (b): Is TigerVNC always worse than TightVNC, or could this
be a bhyve-specific problem?
When I wrote my Video BIOS code one year ago, I noticed that bhyve is
sending updates continuously from rfb_wr_thr(), without any requests.
On the other hand, the RFB protocol specification says that "an update
is only sent from the server to the client in response to an explicit
request from the client", so bhyve seems to technically break this.
I tested my code with TigerVNC, and at one point I ended up with a very
long delay for keyboard events. From my diary at the time (2019-05-02):
"In any case, I finally found the cause of the long input queue.
TigerVNC sends a new update request for each display update it
gets, and it only expects to get one, but bhyve sent a separate
update for each rectangle, so as soon as display updates started,
the input buffer filled up with update requests."
By then, I had probably already changed the rfb.c code a lot, but any
delay for TigerVNC could be due to a similar issue. I guess different
VNC clients would react differently to unexpected update messages.
Anyway, I wanted to mention it before you rewrite the RFB code again.
My patch is still in limbo at https://www.gulbra.net/freebsd-bhyve/,
and the changes in rfb.c are those that are most likely to conflict
with other modifications. It would be better for me if I don't have to
do the same debugging all over again if I finally return to this code.
/Henrik
_______________________________________________
freebsd-virtualization@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to
"freebsd-virtualization-unsubscr...@freebsd.org"
