[vfio-users] [PATCH v2 1/3] input: add qemu_input_qcode_to_linux + qemu_input_linux_to_qcode

[Jonathan Scruggs]

Hi Gerd,

A couple of options I have been wondering about.

1)
Is it possible to have an option that would enable running a program on the
host on switching, IE when both CRTL keys are pressed. It would run on the
host regardless if it was on the guest machine when the keys pressed.
An option like 'onswitchexecute=/usr/bin/monitorswitch'

Something like that. I have a small program that switches the monitor input
via I2C direct (if interested: http://pastebin.com/6Hd0pafF). The program
would need to be modified a little bit to not use a variable input. but to
somehow detect what it's currently at and then switch to the opposite --
shouldn't be too hard.

2)
This would be useful for number idea one.
Instead of both CTRL keys, could the hotkey be something like
CTRL+SHIFT+ALT+1 for the host, and then each guest would set an option of 2
through 9. Since this is really only good for dedicated graphics cards, the
most I've heard of is 7 in one machine and that was a crazy build. A normal
person would have two cards, namely MS Windows Gaming Rig and GNU/Linux.
However, some may want three, which is very doable on most systems. So,
CTRL+SHIFT+ALT+2 or +3 to get to the other systems.

It can connect into point one, as the cheap and dirty monitor switcher code
takes an input and my monitor has three inputs, so a person could write
code to switch anything to anything. The option could have a variable
string that when called by your Input patches, would replace the variable
place holder with the machine being called, IE:
'execonswitch=/usr/bin/monitorswitch %COMPNUM'
Or something like that.

Hope you like the ideas.
Jon

On 18 January 2016 at 14:13, Gerd Hoffmann <kraxel at redhat.com> wrote:

> On Mo, 2016-01-18 at 11:47 +0000, Jonathan Scruggs wrote:
> > Hi Gerd,
> >
> > Would there be a way to add repeating keys back in that doesn't cause
> > issues? Maybe slow down the repeat cycle? Or is this strictly a issue
> > with how the actual event drivers or the buffers work and would need
> > changing to that on the host side?
>
> I don't know ...
>
> > In my mind it seams fairly straightforward in just forwarding these
> > events to the VM.
>
> I assumed that as well, it was there initially and only removed after it
> turned out to cause problems.
>
> I've added a patch to the git branch bringing it back, but guarded with
> a new config option (repeat={on,off}) and turned off by default.
>
> > Would it be different if the keyboard was using the PS/2 versus the
> > USB interface on the guest? I have a USB controller added for the
> > guest but the keyboard and mouse are on PS/2 interfaces.
>
> Worth testing.  Just add "-device usb-kbd" to the qemu command line and
> see what happens ...
>
> > A second thought. What if you made the keyboard and mouse USB only,
> > then on the guest, make sure the USB controller is using Message
> > Signal-Based interrupts. On Windows, the controller was set to the old
> > style Line-Based. The slow downs could be caused by a lake in speed
> > with he interrupts and USB polling speed.
>
> In case windows is new enough to have xhci support (win8+) you can try
> using a xhci hostadapter, which supports MSI (uhci and ehci don't), then
> hook up the usb keyboard to it.
>
> "-device nec-usb-xhci,id=xhci -device usb-kbd,bus=xhci.0"
>
> cheers,
>   Gerd
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/vfio-users/attachments/20160124/75f5e7c7/attachment.htm>