Bug 189518 - keyboard state modifiers erroneously depend on keypress order
keyboard state modifiers erroneously depend on keypress order
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: xorg-x11-server (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Peter Hutterer
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-04-20 13:57 EDT by James Ralston
Modified: 2009-02-26 14:05 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-10-23 06:32:53 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
my X server log file (42.12 KB, text/plain)
2006-04-20 13:59 EDT, James Ralston
no flags Details
my X server config file (3.32 KB, text/plain)
2006-04-20 14:01 EDT, James Ralston
no flags Details
xev output from pressing Alt-Shift-@ (8.00 KB, text/plain)
2006-04-20 14:05 EDT, James Ralston
no flags Details
xev output from pressing Shift-Alt-@ (8.00 KB, text/plain)
2006-04-20 14:07 EDT, James Ralston
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
FreeDesktop.org 2871 None None None Never
FreeDesktop.org 7439 None None None Never

  None (edit)
Description James Ralston 2006-04-20 13:57:59 EDT
I frequently need to enter key combinations that require pressing and holding
both the Shift and Alt (Meta) keys.  An example would be the Emacs mark-word
command (bound to M-@ by default): to enter it, I would press and hold Shift,
press and hold Alt, and then press the @/2 key on the keyboard.

In xorg-x11-drv-keyboard-1.0.1.3-1.2, the state modifiers depend on the order in
which the keys are pressed.

Specifically, if I press Alt-Shift-@, the state modifier returned on the
keypress event is 0x9 (0x1 = Shift, 0x8 = Alt) according to xev:

KeyPress event, serial 28, synthetic NO, window 0x3e00001,
    root 0x4c, subw 0x0, time 3094865719, (86,91), root:(90,110),
    state 0x9, keycode 11 (keysym 0x40, at), same_screen YES,
    XLookupString gives 1 bytes: (40) "@"
    XmbLookupString gives 1 bytes: (40) "@"
    XFilterEvent returns: False

This is correct.

However, if I press Shift-Alt-@ (that is, I press the Shift key before the Alt
key), according to xev, the state modifier returned on the keypress event is 0x1:

KeyPress event, serial 28, synthetic NO, window 0x3e00001,
    root 0x4c, subw 0x0, time 3094891814, (90,70), root:(94,89),
    state 0x1, keycode 11 (keysym 0x40, at), same_screen YES,
    XLookupString gives 1 bytes: (40) "@"
    XmbLookupString gives 1 bytes: (40) "@"
    XFilterEvent returns: False

This is *not* correct; the Alt state modifier has been lost.

This is a very big deal to me, because the way I tend to type, I almost always
hit the Shift key before the Alt key.

Furthermore, this doesn't happen 100% of the time.  Occasionally the X server
will work correctly; that is, the modifier keys don't depend on the order in
which they are pressed.  However, I've been unable to figure out what (if
anything) I did to get it to work correctly.
Comment 1 James Ralston 2006-04-20 13:59:55 EDT
Created attachment 128047 [details]
my X server log file
Comment 2 James Ralston 2006-04-20 14:01:39 EDT
Created attachment 128048 [details]
my X server config file
Comment 3 James Ralston 2006-04-20 14:05:56 EDT
Created attachment 128049 [details]
xev output from pressing Alt-Shift-@

This is the output that xev generates when I move the pointer into its window
and then press Alt-Shift-@.
Comment 4 James Ralston 2006-04-20 14:07:15 EDT
Created attachment 128051 [details]
xev output from pressing Shift-Alt-@

This is the output that xev generates when I move the pointer into its window
and then press Shift-Alt-@.
Comment 5 Pavel Lisy 2006-05-03 04:01:09 EDT
I am working on notebook ThinkPad X40 and I can confirm this behaviour on it. It
happens sometimes. But I didn't uncover when it is changing.
Comment 6 James Ralston 2006-05-03 15:21:12 EDT
I've still been unable to figure out what is causing the behavior.  Sometimes it
works; sometimes it doesn't.

I'm not sure if I've seen the problem since I upgraded to
xorg-x11-server-Xorg-1.0.1-9.fc5.1.1.  I'll wait to see if I encounter the
broken behavior again.  (It would be nice if 1.0.1-9.fc5.1.1 magically fixed
this problem, but I doubt it.)
Comment 7 Mike A. Harris 2006-05-23 09:09:31 EDT
Please report this issue to X.Org developers by filing a bug report in
the X.Org bugzilla located at http://bugs.freedesktop.org in the "xorg"
component.

Once you've filed your bug report to X.Org, if you paste the new
bug URL here, Red Hat will continue to track the issue in the
centralized X.Org bug tracker, and will review any bug fixes that
become available for consideration in future updates.

Setting status to "NEEDINFO_REPORTER", awaiting X.Org bug URL
for tracking.
Comment 8 James Ralston 2006-07-06 11:37:26 EDT
Upstream bug ref added.
Comment 9 Tethys 2006-11-03 16:12:32 EST
Just so you're aware, James isn't alone with this. I've just had exactlythe
same problem (for me, it's hotkey combinations in my window manager, rather
than emacs). I've verified what's happening with xev in a plain X server with
no wm and only a single xterm running, so it's not some strange wm interaction.

