From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:48296) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TF6IZ-0005Yu-6q for qemu-devel@nongnu.org; Fri, 21 Sep 2012 12:41:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TF6IT-0007ce-CR for qemu-devel@nongnu.org; Fri, 21 Sep 2012 12:41:51 -0400 Received: from mx1.redhat.com ([209.132.183.28]:34303) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TF6IT-0007cY-4n for qemu-devel@nongnu.org; Fri, 21 Sep 2012 12:41:45 -0400 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q8LGfieS023910 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 21 Sep 2012 12:41:44 -0400 Date: Fri, 21 Sep 2012 13:42:34 -0300 From: Luiz Capitulino Message-ID: <20120921134234.5d836bc5@doriath.home> In-Reply-To: <505C965B.1050504@redhat.com> References: <1348239340-29021-1-git-send-email-lcapitulino@redhat.com> <1348239340-29021-3-git-send-email-lcapitulino@redhat.com> <505C965B.1050504@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 2/3] qmp: qmp_send_key(): accept key codes in hex List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: akong@redhat.com, qemu-devel@nongnu.org, avi@redhat.com On Fri, 21 Sep 2012 10:31:23 -0600 Eric Blake wrote: > On 09/21/2012 08:55 AM, Luiz Capitulino wrote: > > This commit fixes the problem by adding hex value support down > > the QMP interface, qmp_send_key(). > > > > > +++ b/qapi-schema.json > > @@ -2588,12 +2588,25 @@ > > 'lf', 'help', 'meta_l', 'meta_r', 'compose' ] } > > > > ## > > +# @KeyValue > > +# > > +# Represents a keyboard key. > > +# > > +# Since: 1.3.0 > > +## > > +{ 'union': 'KeyValue', > > + 'data': { > > + 'hex': 'int', > > Don't you find it a bit odd to name this 'hex', even though it works to > do 'hex':32 as a synonym for 'hex':0x20? Should we instead name it > 'value', since we don't care in what base the value was represented, > only that JSON was able to decode the base into a value? Yes, that's a good point. I'll respin.