Scroll lock does not work in X

[Sigve Indregard]

Binary package hint: xkb-data

The scroll lock key does not do anything in X. This applies to ubuntu 6.06. I have tested this with two very different systems. The scroll lock LED does not turn itself on, and it's impossible to get to the "SCROLL" functionality of OpenOffice.org Calc.

The scroll lock key works as expected in the text VTs, but not in VT7 (or other X VTs).

Turning on the led through xset led 3 works as expected.

This is an issue to quite a few people because illuminated keyboards often simply hardwire the light on the scroll lock-led. Therefore, illumination does not work in Ubuntu without knowing the cryptic xset commands.

I figure this is due to some misconfiguration of xkb, but this is an area I know very little of.

[Ropetin Again (ropetin)]

I've detected this same problem in both 6.06 and 6.10 (clean install and upgrade). However, I do have a little more information.

When scroll lock is pressed the light does not come on, and it does not appear to work. I have a TrendNet USB KVM, and double pressing Scroll Lock should make it switch to the next machine, this does not work in Ubuntu, but does in Windows XP.

If I go to System --> Preferences --> Keyboard Shortcuts, and program the email function to be triggered by Scroll Lock, it works fine. The name it gives the key when I press it is 'Scroll_Lock', and pressing Scroll Lock brings up Evolution. If I then program Email for a different key and try a double press of Scroll Lock, it still doesn't switch to the next machine.

As a temporary (and very annoying) workaround I can run this at the command line;

xset led 3; xset led on; xset led off

Sometimes I have to preempt that what another xset led 3, but in a short amount of testing I can't see a pattern of when one xset led 3 is needed, and when two are needed.

Interestingly, if I leave Scroll Lock set to open Email via Keyboard Shortcuts, and do any combination of xset led 3, xset led on or xset led off, Evolution does not open up. That makes me think what Ubuntu thinks is Scroll Lock and what we think is Scroll Lock have two different keyboard codes (if thats the right way to describe it)?

[Micah Cowan (micahcowan)]

Confirming per comments.

[Ropetin Again (ropetin)]

This is still happening in 7.04 (Ubuntu and Kubuntu), and still just as annoying as ever!

[Mike Frazier (mike-frazierhome)]

Found a workaround for this. First, find an unused modifier by typing:

xmodmap -pm

My mod3 was free (so adjust the commands accordingly if you use a different modifier). Now type the following:

xmodmap -e 'add mod3 = Scroll_Lock'

