Public bug reported:
I'm having troubles using the QEMU's SPICE server for remote views. When
trying to sync leds from my SPICE client to QEMU, I can see that the
caps lock keycodes are sent but the server state never gets updated
(which leads in funny behaviours like caps lock "blinking" in the guest
if the clients resyncs its state often).
That behaviour doesn't happen at all with the numlock led which does the
same thing but with different keycodes.
Here is an example of what's happening when the client tries to resync
with a capslock difference:
> Spice received: 58
> ps2_put_keycode: 88
>
> Spice received: 186
> ps2_put_keycode: 240
> ps2_put_keycode: 88
> ps2_queue: 186
And with numlock:
> Spice received: 69
> ps2_put_keycode: 119
>
> Spice received: 197
> ps2_put_keycode: 240
> ps2_put_keycode: 119
> ps2_queue: 197
> ps2_set_ledstate: 0
> Spice new ledstate: 0
This behaviour is consistent across SPICE clients and only appears in a linux
TTY (it works fine if I start an X server and on windows). It still happens on
QEMU latest commit at the time (0d2fa03dae4fbe185a082f361342b1e30aed4582)
Spice registers a callback for leds via qemu_add_led_event_handler but
it's never called for capslock. Is that a normal behaviour ? Is there
any reasons for the capslock led not to be updated ?
** Affects: qemu
Importance: Undecided
Status: New
** Attachment added: "Trace of a capslock press on both linux and windows"
https://bugs.launchpad.net/bugs/1776224/+attachment/5151280/+files/trace_kbd
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1776224
Title:
QEMU's SPICE server not getting leds callback when sending capslock
Status in QEMU:
New
Bug description:
I'm having troubles using the QEMU's SPICE server for remote views. When
trying to sync leds from my SPICE client to QEMU, I can see that the
caps lock keycodes are sent but the server state never gets updated
(which leads in funny behaviours like caps lock "blinking" in the guest
if the clients resyncs its state often).
That behaviour doesn't happen at all with the numlock led which does the
same thing but with different keycodes.
Here is an example of what's happening when the client tries to resync
with a capslock difference:
> Spice received: 58
> ps2_put_keycode: 88
>
> Spice received: 186
> ps2_put_keycode: 240
> ps2_put_keycode: 88
> ps2_queue: 186
And with numlock:
> Spice received: 69
> ps2_put_keycode: 119
>
> Spice received: 197
> ps2_put_keycode: 240
> ps2_put_keycode: 119
> ps2_queue: 197
> ps2_set_ledstate: 0
> Spice new ledstate: 0
This behaviour is consistent across SPICE clients and only appears in a linux
TTY (it works fine if I start an X server and on windows). It still happens on
QEMU latest commit at the time (0d2fa03dae4fbe185a082f361342b1e30aed4582)
Spice registers a callback for leds via qemu_add_led_event_handler but
it's never called for capslock. Is that a normal behaviour ? Is there
any reasons for the capslock led not to be updated ?
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1776224/+subscriptions
