Bug 183997 - xorg-x11-xkbdata - annoying ScrollLock LED behaviour
xorg-x11-xkbdata - annoying ScrollLock LED behaviour
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: xorg-x11-xkbdata (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: X/OpenGL Maintenance List
:
Depends On:
Blocks: FC6Target FC5Update
  Show dependency treegraph
 
Reported: 2006-03-04 15:21 EST by Michal Jaegermann
Modified: 2007-11-30 17:11 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-06-27 13:46:28 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)
information.png (25.33 KB, image/png)
2006-03-06 17:38 EST, Warren Togami
no flags Details
requested gconftool-2 -R /desktop/gnome/peripherals/keyboard output (1.77 KB, text/plain)
2006-03-06 22:17 EST, John Thacker
no flags Details
another 'gconftool-2 -R /desktop/gnome/peripherals/keyboard' output (942 bytes, text/plain)
2006-03-07 03:10 EST, Michal Jaegermann
no flags Details
my gconf2 keyboard (676 bytes, text/plain)
2006-03-07 07:03 EST, Vitor Domingos
no flags Details


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

  None (edit)
Description Michal Jaegermann 2006-03-04 15:21:21 EST
Description of problem:

With the current set of xkbdata logging in into a Gnome session (at least)
lights up ScrollLock LED.  It turns out that NumLock key switches between
NumLock and ScrollLock LEDs.  Going back to a text console will extinguish
ScrollLock LED  and returning to a graphic screen will not make it to
light up - but only until NumLock was tapped twice.  Then we are back to
the previous state.  What happens with ScrollLock key does not have any
bearing on that LED.

All of the above holds unless "ScrollLock LED shows alternative group" box
is checked out in "Layout Options".  Then this LED will stay dark regardless
of a status of keys picked up from "Group Shift/Lock behaviour" set.

Version-Release number of selected component (if applicable):
xorg-x11-xkbdata-1.0.1-6
Comment 1 Mike A. Harris 2006-03-05 19:29:58 EST
Please report this issue to the xkeyboard-config maintainers by filing
a bug report in the X.Org bugzilla located at http://bugs.freedesktop.org
in the "xkbdesc" component.

Once you've filed your bug report upstream, if you paste the new
bug URL here, Red Hat will continue to track the issue in the
centralized upstream 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 2 Mike A. Harris 2006-03-06 16:45:43 EST
Thanks, tracking upstream at: https://bugs.freedesktop.org/show_bug.cgi?id=6162
Comment 3 Warren Togami 2006-03-06 17:38:38 EST
Created attachment 125730 [details]
information.png

This behavior happens to me when I start my desktop from a FC4 GNOME profile,
but only after the GNOME session has run this dialog.  This is true of Failsafe
GNOME as well, but not KDE.  During GNOME startup I can repeatedly hit
Caps-Lock and it has no effect on Num-Lock, but Num-Lock happens as soon as
this dialog pops up.
Comment 4 Warren Togami 2006-03-06 17:42:07 EST
Given the above, this might be a GNOME specific issue.

Impact:
Far worse for laptop users, becuase there is no obvious way of turning off
Num-Lock and they are unable to type properly.
Comment 5 Warren Togami 2006-03-06 17:45:50 EST
/desktop/gnome/peripherals/keyboard/general/disable_sysconfig_changed_warning
setting this gconf key only hides the dialog during GNOME startup, but the
problem does not go away.
Comment 6 Warren Togami 2006-03-06 21:29:08 EST
Tested with a supplemental USB keyboard plugged into my laptop.  Caps-Lock has
the same bad behavior as above.  The extended keyboard Num-Lock key however is
successful in disabling Num-Lock.
Comment 7 Warren Togami 2006-03-06 21:40:17 EST
GNOME > Preferences > Keyboard > Layout Options > Use keyboard LED to show
alternative groups > NumLock LED shows alternative group

If I enable this option, then it seems to fix this bad behavior.  Even if I turn
it off again, it remains fixed.  How do I undo this change to my profile in
order to reproduce the original problem?

I suspect that some of these options are "undefined" in existing GNOME user
profiles, and somewhere around February 24th the system changed and broke these
cases.

fedora-devel-list has a complaint that the "compose" key suddenly changed,
perhaps this a similar problem.  We really should look into all possible impact
scenarios of this issue or we will have unhappy FC4 upgrade users and many
strange and difficult to understand bug reports against wrong components when
FC5 is released.
Comment 8 Warren Togami 2006-03-06 22:06:10 EST
IMPORTANT:
If you can reproduce this problem, please follow this procedure before you try
the workaround described above.

gconftool-2 -R /desktop/gnome/peripherals/keyboard > keyboard-backup.txt

Then please attach that file to this report.  We need data in order to reproduce
this and other potential similar problems.
Comment 9 John Thacker 2006-03-06 22:17:30 EST
Created attachment 125744 [details]
requested gconftool-2 -R /desktop/gnome/peripherals/keyboard output

