Date: Fri, 29 May 2020 08:27:42 +1000 From: Peter Grehan <grehan@freebsd.org> To: Henrik Gulbrandsen <henrik@gulbra.net> Cc: FreeBSD Virtualization <freebsd-virtualization@freebsd.org> Subject: Re: [Bug 246121] [bhyve][PATCH] Append Keyboard Layout specified option for using VNC. Message-ID: <0f397482-9656-7fac-fc00-9d60efaa5954@freebsd.org> In-Reply-To: <ebe9a4974e8cfbfbaad76e3673594512@www.gulbra.net> References: <bug-246121-27103@https.bugs.freebsd.org/bugzilla/> <bug-246121-27103-8Mbugs8UEO@https.bugs.freebsd.org/bugzilla/> <ebe9a4974e8cfbfbaad76e3673594512@www.gulbra.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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): >=20 > =C2=A0=C2=A0=C2=A0 "In any case, I finally found the cause of the long= input queue. > =C2=A0=C2=A0=C2=A0=C2=A0 TigerVNC sends a new update request for each = display update it > =C2=A0=C2=A0=C2=A0=C2=A0 gets, and it only expects to get one, but bhy= ve sent a separate > =C2=A0=C2=A0=C2=A0=C2=A0 update for each rectangle, so as soon as disp= lay updates started, > =C2=A0=C2=A0=C2=A0=C2=A0 the input buffer filled up with update reques= ts." Ok, that's an optimization that could be done: I think there's enough=20 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0f397482-9656-7fac-fc00-9d60efaa5954>