Bugzilla – Bug 478666
Turning on AccessX by key sequences (XkbAccessXKeysMask) should not be enabled by default
Last modified: 2017-08-12 19:14:46 UTC
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b3pre) Gecko/20081202 SeaMonkey/2.0a2 Using an X desktop, the keyboard sometimes stops working. This affects all keys. The mouse still works. At first I suspected hardware, but: the keys actually work if depressed and held (as for repeated characters); the problem disappears if a new instance of the X server starts by exiting from the login session; I have seen the problem on two different machines after installing 11.1 - a ThinkPad and a 64 bit Intel Core Quad CPU machine. I have not found anything useful in log files. Reproducible: Sometimes Steps to Reproduce: 1. In my hands simply continue to work for long enough - sometimes hours, sometimes only a few minutes. 2. 3. I can boot 11.0 on the same machines and not have the problem arise.
Please attach the information requested on webpage: http://en.opensuse.org/Bugs:X It sounds like it might be an application -- any out of the ordinary apps?
I have certainly considered this possibility, and was suspicious for a while that seamonkey might precipitate the fault, but it has happened when only using an xterm, and when the only other applications running were twm and oclock. I have on several occasions run xev in order to test whether keystrokes were seen in the xev window if the problem arose. xev reports exactly what I find functionally, that single keypresses are not detected, but a held down key gives sequences of keypress/keyrelease events after a short delay.
I am just a screener, the X maintainers need the information requested on the webpage: http://en.opensuse.org/Bugs:X
Created attachment 274970 [details] xorg.conf
Created attachment 274973 [details] output of hwinfo --gfx
Created attachment 274978 [details] log
I have observed the same behavior. At random times the computer emits a few beeps and the keyboard stops working. The desktop I had been using was KDE4. The system log did not report any error. I've had it happen with an USB plus a PS/2 keyboards plugged in, one moment they are working, beeps, none work afterwards. Login out and login in again restores the keyboard functionality.
I have made some additional interesting observations when the keypress fault shows up. First, the Ctrl key works, but again I have to depress it for a half second or so. In an xterm, if I press and hold the Ctrl key and press one of the mouse buttons, I see the popup menu. But if I press the Ctrl key and a mouse button simultaneously I get the normal mouse button action. Second, I have found I can kill the X server with Ctrl-Alt-BackSpace, but only if I press and hold the Ctrl key, then also press and hold the Alt key, and finally press and hold the BackSpace key. Third and possibly most important, if I sequentially press and hold Ctrl, Alt, F1 I can get a virtual terminal. In this virtual terminal the keyboard works perfectly. If I press Ctl-Alt-F7 and return to X, the kepress problem is still present. Together I think these observations, which are reproducible when the keypress fault arises, prove this is not a hardware problem.
I have seen this "sticky CTRL key" phenomenon once, but I don't remember where, and I can't / couldn't reproduce that here. Rafael, if this happens again can you verify that pressing Ctrl behaves the same way? Dave, if this happens again can you try to start xev (probably best to do a DISPLAY=:0 xev& on the console), and see what happens with key presses (e.g. the letter 'a'), with and without CTRL pressed? It just sounds like it behaves just the other way round as it should (pressed/released).
(In reply to comment #9) > Rafael, if this happens again can you verify that pressing Ctrl behaves the > same way? Hasn't happened since I switched back to kde3 a couple of days ago. I'll switch back now and wait.
Matthias, an "inverted" or "sticky" Ctrl key is not really consistent with my observations. When the problem arises, from a functional point of view the keys operate as normal, it is just that there is a significant latency between a key press and a KeyPress event arising. But I waited for the problem to occur again (nearly 24h - I was hopeful the latest batch of updates had fixed the problem) and ran xev. I will upload the output - some explanatory comments added and some repeated KeyPress/KeyRelease events when I held the 'A' key down for too long deleted. I'd like to try some debugging of the server, but find the rpm manual unhelpful in how to get from the src rpm to a set of patched sources that I could use to compile an unstripped binary for use with gdb. The keypress problem has just recurred - this time after only about 10min. Typing this is now painfully slow.
Created attachment 276212 [details] xev output when problem evident - testing Ctrl key xev output requested by Matthias and referred to in comment #11.
dup. *** This bug has been marked as a duplicate of bug 106886 ***
Now that we know what precipitates this problem, I have confirmed by booting openSuSE 11.0 and 10.3 that the same problem does not exist with those versions.
Guys, before definitely closing this as duplicate: Can you please a) verify how X was started (with with run-time options): ps axf | grep X b) verify whether you can turn this behavior off (when it's happening again) with - Pressing Shift for more than 8 seconds (if typing was painfully slow) - Pressing Shift 5 times in a row (if Ctrl is sticky) - Pressing two modifier keys (e.g. Shift + Ctrl) or three (Shift+Ctrl+Alt) (also if Ctrl is sticky) - Pressing Ctrl twice (also if Ctrl is sticky) Especially with the Ctrl key behavior I'm still unsure whether it's AccessX again...
Created attachment 276643 [details] Tool for verifying AccessX state Please compile this tool gcc -o accessx_state accessx_state.c -lX11 and run it with ./accessx_state to validate your accessibility state. If it turns out that XkbAccessXKeysMask is on for you, something in your Desktop environment must re-enable the AccessX keyboard switching enablement (which is off by default). If the sticky/slow reaction happens again, run it again and verify the state of XkbSlowKeysMask, XkbBounceKeysMask, and XkbStickyKeysMask.
X was started: /usr/bin/X :0 -br -verbose -auth /var/run/gdm/auth-for-gdm-Lm28WM/database -nolisten tcp vt7 In the "normal state", ./accessx_state output includes:
X was started: /usr/bin/X :0 -br -verbose -auth /var/run/gdm/auth-for-gdm-Lm28WM/database -nolisten tcp vt7 In the "normal state", ./accessx_state output includes: enabled_ctrls: 0x00001141: XkbAccessXKeysMask: Enable turning on AccessX by key sequences: on XkbAccessXTimeoutMask: Change to default values on timeout: off XkbAccessXFeedbackMask: Audible feedback (see ax_options): on XkbSlowKeysMask: Delay keypress acceptance: off XkbBounceKeysMask: Ignore keypress bounces after release: off XkbStickyKeysMask: Let modifiers stick to state: off If I hold down the Shift key for 8s and do not type anything else, the slow keys "feature" is on, and the output now includes: enabled_ctrls: 0x00001143: XkbAccessXKeysMask: Enable turning on AccessX by key sequences: on XkbAccessXTimeoutMask: Change to default values on timeout: off XkbAccessXFeedbackMask: Audible feedback (see ax_options): on XkbSlowKeysMask: Delay keypress acceptance: on XkbBounceKeysMask: Ignore keypress bounces after release: off XkbStickyKeysMask: Let modifiers stick to state: off This is reversed by holding the shift key down for eight seconds again. Note: there is no "audible feedback"; I see no evidence of the "sticky ctrl".
(In reply to comment #18) > XkbAccessXKeysMask: Enable turning on AccessX by key sequences: on That means that you can enable AccessX features by some special key presses. It should be off by default, therefor we have to find out why it had been switched on. The Xserver option +accessx has not been set, so it has been switched on during runtime. So that's either the login manager (do you use kdm or gdm?) or the desktop itself (which one?). > Note: there is no "audible feedback"; I see no evidence of the "sticky ctrl". Audible feedback depends on the ax_options flags. But might be misfunctional as well. The sticky ctrl comment was meant for the other reporter. This has to be assigned to the correct desktop team. So please state whether you use kdm or gdm, and on which Desktop this happens (check for XkbAccessXKeysMask).
For what is worth: /usr/bin/X -br -nolisten tcp :0 vt7 -auth /var/lib/xdm/authdir/authfiles/A:0-yEzlpY My display manager is kdm4 and the desktop is kde4. $ ./accessx_state XkbGetControls: ret 0: enabled_ctrls: 0x00001361: XkbAccessXKeysMask: Enable turning on AccessX by key sequences: on XkbAccessXTimeoutMask: Change to default values on timeout: off XkbAccessXFeedbackMask: Audible feedback (see ax_options): on XkbSlowKeysMask: Delay keypress acceptance: off XkbBounceKeysMask: Ignore keypress bounces after release: off XkbStickyKeysMask: Let modifiers stick to state: off After holding down shift for 8 secs: $ ./accessx_state XkbGetControls: ret 0: enabled_ctrls: 0x00001363: XkbAccessXKeysMask: Enable turning on AccessX by key sequences: on XkbAccessXTimeoutMask: Change to default values on timeout: off XkbAccessXFeedbackMask: Audible feedback (see ax_options): on XkbSlowKeysMask: Delay keypress acceptance: on XkbBounceKeysMask: Ignore keypress bounces after release: off XkbStickyKeysMask: Let modifiers stick to state: off There is an audible PC speaker beep after 4 secs of holding the shift key down, continuing holding the key for 4 more secs produces another beep and the slowkey feature is turned on. (In reply to comment #15) > b) verify whether you can turn this behavior off (when it's happening again) > with > - Pressing Shift for more than 8 seconds (if typing was painfully slow) yes > - Pressing Shift 5 times in a row (if Ctrl is sticky) yes, ctrl is sticky, i think, I get the xterm menu after releasing the ctrl key. I get a feedback beep after the 5 shifts and also after pressing the ctrl key, they have different freqs and it's not clear what they mean. $ ./accessx_state XkbGetControls: ret 0: enabled_ctrls: 0x00001379: XkbAccessXKeysMask: Enable turning on AccessX by key sequences: on XkbAccessXTimeoutMask: Change to default values on timeout: off XkbAccessXFeedbackMask: Audible feedback (see ax_options): on XkbSlowKeysMask: Delay keypress acceptance: off XkbBounceKeysMask: Ignore keypress bounces after release: off XkbStickyKeysMask: Let modifiers stick to state: on > - Pressing two modifier keys (e.g. Shift + Ctrl) or three (Shift+Ctrl+Alt) > (also if Ctrl is sticky) No. Shift+Ctrl+Alt is used by a vmware host to release the mouse under certain configurations. So there may be a possible conflict there. (I use that combo.) > - Pressing Ctrl twice (also if Ctrl is sticky) no
By the way, there is no feedback in ~/.xsession-errors or in /var/log/Xorg.0.log when this feature is toggled on and off.
The XkbAccessXKeysMask is "on" only when logging in through gdm. kdm or xdm logins leave the XkbAccessXKeysMask off. I use twm.
Perhaps this is relevant. After installation, gdm was my default display manager. At some point I monkeyed with the accessibility options in that login manager. The visible changes I got out of it were some computer message that sounded like "welcome to oracle" and a clipped phrase at login. I have since switched to kde4 as display manager. I noticed today at my home computer that I never changed the accessibility options and that XkbAccessXKeysMask is set to off. I will try the other display managers and kde3, 4 and gnome and see if this option gets changed.
With kdm4, XkbAccessXKeysMask is only on for KDE4. With GDM, XkbAccessXKeysMask is only on with KDE4. In GDM I unchecked the "read screen" feature, no other option was selected. In the accessibility options of KDE4, the all seem to be disabled except in "Activation Gestures", the option "Use gestures for activating sticky keys and slow keys" was turned on. By toggling it and applying, XkbAccessXKeysMask gets turned off. I do not remember if I set that option or if it was set by default. Other misc. information, I use KDE 4.2 out of the opensuse repository.
Reopen in order to assign to kde.
Apparently KDE4 explicitly sets XkbAccessXKeysMask. Too many users stumble over accidentally actviated AccessX features, so this shouldn't be enabled by default.
*** Bug 106886 has been marked as a duplicate of this bug. ***
I agree with Matthias' comment #26 that this should not be turned on by default, but not with the view that the problem should be assigned to kde (#25). I opened this bug but was not using kde. gdm seemed to be the "culprit", but I was not using a gnome desktop. So I think it is a general X problem, specifically: - nothing should enable it by default - activating/deactivating it should be logged - the audible signal on activating/deactivating should work - xset should show the ActiveX status (and allow it to be set?)
See comment #24, why we think it is a KDE4 issue.
(In reply to comment #28) > I agree with Matthias' comment #26 that this should not be turned on by > default, but not with the view that the problem should be assigned to kde > (#25). I opened this bug but was not using kde. gdm seemed to be the > "culprit", but I was not using a gnome desktop. So I think it is a general X > problem, specifically: X doesn't (read: shouldn't) set this up - the default has changed to off quite some time ago. In order to validate you can start X without any desktop: X & sleep 1; DISPLAY=:0 xterm& DISPLAY=:0 twm& and run ./accessx_state in the xterm there. Of course you could use any other (simple) window manager, but twm is known to not interfere anywhere. > - activating/deactivating it should be logged > - xset should show the ActiveX status (and allow it to be set?) Please open upstream bug reports for that on bugs.freedesktop.org > - the audible signal on activating/deactivating should work It works for some people (in this bug report as well). Maybe your PC speaker is not connected to the mainboard?
(In reply to comment #30) > (In reply to comment #28) > > I agree with Matthias' comment #26 that this should not be turned on by > > default, but not with the view that the problem should be assigned to kde > > (#25). I opened this bug but was not using kde. gdm seemed to be the > > "culprit", but I was not using a gnome desktop. So I think it is a general X > > problem, specifically: > > X doesn't (read: shouldn't) set this up - the default has changed to off quite > some time ago. > Agreed, but please note again, that from my perpective I "fixed" the problem by changing, in /etc/sysconfig/displaymanager DISPLAYMANAGER="gdm" to DISPLAYMANAGER="kdm" which does not say to me that the problem should be classified "KDE Workspace".
> Agreed, but please note again, that from my perpective I "fixed" the problem > by changing, in /etc/sysconfig/displaymanager > DISPLAYMANAGER="gdm" > to > DISPLAYMANAGER="kdm" > > which does not say to me that the problem should be classified "KDE Workspace". So let's reassign this bug to GNOME after having it fixed for KDE4.
This problem also happens under SLES11 (seen with KDE4). It is aggravated by 2 seperate problems: 1. At least on my system, "slow keys" under SLES11/KDE4 doesn't just slow down the keyboard, it completely disables it (xev shows no more kbd events after "slow keys" are enabled). Deselecting "slow keys" in the control center fixes this situation. 2. As mentioned elsewhere, there is no popup dialog asking the user if they intended to activate slow keys when the SHIFT key is being held. Rather, "slow keys" are activated silently.
I cannot confirm the problem on 11.1 with a newly created user. When holding Shift, after 4 seconds there is a beep, after 4 more seconds, a dialog appears and asks whether to activate slow keys. Please attach your ~/.kde4/share/config/kaccessrc , I assume you have disabled the dialog somehow. If you can reproduce the problem with a new user, please describe the exact steps to reproduce the problem.
I do not have a ~/.kde4/share/config/kaccessrc file, I guess because I am not using kde as my desktop. I use twm. I can reproduce the problem for any user by merely changing my displaymanager back to gdm from kdm.
(In reply to comment #33) I have to correct myself - slightly - after trying with a new user: > This problem also happens under SLES11 (seen with KDE4). > > It is aggravated by 2 seperate problems: > > 1. At least on my system, "slow keys" under SLES11/KDE4 doesn't just slow down > the keyboard, it completely disables it (xev shows no more kbd events after > "slow keys" are enabled). Deselecting "slow keys" in the control center fixes > this situation. This is only 95% true. _Some_ keys are active, AFAICS the SHIFT, CTRL, and ALT keys. Ordinary keys (letters, function keys) definitely aren't. The SHIFT, CTRL, and ALT react after ca. 1s, as expected with "slow keys". By holding SHIFT, I can deactivate slow keys again without using the accessibility control dialog. When I do that, all keys work normally again. > 2. As mentioned elsewhere, there is no popup dialog asking the user if they > intended to activate slow keys when the SHIFT key is being held. Rather, "slow > keys" are activated silently. This is also only partially true. There is indeed a "do you really want to enable slow keys dialog" - but only once per session. I can click "no", and the next time (and any following times) I hold shift the slow keys feature will be silently enabled. Martin
I cannot reproduce any problem in openSUSE11.2 either. If you have enabled the setting in any way, just disable it again as said in comment #24.
Let's try to get at least gdm fixed.
In short: Apparently, gdm sets XkbAccessXKeysMask - which is NOT unset by KDE4. So at least the combination of gdm + KDE4 lets XkbAccessXKeysMask active, which results in many users stumbling over sticky keys etc. If it is a feature that gdm enables XkbAccessXKeysMask, it has to disable it again before logging the user in, because the X.org default is to have it switched off.
Is this one still a issue? If I here no response i'll close it in a week
Ok for me to close.
There is no way to reproduce this today :) Lets close it as 11.1 is out of support. If anyone has still the same issue either report it to upstream gdm team or to TW.
See previous comment.