From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58706) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XYgfH-000371-3r for qemu-devel@nongnu.org; Mon, 29 Sep 2014 15:31:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XYgfA-0004lr-VX for qemu-devel@nongnu.org; Mon, 29 Sep 2014 15:31:19 -0400 Received: from mx1.redhat.com ([209.132.183.28]:34567) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XYgfA-0004kO-OR for qemu-devel@nongnu.org; Mon, 29 Sep 2014 15:31:12 -0400 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s8TJV6TG022793 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Mon, 29 Sep 2014 15:31:07 -0400 Date: Mon, 29 Sep 2014 16:30:45 -0300 From: Marcelo Tosatti Message-ID: <20140929193045.GA30934@amt.cnet> References: <20140929185610.GA28309@amt.cnet> <5429AF2C.7000001@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5429AF2C.7000001@redhat.com> Subject: Re: [Qemu-devel] [PATCH v3] add input-send-event command List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: Amos Kong , Gerd Hoffmann , qemu-devel On Mon, Sep 29, 2014 at 01:12:44PM -0600, Eric Blake wrote: > On 09/29/2014 12:56 PM, Marcelo Tosatti wrote: > > > > Which allows specification of absolute/relative, > > up/down and console parameters. > > > > Suggested by Gerd Hoffman. > > > > Signed-off-by: Marcelo Tosatti > > > > --- > > qapi-schema.json | 17 +++++++++++++++ > > qmp-commands.hx | 63 +++++++++++++++++++++++++++++++++++++++++++++++++++++ > > ui/input.c | 31 ++++++++++++++++++++++++++ > > 3 files changed, 111 insertions(+) > > > > diff --git a/qapi-schema.json b/qapi-schema.json > > index 4bfaf20..2e9e261 100644 > > --- a/qapi-schema.json > > +++ b/qapi-schema.json > > @@ -3233,6 +3233,23 @@ > > 'abs' : 'InputMoveEvent' } } > > > > ## > > +# @input-send-event > > +# > > +# Send input event(s) to guest. > > +# > > +# @console: Which console to send event(s) to. > > +# > > +# @events: List of InputEvent union. > > +# > > +# Returns: Nothing on success. > > +# > > +# Since: 2.2 > > +# > > +## > > +{ 'command': 'input-send-event', > > + 'data': { 'console':'int', 'events': [ 'InputEvent' ] } } > > 'console' is mandatory; I guess that's okay. > > Are we guaranteed that either all events are sent? Or is there a need to Events can be dropped at hardware level if the event queue is full, for example. Would have to modify individual drivers to return error codes, i suppose. Gerd? > worry about partial success (on a list of 3 events, the first gets sent, > then some error is encountered on the second, and the third is not > attempted)? Are the only errors due to something that can be detected > up front (such as trying to send a mouse event to a console that has > only keyboard support)? > > > +The consoles are visible in the qom tree, under > > +/backend/console[$index]. They have a device link and head property, so > > +its possible to map which console belongs to which device and display. > > s/its/it's/ (or 'it is') > > > +void qmp_input_send_event(int64_t console, InputEventList *events, > > + Error **errp) > > +{ > > + InputEventList *e; > > + QemuConsole *con; > > + > > + con = qemu_console_lookup_by_index(console); > > + if (!con) { > > + error_setg(errp, "console %" PRId64 " not found", console); > > + return; > > + } > > + > > + if (!runstate_is_running() && !runstate_check(RUN_STATE_SUSPENDED)) { > > + error_setg(errp, "VM not running"); > > + return; > > + } > > + > > + for (e = events; e != NULL; e = e->next) { > > + InputEvent *event = e->value; > > + > > + if (!qemu_input_find_handler(1 << event->kind, con)) { > > + error_setg(errp, "Input handler not found for " > > + "event type %s", > > + InputEventKind_lookup[event->kind]); > > + return; > > > Ouch. You can return mid-loop. I'd be more comfortable with a two-pass > algorithm (first pass ensures all list elements have a handler, second > actually calls qemu_input_event_send) or with a return that gives an > integer count of how many list items were processed. Sure.