From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:52402) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UF44d-0002pP-87 for qemu-devel@nongnu.org; Mon, 11 Mar 2013 10:51:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UF44Y-0002qq-JA for qemu-devel@nongnu.org; Mon, 11 Mar 2013 10:51:35 -0400 Received: from mx1.redhat.com ([209.132.183.28]:64095) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UF44Y-0002qU-AK for qemu-devel@nongnu.org; Mon, 11 Mar 2013 10:51:30 -0400 Message-ID: <513DEF6C.8080108@redhat.com> Date: Mon, 11 Mar 2013 15:51:24 +0100 From: Gerd Hoffmann MIME-Version: 1.0 References: <1362752571-2056-1-git-send-email-kraxel@redhat.com> <1362752571-2056-3-git-send-email-kraxel@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2 2/2] input: introduce keyboard handler list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Anthony Liguori , qemu-devel@nongnu.org, armbru@redhat.com Hi, > The major difference is that where this code sends key events > to the first handler only, the Nokia patch sends events to > all keys, because the use case it's trying to deal with is > "some keys should go to one device and some to another" > (for example, most keys go to a usb keyboard but F-keys > are treated as being like some of the hardware buttons on > the phone, and they go to a different device in the model). > Maybe we could deal with this by having kbd_put_keycode() > send the event to every register keyboard until one of > them says it has handled it [ie have the put_kbd callback > return a handled/not-handled return]. Yea, sending to all doesn't fly in general as guests with ps/2 + usb kbd would see all keys twice then ... Having a "handled" return code makes sense to me. IIRC glib has something simliar (return true == handled, return false == call next handler please). > That would still > leave the issue that you need to make sure that keyboard > handlers get called in the right order (perhaps a priority > thing on registering?) A priority field is more robust I think. > Anyway, no objection to this patch (and I'm certainly not > trying to say you should fix my problems in this patch), > I just thought I'd mention this other usecase for multiple > keyboards while it was in my head. Should be easy to add support for this on top of this series. cheers, Gerd