Date: Thu, 28 May 2020 16:00:53 +0200 From: Henrik Gulbrandsen <henrik@gulbra.net> To: Peter Grehan <grehan@FreeBSD.org> Cc: FreeBSD Virtualization <freebsd-virtualization@freebsd.org> Subject: Re: [Bug 246121] [bhyve][PATCH] Append Keyboard Layout specified option for using VNC. Message-ID: <ebe9a4974e8cfbfbaad76e3673594512@www.gulbra.net> In-Reply-To: <bug-246121-27103-8Mbugs8UEO@https.bugs.freebsd.org/bugzilla/> References: <bug-246121-27103@https.bugs.freebsd.org/bugzilla/> <bug-246121-27103-8Mbugs8UEO@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2020-05-28 13:44, bugzilla-noreply@freebsd.org wrote: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246121 > > --- Comment #6 from Peter Grehan <grehan@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ebe9a4974e8cfbfbaad76e3673594512>