OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [PATCH qemu 5/6] virtio-input: control device

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 <kraxel@redhat.com>
> > > 
> > > 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).


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]