Re: [Qemu-devel] [PATCH] Add support for multiple simultaneously used keyboard devices.

[Filip Navara <filip.navara@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1910 bytes --]

On Mon, Nov 9, 2009 at 3:35 PM, Anthony Liguori <anthony@codemonkey.ws>wrote:

> Filip Navara wrote:
>
>> The support for multiple keyboard devices is essential for emulating
>> embedded boards where multiple input devices are present (eg. keypad and
>> rotary encoder) which are implemented using separate QEMU devices.
>>
>> Signed-off-by: Filip Navara <filip.navara@gmail.com>
>>
>>
>
> What boards would we actually expose multiple keyboards with?
>

The one that I was about to submit in the next weeks and which I sent
patches for few months ago (search for AT91). It is a custom board with
rotary encoder and matrix keyboard, quite a common configuration. The PXA
controllers even have special "GPIO" pins for these two input devices.

Moreover, we're not doing anything useful here.  We're just repeating a
> single keypress to multiple keyboards which seems rather hackish.
>

The embedded systems I target don't have keyboards in the traditional sense,
they have some input devices connected to the GPIO controller. These input
devices could be reduced keyboards (eg. like on the classic mobile phones),
various kinds of buttons, rotary encoders and so on. Since no direct mapping
exists for these input devices on PC, the easiest way to emulate the input
is with real keyboard.

What I am trying to accomplish is to allow these emulated devices each
handle a distinct subset of the PC keys. The matrix keyboard emulation would
capture the numbers and few other keys and ignore the rest. The rotary
encoder would capture arrows and ignore the rest.

Current QEMU emulations hack it by hard-coding all the real input devices
into one emulated device, which is specific for the board and not reusable.
My emulation is based on the QDEV model and the approach used in Paul Brooks
machine description patches.

Obviously I am open to suggestions on how to better handle this.

Best regards,
Filip Navara

[-- Attachment #2: Type: text/html, Size: 2665 bytes --]