From patchwork Fri Apr 11 08:01:31 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Gerd Hoffmann X-Patchwork-Id: 338416 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 7C8B91402C9 for ; Fri, 11 Apr 2014 18:02:06 +1000 (EST) Received: from localhost ([::1]:56382 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WYWPU-00044w-IN for incoming@patchwork.ozlabs.org; Fri, 11 Apr 2014 04:02:04 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39647) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WYWP9-00043g-Ip for qemu-devel@nongnu.org; Fri, 11 Apr 2014 04:01:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WYWP3-0007br-73 for qemu-devel@nongnu.org; Fri, 11 Apr 2014 04:01:43 -0400 Received: from mx1.redhat.com ([209.132.183.28]:14545) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WYWP2-0007bl-VG for qemu-devel@nongnu.org; Fri, 11 Apr 2014 04:01:37 -0400 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s3B81YRp017017 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 11 Apr 2014 04:01:34 -0400 Received: from [10.36.6.152] (vpn1-6-152.ams2.redhat.com [10.36.6.152]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s3B81WSW028951; Fri, 11 Apr 2014 04:01:33 -0400 Message-ID: <1397203291.22291.55.camel@nilsson.home.kraxel.org> From: Gerd Hoffmann To: "Michael S. Tsirkin" Date: Fri, 11 Apr 2014 10:01:31 +0200 In-Reply-To: <20140410151420.GB21110@redhat.com> References: <1397120874-17166-1-git-send-email-kraxel@redhat.com> <1397120874-17166-7-git-send-email-kraxel@redhat.com> <20140410105533.GA19546@redhat.com> <1397130428.16790.91.camel@nilsson.home.kraxel.org> <20140410151420.GB21110@redhat.com> Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 209.132.183.28 Cc: virtio-dev@lists.oasis-open.org, qemu-devel@nongnu.org, Anthony Liguori Subject: Re: [Qemu-devel] [PATCH qemu 4/6] virtio-input: emulated devices X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Sender: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Hi, > If drivers don't expect a mix of functionality, then separate IDs > seem better. The linux kernel can deal with it just fine. It's just that humans are more used to have separate devices. And I remember back in the dark xen days the input channel for xenfb was a unified input device which delivered both mouse and keyboard events, and it caused some grief with the X11 configuration. While thinking about it: We could certainly make this user-configurable. So instead of adding three new devices we just add one with config options. Then we'll have -device virtio-input-emulated-pci,kbd=on instead of -device virtio-keyboard-pci Likewise for mouse and tablet. And it'll be possible then to just do -device virtio-input-emulated-pci,kbd=on,tablet=on to get a unified device. > OTOH an advantage to using a custom identification scheme would be > if you want to allow a single device to change type > dynamically. Changing dynamically isn't going to happen. > Or more interestingly, as we migrate from host with a mouse > to an MT one, switch from a mouse to a touch device? Multitouch is tricky, especially the input side. gtk+sdl ui could work without too much trouble. spice+vnc need protocol extensions for that. Not investigated yet in detail. Guess it's a good excuse to expense a new, shiny and multi-touch capable monitor ;) Singletouch is easy. We'll basically send BTN_TOUCH instead of BTN_LEFT. And with some additional tweaks (such as filtering out any move events with mousebutton/finger lifted) we can even use normal mouse input to fake a touch screen. > > All keys in linux/input.h are supported by the virtio input protocol. > > I'm asking how is this versioned: assume that linux adds > a new keycode, existing guests don't expect it. > Don't we need any negotiation? Is it really always safe to > ignore keypresses? Worst case is a non-working key. I also don't think you'll run into this in practice. All fundamental stuff is there. Stuff which gets added now is pretty exotic, like this: =================== cut here ====================== And if you really care about this you'll probably make sure your guests do know what these key codes are for anyway ;) > > The current qemu kbd emulation covers all keys qemu knows (see QKeyCode > > in qapi-schema.json). > > Hmm SDL can give us a bunch of codes like volume up/down > that you don't seem to include. Disclaimer: I havn't added QkeyCode, it was there already. I expect QKeyCode learn more keys in the future. The input layer rewrite in the 2.0 devel cycle moved QKeyCode into the focus as it is used more widely in qemu now. Until recently it was used only for the sendkey monitor command. cheers, Gerd =================== cut here ====================== commit 5a1bbf21325bd4f2641f6141fb8c47f6095578dd Author: Dmitry Torokhov Date: Sat Feb 2 11:53:47 2013 -0800 Input: add new keycodes for passenger control units Entertainment systems used in aircraft need additional keycodes for their Passenger Control Units, so let's add them. Signed-off-by: Dmitry Torokhov diff --git a/include/uapi/linux/input.h b/include/uapi/linux/input.h index 5588285..6e4e3c6 100644 --- a/include/uapi/linux/input.h +++ b/include/uapi/linux/input.h @@ -702,6 +702,11 @@ struct input_keymap_entry { #define KEY_CAMERA_LEFT 0x219 #define KEY_CAMERA_RIGHT 0x21a +#define KEY_ATTENDANT_ON 0x21b +#define KEY_ATTENDANT_OFF 0x21c +#define KEY_ATTENDANT_TOGGLE 0x21d /* Attendant call on or off */ +#define KEY_LIGHTS_TOGGLE 0x21e /* Reading light on or off */ + #define BTN_TRIGGER_HAPPY 0x2c0 #define BTN_TRIGGER_HAPPY1 0x2c0 #define BTN_TRIGGER_HAPPY2 0x2c1