On 02/25/2010 10:51 AM, Gerd Hoffmann wrote:
On 02/25/10 16:07, Anthony Liguori wrote:
On 02/25/2010 08:36 AM, Gerd Hoffmann wrote:
I don't think so. Devil is in the details. Note that kbd_event and
mouse_event go to the kbd/mouse drivers, whereas led_event comes from
the kbd driver, so they ar
On 02/25/10 16:07, Anthony Liguori wrote:
On 02/25/2010 08:36 AM, Gerd Hoffmann wrote:
I don't think so. Devil is in the details. Note that kbd_event and
mouse_event go to the kbd/mouse drivers, whereas led_event comes from
the kbd driver, so they are different albeit related beasts.
Right, I
On 02/25/2010 08:36 AM, Gerd Hoffmann wrote:
On 02/25/10 15:15, Anthony Liguori wrote:
But I wonder if it really makes sense to treat all of these things
differently since we end up duplicating a lot of code. Would it make
more sense to just introduce:
typedef struct QEMUInputHandler {
void (
On 02/25/10 15:15, Anthony Liguori wrote:
But I wonder if it really makes sense to treat all of these things
differently since we end up duplicating a lot of code. Would it make
more sense to just introduce:
typedef struct QEMUInputHandler {
void (*put_kbd_event)(QEMUInputHandler *obj, int key
On 02/25/2010 02:39 AM, Gerd Hoffmann wrote:
Adds infrastructure for keyboard led status tracking to qemu.
Signed-off-by: Gerd Hoffmann
This is an obvious extension to the current API so I'm not necessarily
opposed to it.
But I wonder if it really makes sense to treat all of these thing
Adds infrastructure for keyboard led status tracking to qemu.
Signed-off-by: Gerd Hoffmann
---
console.h | 14 ++
input.c | 50 ++
2 files changed, 64 insertions(+), 0 deletions(-)
diff --git a/console.h b/console.h
index 916859d
