Bug 228150 - Behavior of Super_L inconsistent in X
Behavior of Super_L inconsistent in X
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-keyboard (Show other bugs)
6
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Kristian Høgsberg
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-02-10 11:49 EST by Brandon
Modified: 2008-01-15 09:40 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-01-15 09:40:38 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Log file generated when "Windows+Space" behaved correctly. (23.36 KB, text/plain)
2007-02-12 11:46 EST, Brandon
no flags Details
One of several offending configuration files. (1.31 KB, text/plain)
2007-02-12 11:46 EST, Brandon
no flags Details

  None (edit)
Description Brandon 2007-02-10 11:49:55 EST
Description of problem:
I have an application that I've configured to use the "windows key" for certain 
functions.  When I upgraded to FC6, this application would sometimes fail to 
understand the key sequences I use that use that key.  I have found that 
whether or not my key sequences will work correlate to whether typing 
Windows+Space outputs a space on the username field of the login screen; the 
correct behavior is some sort of control sequence that is not interpreted as a 
space, the incorrect behavior is the space on the username field.

Roughly half the time, when X and gdm start up, it will behave incorrectly.  I 
have to restart the X server repeatedly until it behaves the way I want it to.

On my home system, xmodmap consistently shows the following output, whether the 
behavior is correct or not:
shift       Shift_L (0x32),  Shift_R (0x3e)
lock      
control     Control_L (0x25),  Control_L (0x42),  Control_R (0x6d)
mod1        Alt_L (0x40),  Alt_L (0x7d),  Meta_L (0x9c)
mod2        Num_Lock (0x4d)
mod3      
mod4        Super_L (0x7f),  Hyper_L (0x80)
mod5        Mode_switch (0x5d),  ISO_Level3_Shift (0x7c)


Version-Release number of selected component (if applicable):


How reproducible:
Very.  I've seen this on brand-new FC6 installs from media, and on up to date 
systems.  I've seen this on a variety of desktops and laptops, all i386.


Steps to Reproduce:
1. Start an FC6 system into runlevel 5.
2. Hold down the "windows key" and press space with input focus in the username 
field.
3. ctrl-alt-backspace and try again until you see both sets of behavior.
  

Additional info:
Comment 1 Matěj Cepl 2007-02-12 05:23:36 EST
Thanks for the bug report.  We have reviewed the information you have provided
above, and there is some additional information we require that will be helpful
in our diagnosis of this issue.

Please attach your X server config file (/etc/X11/xorg.conf) and X server log
file (/var/log/Xorg.*.log) to the bug report as individual uncompressed file
attachments using the bugzilla file attachment link below.

Could you please also try to run without any /etc/X11/xorg.conf whatsoever and
let X11 autodetect your display and video card? Attach to this bug
/var/log/Xorg.0.log from this attempt as well, please.

We will review this issue again once you've had a chance to attach this information.

Thanks in advance.
Comment 2 Brandon 2007-02-12 11:46:12 EST
Created attachment 147909 [details]
Log file generated when "Windows+Space" behaved correctly.

The log file generated when "Windows+Space" produces a space is identical
except for the timestamp.  The diff of the two log files is

15c15
< (==) Log file: "/var/log/Xorg.0.log", Time: Mon Feb 12 09:26:35 2007
---
> (==) Log file: "/var/log/Xorg.0.log", Time: Fri Feb  9 17:04:05 2007
Comment 3 Brandon 2007-02-12 11:46:55 EST
Created attachment 147910 [details]
One of several offending configuration files.
Comment 4 Brandon 2007-02-12 11:48:05 EST
I found some more information about the problem at
http://modeemi.cs.tut.fi/~tuomov/ion/faq/broken_software.html  As described at
that site, I added the lines

remove mod4 = Super_L
keycode 127 = 
add mod4 = Super_L

to /etc/X11/Xmodmap and that seems to have fixed my issue.

The Xorg.0.log files generated by a successful run and an unsuccessful run only
differed in the timestamp, so I am only attaching one of those files.  My first
attempt at letting Xorg generate the xorg.conf file failed (X wouldn't start),
so I'll find another system to try that on if you still need that test.
Comment 5 Matěj Cepl 2007-12-10 04:25:14 EST
Fedora Core 6 is no longer supported, could you please reproduce this with the
updated version of the currently supported distribution (Fedora 7, 8, 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.

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

[This is mass-filed message to all open Fedora Core 6 bugs related to Xorg or
Gecko. If you see any other reason, why this bug shouldn't be closed, please,
comment on it here.]
Comment 6 Matěj Cepl 2008-01-15 09:40:38 EST
Since there are insufficient details provided in this report for us to
investigate the issue further, and we have not received feedback to the
information we have requested above, we will assume the problem was not
reproducible, or has been fixed in one of the updates we have released for the
reporter's distribution.

Users who have experienced this problem are encouraged to upgrade to the latest
update of their distribution, and if this issue turns out to still be
reproducible in the latest update, please reopen this bug with additional
information.

Closing as INSUFFICIENT_DATA.

{This is mass-closing of all obsolete bugs; if this bug was in your opinion
closed by mistake, please, reopen it with additional information; thanks a lot
and I am sorry for bothering you in such case.}

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