From owner-freebsd-virtualization@freebsd.org Thu May 28 14:01:00 2020 Return-Path: Delivered-To: freebsd-virtualization@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 23FFC2F31B0 for ; Thu, 28 May 2020 14:01:00 +0000 (UTC) (envelope-from henrik@gulbra.net) Received: from srv.gulbra.net (ec2-174-129-193-206.compute-1.amazonaws.com [174.129.193.206]) by mx1.freebsd.org (Postfix) with ESMTP id 49Xq9R2XYCz4g31 for ; Thu, 28 May 2020 14:00:59 +0000 (UTC) (envelope-from henrik@gulbra.net) Received: from srv.gulbra.net (localhost [127.0.0.1]) by srv.gulbra.net (Postfix) with ESMTP id D345CFD1 for ; Thu, 28 May 2020 14:00:53 +0000 (UTC) Received: by srv.gulbra.net (Postfix, from userid 33) id AD31FFD2; Thu, 28 May 2020 14:00:53 +0000 (UTC) To: Peter Grehan Subject: Re: [Bug 246121] [bhyve][PATCH] Append Keyboard Layout specified option for using VNC. X-PHP-Originating-Script: 0:rcube.php MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 28 May 2020 16:00:53 +0200 From: Henrik Gulbrandsen Cc: FreeBSD Virtualization In-Reply-To: References: Message-ID: X-Sender: henrik@gulbra.net User-Agent: Roundcube Webmail/1.2-beta X-Rspamd-Queue-Id: 49Xq9R2XYCz4g31 X-Spamd-Bar: +++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of henrik@gulbra.net has no SPF policy when checking 174.129.193.206) smtp.mailfrom=henrik@gulbra.net X-Spamd-Result: default: False [3.18 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.10)[-0.104]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.06)[0.057]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-virtualization@freebsd.org]; DMARC_NA(0.00)[gulbra.net]; HAS_X_POS(0.00)[]; AUTH_NA(1.00)[]; PHP_SCRIPT_ROOT(1.00)[]; TO_DN_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_LONG(0.73)[0.732]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_NA(0.00)[no SPF record]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:14618, ipnet:174.129.0.0/16, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_WWW(0.50)[] X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Discussion of various virtualization techniques FreeBSD supports." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2020 14:01:00 -0000 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 --- > 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