From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33588) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YKkRw-0003GS-VT for qemu-devel@nongnu.org; Mon, 09 Feb 2015 04:16:13 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YKkRt-0001jg-QA for qemu-devel@nongnu.org; Mon, 09 Feb 2015 04:16:12 -0500 Received: from mx1.redhat.com ([209.132.183.28]:36932) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YKkRt-0001jb-Gf for qemu-devel@nongnu.org; Mon, 09 Feb 2015 04:16:09 -0500 Message-ID: <1423473364.13413.39.camel@nilsson.home.kraxel.org> From: Gerd Hoffmann Date: Mon, 09 Feb 2015 10:16:04 +0100 In-Reply-To: References: <1423470425.13413.15.camel@nilsson.home.kraxel.org> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Definition of the UI layer's "key number" ? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: QEMU Developers On Mo, 2015-02-09 at 08:31 +0000, Peter Maydell wrote: > On 9 February 2015 at 08:27, Gerd Hoffmann wrote: > > Well, we have two ways to represent a key code in qemu, unfortunately in > > the QMP api (see KeyValue in qapi-schema.json). > > > > One is QKeyCode (defined in qapi-schema.json too), the other "key > > number" is the key coding used pretty much everywhere in qemu before the > > input layer rewrite (the new code in ui/input*.c) got merged. It is > > based on ps/2 keycodes. > > > > For new code I strongly suggest to simply ignore the old "key number" > > coding and use QKeyCodes exclusively, it allows you to have nicely > > readable mappings like the one in ui/sdl2-keymap.h. Then use > > qemu_input_event_send_key_qcode() to feed the guest with the keyboard > > input. > > > > ui/input-keymap.c has a table to map QKeyCodes to "key numbers" and > > helper functions to translate codes both ways. > > Thanks. How do we handle key codes which don't exist in the translation > tables in input-keymap.c? Specifically, we need to support the > "keypad =" key which exists on some Mac keyboards (both for sending > it if you're using this keyboard on the host and for receiving it > if you're using the ADB keyboard in the guest). There is a > Q_KEY_CODE_KP_EQUALS but it doesn't have a table entry, and since > both the guest code and the frontend UI code in question use old > style keycodes I'd rather the answer wasn't "convert both of them > to use QKeyCode"... Hmm, this certainly is the cleanest approach and it is exactly what I did for sparc. They had some special key numbers in the 0xf0 .. 0xff range for keys present on the sparc keyboard but not ps/2. sparc kbd emulation (in hw/char/escc.c) got converted to use QKeyCodes so I could drop those numbers. The keymap in the sparc kbd emulation also became much nicer in the process. qcode_to_number[] in ui/input-keymap.c basically defines what our "key numbers" are, so we could extend this with non-ps/2 keys, simliar to how it was done for the sparc keys in the past. It's hackish, but should work as long as the number of additional keys is small. cheers, Gerd