After doing this, your scroll lock key will now work. You can now make this a permanent fix by adding the following line to /root/.Xmodmap (if the file isn't there, then create it):

add mod3 = Scroll_Lock

By putting this in root's Xmodmap, it will enable the scroll lock key every time X starts.

[Tim Abell (tim-abell)]

I have the same problem in 8.04 hardy heron.

Creating /root/.Xmodmap didn't work for me. Adding "xmodmap -e 'add mod3 = Scroll_Lock'" to ~/.xmodmap as per http://www.nabble.com/Re%3A-Swap-Remap--Ctrl-and-Alt-keys-p17724405.html works, but pops up a dialog for running the addition at login, which is just as annoying.

Beats me why they don't just put a switch on the keyboard somewhere. I've also discovered that ctrl+backspace (no alt) restarts X when scroll lock is on, which caused me to have to re-write this message a few times!

[Bryce Harrington (bryce)]

Seems to still be an issue in jaunty.

[Bryce Harrington (bryce)]

xev shows it is recognizing Scroll_Lock hits...

KeyPress event, serial 33, synthetic NO, window 0x3400001,
    root 0x77, subw 0x0, time 321477394, (1755,680), root:(1765,728),
    state 0x0, keycode 78 (keysym 0xff14, Scroll_Lock), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyRelease event, serial 33, synthetic NO, window 0x3400001,
    root 0x77, subw 0x0, time 321477506, (1755,680), root:(1765,728),
    state 0x0, keycode 78 (keysym 0xff14, Scroll_Lock), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyPress event, serial 33, synthetic NO, window 0x3400001,
    root 0x77, subw 0x0, time 321477743, (1755,680), root:(1765,728),
    state 0x0, keycode 78 (keysym 0xff14, Scroll_Lock), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyRelease event, serial 33, synthetic NO, window 0x3400001,
    root 0x77, subw 0x0, time 321477899, (1755,680), root:(1765,728),
    state 0x0, keycode 78 (keysym 0xff14, Scroll_Lock), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

[Bryce Harrington (bryce)]

I also tried mapping the scroll lock key to "Launch Calculator" and it works fine at launching that, but the led never changes.

[Derek White (d-man97)]

I can confirm all problem-related comments in Jaunty.

xev shows the button press, mod3 is blank, "xmodmap -e 'add mod3 = Scroll_Lock'" works for current session. I have not applied it to .Xmodmap/.xmodmap yet, as there are conflicting results as to where to put it and whether it works.

If it's related, see Bug 393285.

Keyboard: Saitek Eclipse Model # KU-0418, Assembly # KU-0573.

[Tom Swartz (tom-swartz07)]

This issue also affects Lucid. I am experiencing all of the same symptoms.

Was there a patch released for this? If so, what about the status of the patch for Lucid?

[yota (yota-opensystems)]

Confirming the behaviour on Lucid and that this is "still just as annoying as ever!" after 4 years...

On my setup, a logitech mk 710 and intellinet 2 ports usb kvm, the "xmodmap -e 'add mod3 = Scroll_Lock'" restores the led functionality, but does not trigger the kvm switch.
On the opposite "numlockx toggle; sleep 1; numlockx toggle" works under X.

Everything works fine in a VT.

[Tom Swartz (tom-swartz07)]

Got it!

the "xmodmap -e 'add mod3 = Scroll_Lock'" fixes the light, so that it will now actually work when you hit scroll lock.

to use xset, you need to call it by name
xset led named "Scroll Lock"
will illuminate the light

[Bryce Harrington (bryce)]

Can confirm this is still an issue in Natty, and that the workaround of running `xmodmap -e 'add mod3 = Scroll_Lock'` solves it.

[Bryce Harrington (bryce)]

At least, the issue of the scroll lock light not lighting up is still an issue.

I can't seem to find an application that changes behavior depending on whether scroll lock is toggled (with or without the mod3 addition). Tested xterm, firefox, openoffice... all seem to scroll just fine.

To be honest I'm a little unclear as to what the underlying problem here is (numerous different people have commented on this bug but I'm not sure everyone's problems were the same).

1. The issue that the scroll lock key is lit up sometimes that Derek mention appears to be solved separately now according to his comment on #393285

2. Being able to map something to activate when scroll lock is hit (as in comment #1 and #8) seems to already work, despite the led not toggling. But I'm not certain the user would want the led to toggle in such a case anyway?

3. For KVMs that toggle when Scroll Lock is tapped, I have such a KVM myself, attached to two Lucid boxes, and in fact I do use Scroll Lock to do the toggling, and it works ok for me. Could issues related to this be a hardware or kernel issue rather than xkeyboard-config?

Anyway, given all the uncertainties I think what I want to do is close out this bug report, as it's old and rambly, and ask those of you who still have Scroll Lock related issues to please file new bug reports (use 'ubuntu-bug xorg' so your report includes your key configuration, dmesg, and so on) and please provide a detailed account of the issue you see (describe your specific use case, hardware, and expectation). It may be that there is kernel breakage underlying your issue, or maybe there's a better way to achieve your ends, or if nothing else it will make it easier for us to forward the bug report upstream. Thanks ahead of time!

[Sigve Indregard (sigve-indregard)]

Go ahead and close it, Bryce. I can't verify the bug anymore, as the backlit keyboard this bug originally messed up is long gone.

However: Your comments mention other reasons to close the bug. Still, the original bug (not the comments' bugs) remains, as far as I am able to tell.

I would still go for closing this one and instead wait for a new report from a new user with a similar keyboard.

[yota (yota-opensystems)]

@Bryce:

my KVM still doesn't toggle under X in maverick, while it toggles on a VT.

Since the problem still seems to apply to various KVMs and the issue just says "Scroll lock does not work in X" (which is true) it seems to me valuable to keep it open.

Moreover "scroll lock doesn't work in ubuntu" on a search engine is likely to land here, leaving this issue open helps collecting everyone's experience in one place.

[Bryce Harrington (bryce)]

On Thu, Feb 17, 2011 at 02:12:03PM -0000, yota wrote:
> @Bryce:
>
> my KVM still doesn't toggle under X in maverick, while it toggles on a
> VT.
>
> Since the problem still seems to apply to various KVMs and the issue
> just says "Scroll lock does not work in X" (which is true) it seems to
> me valuable to keep it open.

If this were a support forum I'd agree, but the usage pattern for a bug
tracker is different, and actually general practice is to keep bug
reports as fine grained as possible.

Especially with hardware problems like KVM switches it's not uncommon to
need a separate fix for each specific type of device. In this sort of
situation, it's really helpful to have each person's problem as a
separate bug report, so as we generate or locate patches we can keep
track of which KVMs still need attention and which are solved.

Also, bug trackers tend to make it really cheap and easy to dupe
multiple bug reports, whereas splitting one bug report out into several
isn't possible. So even in the case where everyone's KVM scroll lock
issue was identical, it's not hard for us developers to quickly verify
this, and then easily mark them as dupes. Then, if later on we find
we've made a mistake we can undupe bugs on a case by case basis and
carry on.

Anyway, I'm belaboring the point. But trust me, it really does help to
have separate bug reports for each person and each particular piece of
hardware. :-)

> Moreover "scroll lock doesn't work in ubuntu" on a search engine is
> likely to land here, leaving this issue open helps collecting everyone's
> experience in one place.

Actually, if the bug is closed, the search engine will still be able to
link to it, so that's not a problem.

But I think what you are wanting in this case would be best served as a
discussion thread on a technical support forum such as askubuntu.com or
the ubuntu forums, which I think would be a really good idea.
Meanwhile, in the bug tracker we really should just focus development
efforts towards *fixing* the bug.

[yota (yota-opensystems)]

First of all thank you for your answer.

I'm really sorry, bringing up my specific problem (related to the kvm) seems to have diverted the attention from the core business of this bug report.

IMHO the problem at stake here is that "scroll lock doesn't work under X", which is true even without KVMs (in fact it doesn't work on the pc that I'm writing from, which is not connected to a KVM).
I had the bad idea to back-up my reasoning by illustrating that (I believe) this ultimately has consequences on many KVMs, but please forget that and just focus on restoring scroll lock functionality "per se".

AFAIK I've never seen a single ubuntu machine where scroll lock works properly under X and, considered that, this bug report seems fine to me.

Hoping to help I'll try to describe what should be the expected functionality of the scroll lock key.
On a VT:
-launch a command that produces a very verbose output, say "find /"
-press scroll lock and notice that the scroll pauses and the "scroll lock" led on the keyboard lights up

Under X :
-open a terminal and launch a command that produces a very verbose output, say "find /"
-press scroll lock and notice that perfectly nothing happens (no led, no lock)

This is not something hardware-related, and fragmenting the same problem under lots of potentially unrelated perspectives desn't seem to be productive.

For the sake of completeness, if you are still wondering why your KVM works and mine doesn't, it probably depends on how they are detecting toggle condition.
Your KVM probably is smart enough to be aware of the actual keys pressed on the keyboard and so it switches when scroll lock is tapped two times in a small amount of time.
On the other hand mine, which is a dumb KVM, has no idea of what are those strange electric signals going over those wires inside him... it just switches if the "scroll lock" led flashes. (so no led->no toggle)

If scroll lock worked as it should both (and hopefully all) KVMs would operate correctly.

Bottom line: please forget everything I said about KVMs and just fix scroll lock under X.

[Tim Abell (tim-abell)]

filed new bug as requested: https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/912044

[Tim Abell (tim-abell)]

see also https://bugs.launchpad.net/linuxmint/+bug/662517