Hi Henrik,
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.
So do the clients that don't send any UpdateRequest messages at all. Spec compliance in the VNC world is a very loose definition :(
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."
Ok, that's an optimization that could be done: I think there's enough info to do that in an update.
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.
And the majority do.
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.
Thanks; I 'll have a look at it. later, Peter. _______________________________________________ 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"
