summary refs log tree commit diff stats
path: root/results/scraper/launchpad-without-comments/1776224
diff options
context:
space:
mode:
Diffstat (limited to 'results/scraper/launchpad-without-comments/1776224')
-rw-r--r--results/scraper/launchpad-without-comments/177622440
1 files changed, 40 insertions, 0 deletions
diff --git a/results/scraper/launchpad-without-comments/1776224 b/results/scraper/launchpad-without-comments/1776224
new file mode 100644
index 00000000..e50af73c
--- /dev/null
+++ b/results/scraper/launchpad-without-comments/1776224
@@ -0,0 +1,40 @@
+QEMU's SPICE server not getting leds callback when sending capslock
+
+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 ?
\ No newline at end of file