Note that it contains various cruft from upgrading multiple times before.  I'm
seeing the Scroll Lock issue after the upgrade.  I've changed features since
the upgrade, but haven't done the fix suggested in the comment for the Scroll
Lock issue.
Comment 10 John Thacker 2006-03-06 22:21:25 EST
After doing that, I tried the work around.  Changing "NumLock LED shows
alternative group" had no effect (other than making the NumLock LED not light
up).  Changing "ScrollLock LED shows alternative group" made the ScrollLock LED
turn off (since I wasn't in an alternative group), but it came back on as soon
as the option was turned off.  The original "ScrollLock LED is the reverse of
the NumLock LED" returned.
Comment 11 Warren Togami 2006-03-06 22:29:48 EST
Try turning it on and off.  Is the behavior the same as before you toggled it?
Comment 12 John Thacker 2006-03-07 00:11:46 EST
Yes, behavior is exactly the same as before I toggled the option.  (Assume you
mean the ScrollLock option, rather than, as you wrote, the NumLock option.)

Slight difference in my issue than what seems to be described-- Either the
NumLock OR CapsLock turning on will make the ScrollLock LED go off.
Comment 13 Thorsten Leemhuis (ignored mailbox) 2006-03-07 02:15:07 EST
(In reply to comment #12)
> Yes, behavior is exactly the same as before I toggled the option.  (Assume you
> mean the ScrollLock option, rather than, as you wrote, the NumLock option.)

It seems to me that the problem Warren describes is somewaht different to that
from John.

I'm seeing exactly the same symptoms as John.

> Slight difference in my issue than what seems to be described-- Either the
> NumLock OR CapsLock turning on will make the ScrollLock LED go off.

This, too. Microsoft Natural Keyboard connected via USB. Happens on a fresh
account, too. Toggling the GNOME options as described in #7 doesn't help.
Comment 14 Michal Jaegermann 2006-03-07 03:10:32 EST
Created attachment 125746 [details]
another 'gconftool-2 -R /desktop/gnome/peripherals/keyboard' output

AFAICS what I am seeing, and what I reported originally, is something
like described by John and not by Warren.  Changing ""ScrollLock LED
shows alternative group" toggles that off and on.  But this is on
a desktop machine and not on a laptot (and x86_64 if that has any
relevance here).

What brought into gconftool-2 output this "ar	   azerty" stuff I really
do not know.  It was not something I added there and I was never using
such layout.  It does not show at this moment in "Layouts" tab of "Keyboard
Preferences" window.  It did at some moment in the past but I asked for
a removal.
Comment 15 Vitor Domingos 2006-03-07 07:03:13 EST
Created attachment 125749 [details]
my gconf2 keyboard
Comment 16 Michal Jaegermann 2006-03-07 17:14:47 EST
Whatever changed in xorg-x11-xkbdata-1.0.1-7 I do not see ScrollLock LED
to light up; as a matter of fact in any circumstances and does not matter
which keys are pushed and that includes ScrollLock itself.  At the first
glance other recent updates should be immaterial.

I am not sure how this affects laptop keyboards.  I do not have such test
installation.

So whos problems is that really and what should be closed?  Is this truly
a freedesktop.org baby?
Comment 17 Bill Crawford 2006-03-07 19:05:28 EST
Happening here with KDE, too. Behaviour is actually "scroll lock led lights up 
when X starts, and goes out if either num lock or caps lock are on (or both)". 
 
Could be a kernel issue, since I *didn't* see it *after* updating to recent 
xorg + xkbdata packages but *before* booting into a recent kernel. 
 
Comment 18 Bill Crawford 2006-03-07 19:06:56 EST
Hmm, scratch that, "xkbvleds" shows the same behaviour as the physical LEDs. 
Comment 20 Vitor Domingos 2006-03-08 08:06:09 EST
problem *almost* solved with xorg-x11-xkbdata-1.0.1-7, but now the scrollkey
never lights up.
Comment 21 Mike A. Harris 2006-03-09 04:15:06 EST
(In reply to comment #16)
> Whatever changed in xorg-x11-xkbdata-1.0.1-7 I do not see ScrollLock LED
> to light up; as a matter of fact in any circumstances and does not matter
> which keys are pushed and that includes ScrollLock itself.  At the first
> glance other recent updates should be immaterial.

xorg-x11-xkbdata-1.0.1-7 contained an update from
xkeyboard-config 0.7 to version 0.8

 
> I am not sure how this affects laptop keyboards.  I do not have such test
> installation.
> 
> So whos problems is that really and what should be closed?  Is this truly
> a freedesktop.org baby?

That's not clear yet.  I assume it's an xkeyboard-config bug, but rstrode
has suggested in IRC that it could be a GNOME bug perhaps.  Bill Crawford
above claims to have the problem in comment #17 which would make it seem the
problem is not limited to GNOME, but more generic.  I don't know if our
KDE setup causes any GNOME stuff to run in the background or not though.

I'm still assuming this is an xkeyboard-config problem for now in light
of new data pointing to something else.

Moving to FC5Update, FC6Target trackers as FC5 is baked.

Comment 22 Hans de Goede 2006-03-09 06:26:53 EST
I've seen this strange scroll-lock behaviour todat too, after doing a full
update 2 rawhide its completly gone. Notice I do not and have nver used the leds
to show alternative keyb groups.

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