From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Np2x9-0005nt-7Z for qemu-devel@nongnu.org; Tue, 09 Mar 2010 12:10:43 -0500 Received: from [199.232.76.173] (port=37315 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Np2x8-0005mo-D5 for qemu-devel@nongnu.org; Tue, 09 Mar 2010 12:10:42 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1Np2x7-0004Vv-76 for qemu-devel@nongnu.org; Tue, 09 Mar 2010 12:10:42 -0500 Received: from mail-fx0-f224.google.com ([209.85.220.224]:38946) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Np2x6-0004Vn-Uh for qemu-devel@nongnu.org; Tue, 09 Mar 2010 12:10:41 -0500 Received: by fxm24 with SMTP id 24so815351fxm.17 for ; Tue, 09 Mar 2010 09:10:39 -0800 (PST) Message-ID: <4B96810B.2070309@codemonkey.ws> Date: Tue, 09 Mar 2010 11:10:35 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH v2 1/4] kbd leds: infrastructure References: <1267201059-24145-1-git-send-email-kraxel@redhat.com> <1267201059-24145-2-git-send-email-kraxel@redhat.com> <4B96631E.4020700@codemonkey.ws> <201003091558.24975.paul@codesourcery.com> <4B9673A3.9070601@redhat.com> <4B96771B.5020509@codemonkey.ws> <4B967A48.5030005@redhat.com> In-Reply-To: <4B967A48.5030005@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: Paul Brook , qemu-devel@nongnu.org On 03/09/2010 10:41 AM, Gerd Hoffmann wrote: > On 03/09/10 17:28, Anthony Liguori wrote: >> If a person has a guest that twiddles with LEDs, what are the chances >> they are going to figure out that there's an option with VNC to not use >> LED status as part of the modifier tracking heuristics? >> >> I don't think it's really useful. Like I said in an earlier note, we're >> already dealing with a heuristics based algorithm because we're >> attempting to detect dangling modifier presses. I'd rather see an option >> that disabled the whole thing verses something specific to the LEDs. > > You are referring to the > do-i-should-insert-extra-capslock/numlock-events logic in do_key_event() ? Yup. > Well, we can turn off both, fine with me, after all they sort-of > belong together. Do you have an idea for a short > 'no-capslock-and-numlock-tracking-heuristics' option name? Maybe 'toggle-key-tracking=on|off' with an appropriate documentation blurb. I don't know, it doesn't sound like a good name to me. Regards, Anthony Liguori > > cheers, > Gerd >