[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] adb: change handler only when recognized

From: Hervé Poussineau
Subject: Re: [Qemu-devel] [PATCH] adb: change handler only when recognized
Date: Sat, 12 Mar 2016 21:31:01 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.6.0

Le 12/03/2016 19:13, Programmingkid a écrit :

On Mar 12, 2016, at 12:44 PM, Hervé Poussineau wrote:

Le 12/03/2016 16:24, Mark Cave-Ayland a écrit :
On 12/03/16 13:38, Hervé Poussineau wrote:

ADB devices must take new handler into account only when they recognize it.
This lets operating systems probe for valid/invalid handles, to know device 

Add a FIXME in keyboard handler, which should use a different translation
table depending of the selected handler.

Signed-off-by: Hervé Poussineau <address@hidden>

Interesting. Can you explain a bit more about which OSs this patch
affects and the symptoms it alleviates?

Here is a small list of handlers requested by some operating systems without 
the patch
HelenOS         kbd=1 mouse=2
MacOS 9         kbd=1 mouse=0xc (what is 0xc?)
Linux           kbd=3 mouse=4

Here is a small list of handlers requested by some operating systems with the 
HelenOS         kbd=1 mouse=2
MacOS 9         kbd=1 mouse=2
Linux           kbd=3 mouse=2

I have no example of current problem with the keyboard part. However, I suspect 
it may be related some
problems John is seeing on some operating systems, as handler 1 and 2/3 must 
not use the same
translation table.
Note that MacOS 9 uses handler 1 (Apple Standard Keyboard), while Linux uses 
handler 3 (Apple Extended Keyboard LShift != RShift).

On mouse part, operating systems (like MacOS or Linux) try to probe the mouse 
model by testing
different handlers, and see which ones are accepted.
On Linux, the handler 1 and 2 have a 3 bytes protocol, while the handler 4 has 
a 4 bytes protocol.
Correctly supporting protocol 4 will be required to handle 3-button mice.


Very interesting. Thank you for this information. So it sounds like the keys 
should change in the keyboard array with respect to the value of kbd. It would 
have to happen during runtime. Do you have any documentation related to your 
handler code? Particularly what keys are and not available for a particular 

Of course, I've no real documentation for Standard Keyboard vs Extended 

However, on a side note, while checking Linux code (for example 
I saw that keys Mute/VolumeUp/VolumeDown/EjectCD/BrightnessIncrease/BrightnessDecrease 
are not on the keyboard, but on another ADB device with category "misc".
Might be interesting if we want to add support for these keys one day in QEMU.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]