GNOME Bugzilla – Bug 698746
Accessibility : "slow keys" breaks "screen keyboard" feature
Last modified: 2014-01-03 15:46:38 UTC
If you set both on none will be usable at all Only the pointer to disable one of them Tested on fedora base (gnome-3.8.0) ... May investigate later, If none cares
If slow keys and screen keyboard are set to on in universal acces, the screen keyboard is unusable but the slow keys are still working
(In reply to comment #1) > If slow keys and screen keyboard are set to on in universal acces, the screen > keyboard is unusable but the slow keys are still working (Fedora beta 19 http://fedoraproject.org/fr/download-splash?file=http://download.fedoraproject.org/pub/fedora/linux/releases/test/19-Beta/Live/x86_64/Fedora-Live-Desktop-x86_64-19-Beta-1.iso)
Bug still present in gnome 3.10 (tested in Fedora 20).
Created attachment 257915 [details] [review] caribou-slowkeys.patch Hello, Please consider attached patch, which solves the problem by deactivating X slow keys features, each time the virtual keyboard sends a keystroke.
Precision : patch was made with caribou-0.4.11 (ftp://ftp.gnome.org/pub/GNOME/sources/caribou/0.4/caribou-0.4.11.tar.xz) used by gnome-shell 3.8.
Just tested, patch works with git master, too.
Patch works fine for me (tested on Fedora 20).
Review of attachment 257915 [details] [review]: Thanks, patch looks fine. ::: libcaribou/xadapter.vala @@ +95,3 @@ + if (this.a11y_settings.get_boolean ("slowkeys-enable") == true) { + if (enable == false) + this.xkbdesc.ctrls.enabled_ctrls = this.xkbdesc.ctrls.enabled_ctrls & ~Xkb.SlowKeysMask; this.xkbdesc.ctrls.enabled_ctrls &= ~Xkb.SlowKeysMask; for simplicity @@ +277,3 @@ mod_latch (mask); + trigger_slowkeys (false); "trigger" looks a bit misleading here. It sounds like the function proactively enable the slow keys, even though the argument is false. Maybe: disable_slowkeys (); XTest.fake_key_event (...); enable_slowkeys (); might make the logic a bit clearer? @@ +103,3 @@ public class Controls { + public uint enabled_ctrls; + public uint axt_ctrls_mask; Other fields than enable_ctrls can be omitted.
Perhaps we don't even need to check the a11y settings here. If we had a function, say, set_slow_keys_enabled, which returns the previous value of (enable_ctrls & SlowKeysMask) == 0, we could write: var slow_keys_enabled = set_slow_keys_enabled (false); XTest.fake_key_event (...); set_slow_keys_enabled (slow_keys_enabled);
(In reply to comment #8) Hello Daiki and thanks for your review, > "trigger" looks a bit misleading here. It sounds like the function proactively > enable the slow keys, even though the argument is false. Maybe: > > disable_slowkeys (); > XTest.fake_key_event (...); > enable_slowkeys (); > > might make the logic a bit clearer? > Yes, having 2 functions sounds fine. > Other fields than enable_ctrls can be omitted. My bad, these are leftovers from my initial tests. They could eventually become useful in the future, though. (In reply to comment #9) > Perhaps we don't even need to check the a11y settings here. If we had a > function, say, set_slow_keys_enabled, which returns the previous value of > (enable_ctrls & SlowKeysMask) == 0, we could write: > > var slow_keys_enabled = set_slow_keys_enabled (false); > XTest.fake_key_event (...); > set_slow_keys_enabled (slow_keys_enabled); Smart, should be faster, looks good to me !
Created attachment 258653 [details] [review] Makes "screen keyboard" works with "slow keys" feature enabled. Manuel's patch with Daiki Ueno modifications.
(In reply to comment #11) > Manuel's patch with Daiki Ueno modifications. Thanks. However, in that case, set_slow_keys_enabled needs to call Xkb.get_controls to retrieve the latest controls from the server. I'll attach a slightly modified version.
Created attachment 258712 [details] [review] xadapter: disable slowkeys when sending key event
Works for me.
Attachment 258712 [details] pushed as 6c75e02 - xadapter: disable slowkeys when sending key event
That's very nice ! Do you think it would be possible to push it to 4.11, eventually ?
Sure, will make a release for 3.11.2 unstable.
I confirm caribou 0.4.13 is working fine on gnome-3-8 base BTW it would make sense to have a gnome-3-8 branch on this project too... Thank you all