There doesn't seem to be anything much happening with the upstream bug, which
is a shame. If this isn't sorted soon, I'm going to have to revert to FC4
(which I was using just before an upgrade to FC6 yesterday). I'd rather use
an unsupported OS than be without my hotkeys. It's a *major* blow to my
productivity :-(

Like James, it's not 100% reproducable for me. It seems to be per invocation
of the X server. If it starts up with the modifier order being important, then
it'll stay that way until the X server is restarted. Likewise, if it starts up
working fine, then it'll stay that way.

FWIW, I'm using FC6 on i386:

xorg-x11-server-Xorg-1.1.1-47.fc6
xorg-x11-drv-keyboard-1.1.0-2.1
Comment 12 Matěj Cepl 2007-07-03 09:52:46 EDT
Fedora Core 5 is no longer supported, please, could you reproduce this bug with
the updated version of the currently supported distribution (Fedora Core 6, or
Fedora 7, or Rawhide)? If this issue turns out to still be reproducible, please
let us know in this bug report.  If after a month's time we have not heard back
from you, we will have to close this bug as CANTFIX/INSUFFICIENT_DATA.

Setting status to NEEDINFO, and awaiting information from the reporter.

Thanks in advance.
Comment 13 James Ralston 2007-07-03 17:06:09 EDT
This bug still exists in Fedora 7.
Comment 14 James Ralston 2007-07-03 17:08:15 EDT
Ok, Bugzilla is ignoring my assertion that "I am providing the requested
information for this bug."  (But I am.)
Comment 15 Bug Zapper 2008-05-14 08:01:03 EDT
This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '7'.

Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 7's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 7 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug. If you are unable to change the version, please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists.

Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs:
http://docs.fedoraproject.org/release-notes/

The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 16 James Ralston 2008-05-14 11:04:08 EDT
This bug still exists in F8.  Moreover, as of a few days, this bug still exists
in Rawhide, and assumably exists in F9 (although I haven't had a chance to
install F9 yet.)
Comment 17 Peter Hutterer 2008-08-06 02:51:49 EDT
I can't reproduce this with the rawhide x server. Can you please verify if this is still an issue with F9/Rawhide?
Also - how often does it actually happen. Once in a while, or quite regularly?
Comment 18 James Ralston 2008-09-09 11:31:22 EDT
It depends.  With my old laptop (a Dell Latitude D600), I could reproduce it fairly easy... probably about 50% of the time.  With my current laptop (a Dell Latitude D620), I don't think I've *ever* been able to reproduce it.

On both my old and current office PCs, I don't think I was ever able to reproduce it.

On my home PC (running F9), I can reproduce it, but it happens extremely infrequently... maybe only once out of every 50 X server invocations.

The problem is more likely to occur when I start X immediately after a [re]boot.  If the problem occurs, if I shut down and then restart X, the problem is extremely likely to occur again.  If, however, before restarting X, I do something that will "stir" memory (e.g., let a "find /" command run for 30 seconds or so), then the problem is extremely unlikely to reoccur.

Again, given that toggling an option can fix the problem in a running server (see the upstream freedesktop bug), this problem is almost certainly the result of bug in memory allocation (probably, the use of uninitialized values) within the X server.

I suspect that without some sort of memory testing toolsuite (e.g., Valgrind), the bug is going to be very difficult to find.  :(
Comment 19 Peter Hutterer 2008-09-23 21:45:15 EDT
(In reply to comment #18)
> On my home PC (running F9), I can reproduce it, but it happens extremely
> infrequently... maybe only once out of every 50 X server invocations.

next time it happens, please run xkbcomp -xkb :0 out.xkb and attach out.xkb to this bugreport. Also, run the same command when everything works properly and check if diff shows a difference between the two.


The upstream bug has been marked as a duplicate of FDO Bug 2871, adding reference.
Comment 20 Matěj Cepl 2008-10-20 15:44:33 EDT
Reporter, any development on this issue? If you won't reply in one month, I will probably have to close this bug as INSUFFICIENT_DATA, because it doesn't seem to lead anywhere. Thank you.
Comment 21 James Ralston 2008-10-22 20:04:47 EDT
I'm still waiting for the "next time it happens" part.  As I said, it occurs very rarely now.  :p

If you want, go ahead and close this bug.  If/when I manage to reproduce it, I'll reopen the bug and attach the info you requested.
Comment 22 Matěj Cepl 2008-10-23 06:32:53 EDT
OK, just keep our bugzilla at least a little bit, I will close this, and certainly you are very welcome to reopen with the additional information when you see it again.
Comment 23 Steve Fink 2009-02-26 14:05:40 EST
I am seeing this also, on Fedora 10. You can see my xkbcomp output in the upstream bug 2871.

Note You need to log in before you can comment on or make changes to this bug.