[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH for-2.5 2/2] input: Promote 'input-send-event' t
From: |
Gerd Hoffmann |
Subject: |
Re: [Qemu-devel] [PATCH for-2.5 2/2] input: Promote 'input-send-event' to stable API |
Date: |
Thu, 12 Nov 2015 10:09:03 +0100 |
On Do, 2015-11-12 at 09:23 +0100, Markus Armbruster wrote:
> Eric Blake <address@hidden> writes:
>
> > We've had 'x-input-send-event' since 2.3, with no further
> > changes to the interface other than tweaks in the previous patch
> > to the spelling of the enum constants ('X' and 'WheelUp' changed
> > to 'x' and 'wheel-up').
> >
> > What's more, changing the spelling of enum constants is not easy
> > to introspect prior to 2.5; so a client that was relying on the
> > experimental command can't easily tell which spelling is expected.
> > But 'query-commands' works in all qemu versions that supported
> > the command, so renaming the command now makes it an easy thing
> > to determine which spelling of the enum values to use.
> >
> > Thus, it's time to promote this interface to stable.
>
> The x- goes back to commit df5b2ad:
>
> input: move input-send-event into experimental namespace
>
> Ongoing discussions on how we are going to specify the console,
> so tag the command as experiental so we can refine things in
> the 2.3 development cycle.
>
> Have we settled "how we are going to specify the console"? If yes,
> commit, please. If no, I'm afraid the command should stay experimental.
Good question. I don't think so.
IIRC the question was whenever we'll leave it as-is (console=<index>),
or whenever we'll do something like display=<id>,head=<nr> instead.
The latter would be consistent with how we are doing input routing, i.e.
grouping display and input devices to a seat for multiseat setups (see
docs/multiseat.txt for more details).
The consoles are already present in the qom tree
as /backend/console[<index>] nodes, and they have device + head
children. So qom users can map console=<index> to
display=<id>,head=<nr> and visa versa already. So from a functionality
point of view it doesn't really matter, it is largely a matter of
taste ...
cheers,
Gerd