[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH qemu 5/6] virtio-input: control device
From: |
Michael S. Tsirkin |
Subject: |
Re: [Qemu-devel] [PATCH qemu 5/6] virtio-input: control device |
Date: |
Sun, 13 Apr 2014 20:14:53 +0300 |
On Fri, Apr 11, 2014 at 10:25:59AM +0200, Gerd Hoffmann wrote:
> On Do, 2014-04-10 at 18:20 +0300, Michael S. Tsirkin wrote:
> > On Thu, Apr 10, 2014 at 02:10:20PM +0200, Gerd Hoffmann wrote:
> > > On Do, 2014-04-10 at 14:05 +0300, Michael S. Tsirkin wrote:
> > > > On Thu, Apr 10, 2014 at 11:07:53AM +0200, Gerd Hoffmann wrote:
> > > > > Device for sending non-input control messages to the guest. For now
> > > > > this is only a single event: shutdown requests are sent as power
> > > > > button
> > > > > press to the guest.
> > > > >
> > > > > Possible other use is signaling sound volume changes to the guest (via
> > > > > EV_ABS / ABS_VOLUME). I expect we'll find more over time.
> > > > >
> > > > > Signed-off-by: Gerd Hoffmann <address@hidden>
> > > >
> > > > Why not use a keyboard device for this?
> > >
> > > >From the guests point of view this is looks like a keyboard. A keyboard
> > > with a single key: power.
> > >
> > > I prefer a clear separation between devices being feed from user input
> > > and the control device which monitors other event sources (powerdown
> > > notifier).
> > >
> > > There is no fundamental reason why this can't live in the emulated
> > > keyboard though.
> > >
> > > cheers,
> > > Gerd
> > >
> >
> > Well I have a keyboard with volume keys - sleep and wakeup buttons too.
> > Not power but that's not out of the realm of possibility.
> > If we want to be able to pass that through, it should work as a
> > virtio keyboard right?
>
> Sure. That is another story though. QKeyCode needs to learn those
> keys, they need to be added to the mappings, and then they'll be handled
> like any other key.
>
>
> What I was thinking about is sending feedback about volume changes to
> the guest is something completely different, let me explain in detail:
>
> What we have in spice today is that the guests volume change request is
> passed to the spice client, which in turn forwards it to pulseaudio,
> which then actually applies the volume setting to the audio stream. And
> you can see the guests volume changes in the hosts mixer UI (sound
> settings -> applications): change the volume in the guest and watch the
> slider move.
>
> Today this is a one-way ticket. If you fiddle with the volume in the
> hosts mixer ui the guest doesn't notice. A emulated volume wheel would
> be a possible way to feedback volume changes on the host to the guest.
> Note that it isn't that simple to implement as it need a spice protocol
> extension too (and support in spice server + client of course).
>
> cheers,
> Gerd
Or forward volume keys to guest through the virtio keyboard - then we
don't need to emulate a volume wheel.
[Qemu-devel] [PATCH qemu 6/6] virtio-input: evdev passthrough, Gerd Hoffmann, 2014/04/10
[Qemu-devel] [PATCH qemu 4/6] virtio-input: emulated devices, Gerd Hoffmann, 2014/04/10