Toshiba Satellite U300 volume wheel sticking

[Andrew Gee]

I'm running up-to-date intrepid. I have a volume control wheel on the side of my Toshiba U300 laptop. This volume control did work as expected in hardy. It operates like a scroll wheel on a mouse, in the way that it has specific points at which it sends a signal. When I got to these points on hardy, the volume would just increase or decrease by one block.

With intrepid it gets the volume to go up one block, then waits for a second and then keep turning the volume up constantly without stopping. I've found if I hold a key on the keyboard down, for example Ctrl, it stops it temporarily. When I release Ctrl it start zooming off increasing or decreasing again. I have found if I swap desktops by holding down Ctrl Alt Left or Right, it stops it zooming off increasing or decreasing completely.

I'm sorry if the above was a bit confusing. It's surprisingly hard to explain :)

[Tomasz (tomasz-redhat-bugs)]

On a Toshiba Satellite Pro U300 laptop (and others with the Pro series), there
is a volume dial on the side of the laptop, which is used to control the sound
volume.

It works on Fedora GNOME 2.22.1, but incorrectly.

Even slightest move up of the dial, moves the volume all the way up. The volume
control beside the clock shows the setting is in effect, also the volume icon
popup shows the volume all the way up.

The same happens with even slightest move the volume dial down. It turns the
volume all the way down, showing the mute sound icon beside the clock on the
panel and on the popup.

Aditionally the move breaks the keyboard handling. After the volume all up/down
keyboard is left in a non-working state. The signalling is still on because the
volume popup stil shows and disappears consistenly showing the max/mute icon.

I tried to see what keycodes the volume dial sends using 'xev', but since the
keayboard handling breaks during the dial move, I couldn't get much information
of it.

To get my keyboard working back, I need to switch to text console (Ctrl-Alt-F1)
and back to graphical console (Alt-F7).

Description of problem:

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

How reproducible:

Steps to Reproduce:
1.
2.
3.

Actual results:

Expected results:

Additional info:

[Bastien (bastien-redhat-bugs)]

First, gnome-audio has nothing to do with your problem. gnome-audio is a package
with a bunch of audio files to be played when certain events occur, ie. an audio
theme.

As for using the dial "breaking the keyboard handling", I'm not quite sure what
it means. You could try using the dial on the command-line instead, with a tool
like evtest (not packaged, look for evtest.c on google), or printing whatever
xev gives you back (even if you need to switch VTs to get to the result).

My guess is that this Toshiba laptop needs a driver to make this button work
appropriately. Reassigning to the kernel, where hopefully somebody will have the
hardware to test this, and point the finger back at GNOME if it's indeed the
culprit (unlikely).

[Tomasz (tomasz-redhat-bugs)]

This is not a kernel problem.

This volume dial sends normal multimedia keyboard VolumeUp and VolumeDown
keypresses. But I guess with some additional keycodes. In GNOME Keyboard
Shortcuts these are correctly identified as XF86AudioRaiseVolume and
XF86AudioLowerVolume.

Under textmode console there is no problem. Turning the volume wheel yelds some
~ characters on screen only, but the keyboard is still working.
Under XOrg, once I move the volume dial, keyboard is not working anymore. Maybe
it is switched to RAW mode or something? (I don't know the exact X internals).

So, this is more likely XOrg/GNOME problem, not kernel.

I would gladly help debugging it, but I do need some guidance.

[Chuck (chuck-redhat-bugs)]

Can you boot to text mode and run 'showkey -s' then turn the volume up one
click, let showkey terminate and post the output?

[Tomasz (tomasz-redhat-bugs)]

VolumeUp is:
0xe0 0xb0 0xe0 0x30 0xe0 0xb0 0xe0 0x30 0xe0 0xb0 0xe0 0x30

VolumeDown is:
0xe0 0xae 0xe0 0x2e 0xe0 0xae 0xe0 0x2e 0xe0 0xae 0xe0 0x2e

[Bug (bug-redhat-bugs)]

Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

[Tomasz (tomasz-redhat-bugs)]

Fedora 9 is out.

Is anything going around this issue?

[Peter (peter-redhat-bugs)]

sounds like http://lists.freedesktop.org/archives/xorg/2008-June/036634.html

can you run evtest [1] on the device file and move the wheel by one? this should
indicate whether a key down event is being sent.

[1] http://people.freedesktop.org/~whot/evtest.c

[Bastien (bastien-redhat-bugs)]

(In reply to comment #7)
> sounds like http://lists.freedesktop.org/archives/xorg/2008-June/036634.html

I don't like that patch because it breaks auto-repeat for a huge number of
perfectly working keyboards, and it adds policy to the X server. This should
probably only be done if a certain hal property was present.

[Tomasz (tomasz-redhat-bugs)]

After moving the wheel up by one I got the following output:
Event: time 1216648995.027213, type 4 (Misc), code 4 (ScanCode), value b0
Event: time 1216648995.027232, type 1 (Key), code 115 (VolumeUp), value 0
Event: time 1216648995.027235, -------------- Report Sync ------------
Event: time 1216648995.037187, type 4 (Misc), code 4 (ScanCode), value b0
Event: time 1216648995.037198, type 1 (Key), code 115 (VolumeUp), value 1
Event: time 1216648995.037200, -------------- Report Sync ------------
Event: time 1216648995.067159, type 4 (Misc), code 4 (ScanCode), value b0
Event: time 1216648995.067170, type 1 (Key), code 115 (VolumeUp), value 0
Event: time 1216648995.067172, -------------- Report Sync ------------
Event: time 1216648995.077224, type 4 (Misc), code 4 (ScanCode), value b0
Event: time 1216648995.077232, type 1 (Key), code 115 (VolumeUp), value 1
Event: time 1216648995.077234, -------------- Report Sync ------------
Event: time 1216648995.107180, type 4 (Misc), code 4 (ScanCode), value b0
Event: time 1216648995.107189, type 1 (Key), code 115 (VolumeUp), value 0
Event: time 1216648995.107191, -------------- Report Sync ------------
Event: time 1216648995.117238, type 4 (Misc), code 4 (ScanCode), value b0
Event: time 1216648995.117245, type 1 (Key), code 115 (VolumeUp), value 1
Event: time 1216648995.117247, -------------- Report Sync ------------

Full evtest output attached.

Do we have evidence, that the patch really breaks things?

[Tomasz (tomasz-redhat-bugs)]

Created attachment 312257
evtest run output

[Peter (peter-redhat-bugs)]

yep, same problem. we never get a key up event, resulting in endless key repeats
by the server.

(In reply to comment #8)
> (In reply to comment #7)
> > sounds like http://lists.freedesktop.org/archives/xorg/2008-June/036634.html
>
> I don't like that patch because it breaks auto-repeat for a huge number of
> perfectly working keyboards, and it adds policy to the X server. This should
> probably only be done if a certain hal property was present.

agreed. mjg59 was talking about a kernel quirk for this, this is the "correct"
solution.

[Mackenzie Morgan (maco.m)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. Unfortunately we can't fix it without more information. Please include the information requested from the "Reporting Sound Bugs" section of https://wiki.ubuntu.com/DebuggingSoundProblems as separate attachments.

[Andrew Gee (andrewgee)]

I have included the debugging information that has been requested. lspci -vvnn is attached.

And the alsa sound information has uploaded here:
http://www.alsa-project.org/db/?f=942e2d5ab0835dddc64dc6278f8fbf504f0a9d3c

uname -a:
Linux andrew-laptop 2.6.27-3-generic #1 SMP Wed Sep 10 16:02:00 UTC 2008 i686 GNU/Linux

[Brian Murray (brian-murray)]

This seems more likely to be an xorg bug with the input device.

[Tomasz Sterna (smoku)]

The problem is described in detail in RedHat Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=444440

It has a solution: http://lists.freedesktop.org/archives/xorg/2008-June/036373.html which I guess was applied on Hardy, because Ubuntu Hardy was the only distribution that got my volume wheel working fine.
With upgrade to Intrepid it is broken again.

[Tomasz Sterna (smoku)]

Provided detailed information and proposed solution.

[Tomasz Sterna (smoku)]

See also http://lists.freedesktop.org/archives/xorg/2008-June/036380.html for devs discussion.

[Timo Aaltonen (tjaalton)]

Looks like it needs a kernel quirk. That was the outcome of the discussions.

Intrepid uses the evdev driver for keyboards, that's why the problem has resurfaced.

[Josh (theformerprophet)]

I have an HP Pavilion zv6000 running Intrepid Ibex with all of the latest updates. I upgraded from Hardy about a week ago and have seen this problem consistently. Hitting CTRL ALT DEL to log out and log back in will kill the issue, too. It's really annoying, and Ibex is due out in less than a week. any fix yet?

[rekado (rekado)]

This and its proposed duplicates sound similar to bug #285323, while there its not the volume control but brightness. The symptoms are the same, though as on my machine.

[Saivann Carignan (oxmosys)]

bug 285323 describes a similar issue and a known workaround is to kill gnome-power-manager by typing "sudo killall gnome-power-manager" before changing volume with FN keys. Does that work for anyone?

[Tomasz Sterna (smoku)]

"sudo killall gnome-power-manager" does not help me with the "sticking" volume wheel issue

[plindeman (peter-lindeman-nl)]

I also tried that a couple of days ago as described in https://bugs.launchpad.net/bugs/278781 but it also does not work for me.

[Saivann Carignan (oxmosys)]

Thanks for the confirmation. That means that these bugs are not related.

[Ztrange (ztrange)]

Same here, sorry didn't found the duplicate, thanks.

[AaronMT (aaron-train)]

This happens on my machine too, a Dell Inspiron 1501 running Ubuntu Intrepid Ibex.

[MAcks (xmacn-konto)]

I happen to have the same problem with Fujitsu Siemens Amilo Pi1505. Killing gnome-power-manager doesn't help. Switching desktops with ctrl-alt-left or right does hide the volume-bar window, but the keyboard isn't working until I switch to VT1 using ctrl-alt-F1. I'm switched back instantaneously without pressing ctrl-alt-F7.

[Rodrigo de Lima Vieira (rodrigo-mec)]

This happens on my machine too, a toshiba u300 series (u305-s5127).
I use the combination, CtrL+ALT+F1 then CtrL + ALT + F7 to workaround.
In hardy my volume wheel works fine. And only in hardy and in dapper. In Fedora 8 and 9, Mandriva 2008.1, 2009.0, opensuse 10.3 and 11.0 my volume whell doesn't work, in all the other distros i'd the same bug! (sorry about my english, is terrible!).
Can I help sending more information ou doing tests ?

[Tomasz (tomasz-redhat-bugs)]

Is someone working on the quirk?

[jrf2027 (jrf2027)]

Same bug for me on Ubuntu Intrepid. Volume control works fine under Hardy. I'm running on Toshiba U305-S2808.

[Zeppe (giuseppe-passino)]

Same for me after upgrade to Intrepid, fine with Hardy. My model is Toshiba U300-13U. Thanks for any info.

[Ben Schaffhausen (bhs128)]

I also have a HP Pavilion zv6000 and am seeing this issue. As the other bug reports may indicate, after the volume maxes out it will start to flicker. After pressing the buttons some more I can get the OSD to disappear, but now none of the GNOME menus will drop down (they do highlight though). I got out of this by pressing my power button and selecting reboot from the pop-up options.

I'm running the released 8.10 64-bit desktop with updates.

If there's anything I can do to help please let me know.

[Tomasz Sterna (smoku)]

It needs a kernel quirk - https://bugzilla.redhat.com/show_bug.cgi?id=444440#c11 - which disables auto-repeat for the media buttons.

[PPKuma (santiago-kuma)]

I have the same problem, Toshiba Satellite U305.
The best solution i've come up with while this bug is fixed is to disable the volume hoykeys, this way if i accidentally want to turn up/down the volume i will not fire that annoying bug.

[fghj (hjkl-deactivatedaccount)]

I'm running Intrepid vanilla 32bit on a Hewlett Packard zv6511ea and when I use the volume +/- keys I lose keyboard and mouse functionality in the same way as described above. That is: I can highlight menu names, like Applications, Places, System but am unable to select or expand the menus, and they keyboard keypresses do not appear in a Gnome terminal menu. And pressing Ctl-Alt f1 to switch to a virtual terminal, then Ctl-Alt f7 to switch back to X, I regain control. Also one press of the volume down hotkey will reduce the volume to 0. You can see the on-screen display reduce from the current level down to zero.

This sounds very like bug #285323, but what would I know.

[Peter (peter-redhat-bugs)]

Reassigning to kernel, sounds like Bug 460237 (for which I have seen a patch on linux-input) has a quirk already, should be able to get one for this one too.

[Dave in Berkeley (daweick)]

I have this problem too. I'm running 32 bit 8.10 on an HP Pavilion zv6000.

[drewp (drewp)]

Same thing on intrepid on an hp pavilion dv9000, 2.6.24-21-generic 32bit.

On this machine, the volume is adjusted by sliding your finger on a little stripe. It's like a laptop mousepad, but 1D and above the keyboard (http://www.laptopblog.org/images/jgfjh.jpg). What I find is the gently sliding and releasing still works fine, but if I press harder with my finger, I'll get a repeated volume adjustment until the volume hits 0 or 100%. The workaround is to be very gentle with this controller.

[ktemkin (kyle-ktemkin)]

Why don't we implement the same solution that was implemented in the old Xorg KBD drivers?

That is, add to the PostKbdEvent() function in evdev.c something along the lines of:

    /* fix events for volume keys */
    if(ev->code == KEY_VOLUMEDOWN || ev->code == KEY_VOLUMEUP)
    {
 //post a keydown and then a keyup, as media keys have no automatic key-up
 xf86PostKeyboardEvent(pInfo->dev, code, 1);
 xf86PostKeyboardEvent(pInfo->dev, code, 0);
 return;
    }

?

(I posted information about a temporary 'fix' here: http://ubuntuforums.org/showthread.php?t=974723)

[diablo75 (dave-davestechsupport)]

Ben Schaffhausen said "I also have a HP Pavilion zv6000 and am seeing this issue. As the other bug reports may indicate, after the volume maxes out it will start to flicker. After pressing the buttons some more I can get the OSD to disappear, but now none of the GNOME menus will drop down (they do highlight though). I got out of this by pressing my power button and selecting reboot from the pop-up options."

I am having the exact same problem on a Compaq Presario R4000 running the 32-bit version of Ibex. Hope this gets fixed soon.

[Jesse Kahtava (jesse-kahtava)]

I ran xev and turned the wheel a bit and the event is repeated infinitely. The only thing I could find that would stop the repeating is to Ctrl-Alt-F1 to a different terminal.

KeyRelease event, serial 34, synthetic NO, window 0x3600001,
    root 0x7a, subw 0x0, time 18887985, (167,-11), root:(841,15),
    state 0x0, keycode 122 (keysym 0x1008ff11, XF86AudioLowerVolume), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyPress event, serial 34, synthetic NO, window 0x3600001,
    root 0x7a, subw 0x0, time 18887985, (167,-11), root:(841,15),
    state 0x0, keycode 122 (keysym 0x1008ff11, XF86AudioLowerVolume), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

[catch (catch56)]

Just posting to confirm the same issue as reported on a Toshiba Pro U300 series (and the ctrl-alt-f1/ctrl-alt-f7 workaround does bring things back)

[Andrew Gee (andrewgee)]

And here's a confirmation that the bug still exists in jaunty :(

[Taner Senyurt (turshu)]

Yes bug still exist in jaunty :( but Solution Exist Here : http://www.tsenyurt.com/?p=56

[ktemkin (kyle-ktemkin)]

@Taner Senyurt:

I'd like to point out:

1) This isn't a problem with Jaunty, nor Intrepid. Instead, it's a problem with the "evdev" driver. The reason these problems are showing up in these distributions is that they use the newer "evdev" driver instead of the older "kbd" driver.
2) The link you posted to your blog/solution is actually pretty much a transpose of my earlier "temp fix", located at http://ubuntuforums.org/showthread.php?t=974723. While it's fine that you copy-pasted and paraphrased my work (including letter-for-letter my code, including my comments); I'd appreciate two things in the future: firstly, credit where credit's due is always nice, and secondly, please, please, please, please, please include the disclaimers I posted to the top of that post. My 'solution' is nothing more
than a temporary fix; it's very user-specific and requires attention any time there is an evdev update.

The problem still exists in Jaunty's evdev because the developers aren't quite sure where to fix it. Different models of computer behave differently given the volume keys. Most of these problem laptops 'hang' because they never send a key-up event; other computers (the majority) do. If one modifies the driver the way I have in the post I've written above, it's at the price of other users having a different problem: they press and hold their volume up key, and the volume only increments once.

The real solution needs to be implemented in a way that doesn't negatively affect the majority for the sake of providing functionality to the minority. For now, the minority can use this 'temp fix', while the developers decide where exactly to implement this 'fix' functionality. Perhaps later, there will be a more conclusive solution.

[Xandru (xandruarmesto)]

I just posting to report the same problem on my Toshiba U300-14Q with intrepdi and jaunty.

[A. Leon (aleon05)]

Same problem Jaunty Jackalope with Toshiba Satellite. This bug sucks....

[jetdog (slicksterdave)]

I can confirm this issue, and I have a lot more information for whoever is pursuing this.

(I originally posted this in the following thread)
http://ubuntuforums.org/showthread.php?p=7385680#post7385680

This issue is not ubuntu-specific - I have witnessed this in gentoo too (and likely affects them all, based on this bug). (Bear with me)

I originally tried mapping the volume up/down keys to multimedia functions within gnome using XModMap within gentoo (basically creating aliases for special commands within Xorg), but then found the very same problem in gentoo - so I pulled off the keymaps and took a look for what was happening on keyboard input.

Fortunately, I was able to test a few more things within gentoo - but I can confirm that this issue is guaranteed to be from the same source as the problem within ubuntu.

I tried using xev, a program for watching input via event-based devices within xorg, and noticed that pressing either of the volume up/down keys on the R4125CA (R4000-series compaq laptop) causes one key signal while a volume up/down button is pressed, and the moment either of those is released, a completely different signal from the first is spammed endlessly - no other keypresses will stop this.

So, I tried using "showkey" from outside of Xorg, in a framebuffer console (basically command-line without gui ) . Interesting, pressing and holding a volume up creates two seperate scan codes - something that I would imagine to be EXTREMELY quirky (and a terrible hack?). I am not aware of any software for linux that will correctly interpret a double scan code. But I suggest that the developers for ubuntu might be able to file this information with whomever would be responsible for dealing with this.

Also important, this bug is present __with or without__ xf86-input-evdev ==> meaning that the problem has to start even before the keypresses are getting to Xorg's evdev driver. Perhaps in the kernel source for evdev ? *tear* :(

My locale and console region when dealing with this were EN-US and UTF-8.

As for the above issues of having the mouse pointer clicks not occuring - what I think I noticed was that following a volume key (for this device), a mouse click's signal is different, which explains why none of the mouse clicks after this event were working. (Don't take my word for it, I was watching the input scroll very fast - and can post a log if we need to confirm this)

I would also like to point out that physically inside this system, it appears that the multimedia buttons are not directly part of the physical keyboard, though they might get combined via hardware later on (Which could be the real source of this mess - and software would be how windows *ahem* is dealing with this issue)

I can also confirm that this issue exists on the livecd.

Just as a suggestion: I believe it was the ZV-6000 (i think compaq) has similar internals to the R4000 - perhaps this issue should contain this information as well for whomever is trying to test it.

If ubuntu needs more debugging information, I will be happy to test this further, since I'm quite interested in fixing this for everyone -- because this issue has been present for a LONG time i...

[ktemkin (kyle-ktemkin)]

I don't think you're correct at all in diagnosing that the problem _isn't_ evdev. Making a few code modifications to the evdev driver to account for the odd scancode reporting fixes it right up, even if the volume control isn't as smooth as the windows version is. This definitely indicates that the problem is (at least resolvable) in evdev.

I think I'm repeating myself, but I'll explain basically how the scancode works on a normal keyboard key:

1) The keyboard (hardware) reports a scan-code indicating that the key has gone _down_. This indicates which physical key was pressed to the software.
2) The 'driver' software translates the scan-code to the correct key-press in the system locale and reports it to the shell/x-server/etc as a 'key event'.
3) The driver code waits a specific amount of time for another scan-code, indicating that the key has gone _up_. When this is not received, it sends another key 'event'.
4) Finally, the key is released, and the keyboard reports a scan-code indicating that they key has gone _up_. The driver stops paying attention, as it knows no (further) auto-repeat is required.

The problem is that when keyboards with media keys were first created, there wasn't an explicit media keys standard- many OEMs provided their own drivers. These keyboards, as often as not, did not bother to send key-up events for their media keys. After all, keys like "stop", "eject", "play', and etc. didn't really necessitate knowing when the key was released, only when it was pressed.

When the media key format became more standardized, both the windows drivers and the original X 'kbd' driver made a modification to their code, which automatically injected a key-up directly after a key-down for any media key. This 'hack' essentially turned of auto-repeat for media keys.

Up until Hardy Heron, Ubuntu utilized the older X 'kbd' driver- so you may notice that your volume keys work fine there. However, in the newer versions, the 'evdev' driver is utilized instead, which lacks the fundamental media-key-norepeat hack.

When I have time, I'll work on a similar hack for evdev- I have a prototype running on my machine (and several other users machines) that works perfectly, but I haven't had time to smooth out a few things (like the fact that this makes the volume 'keys' extremely oversensitive on the volume wheels of the U300 series.)

[Attila Franczen (marrow)]

In case you need beta testers, just let me know.

2009/6/3 ktemkin <email address hidden>:
> I don't think you're correct at all in diagnosing that the problem
> _isn't_ evdev. Making a few code modifications to the evdev driver to
> account for the odd scancode reporting fixes it right up, even if the
> volume control isn't as smooth as the windows version is. This
> definitely indicates that the problem is (at least resolvable) in evdev.
>
> I think I'm repeating myself, but I'll explain basically how the
> scancode works on a normal keyboard key:
>
> 1) The keyboard (hardware) reports a scan-code indicating that the key has gone _down_. This indicates which physical key was pressed to the software.
> 2) The 'driver' software translates the scan-code to the correct key-press in the system locale and reports it to the shell/x-server/etc as a 'key event'.
> 3) The driver code waits a specific amount of time for another scan-code, indicating that the key has gone _up_. When this is not received, it sends another key 'event'.
> 4) Finally, the key is released, and the keyboard reports a scan-code indicating that they key has gone _up_. The driver stops paying attention, as it knows no (further) auto-repeat is required.
>
> The problem is that when keyboards with media keys were first created,
> there wasn't an explicit media keys standard- many OEMs provided their
> own drivers. These keyboards, as often as not, did not bother to send
> key-up events for their media keys. After all, keys like "stop",
> "eject", "play', and etc. didn't really necessitate knowing when the key
> was released, only when it was pressed.
>
> When the media key format became more standardized, both the windows
> drivers and the original X 'kbd' driver made a modification to their
> code, which automatically injected a key-up directly after a key-down
> for any media key. This 'hack' essentially turned of auto-repeat for
> media keys.
>
> Up until Hardy Heron, Ubuntu utilized the older X 'kbd' driver- so you
> may notice that your volume keys work fine there. However, in the newer
> versions, the 'evdev' driver is utilized instead, which lacks the
> fundamental media-key-norepeat hack.
>
> When I have time, I'll work on a similar hack for evdev- I have a
> prototype running on my machine (and several other users machines) that
> works perfectly, but I haven't had time to smooth out a few things (like
> the fact that this makes the volume 'keys' extremely oversensitive on
> the volume wheels of the U300 series.)
>
>
> ** Changed in: linux (Ubuntu)
>       Status: Confirmed => In Progress
>
> ** Changed in: linux (Ubuntu)
>     Assignee: (unassigned) => ktemkin (kyle-ktemkin)
>
> --
> Volume control wheel on laptop is sticking in ubuntu
> https://bugs.launchpad.net/bugs/271706
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>
> Status in xserver-xorg-input-evdev: New
> Status in “linux” source package in Ubuntu: In Progress
> Status in “linux” source package in Fedora: In Progress
> Status in Gentoo Linux: New
>
> Bug description:
> I'm running up-to-date intrepid. I have a volume control wheel on the side of my Toshiba U300 lap...

[ktemkin (kyle-ktemkin)]

Ultra-simple patch, anyone?

[jetdog (slicksterdave)]

@ktemkin :

I understand that position entirely, but I was under the impression that evdev events originate within the kernel itself, and that they get sent at probed intervals as long as a key is considered "down" by the hardware.

After reading more source code, it looks like it is actually event-based, in that a "down" or an "up" is sent, ONLY once, by the kernel, and that the evdev (or kbd, as i also found in one of my test cases -- which also has the problem for the r4000/zv6000), is what generates the repetition.

Yummy... answers, time to play with patches :)

[jetdog (slicksterdave)]

@ktemkin:

Okay, got something you might enjoy besides more confusion:

Just writing
+ if(ev->code == KEY_VOLUMEDOWN || ev->code == KEY_VOLUMEUP)
+ return;

Unfortunately seems to result in no keyevents for the volume up/down buttons at all (R4000) , as indicated by xev.

I think you original modification was more correct with this:

 if(ev->code == KEY_VOLUMEDOWN || ev->code == KEY_VOLUMEUP)
    {
 //post a keydown and then a keyup, as media keys have no automatic key-up
 xf86PostKeyboardEvent(pInfo->dev, code, 1);
 xf86PostKeyboardEvent(pInfo->dev, code, 0);
 return;
    }

Also, I suggest a slightly improved version of this, because this modification will apply for all xf86-input-evdev generated events (so for people whom have two keyboards with volume buttons, one working, one quirky, we would be throwing volume "up then down" events (as per above), for keyboards that successfully have the "volume key release" event correctly implemented. To fix such, I suggest the following:

+ if (ev->code == KEY_VOLUMEDOWN || ev->code == KEY_VOLUMEUP) {
+ if (value) {
+ xf86PostKeyboardEvent(pInfo->dev, code, 1);
+ xf86PostKeyboardEvent(pInfo->dev, code, 0);
+ }
+ return;
+ }
+

^ ^ if my understanding of "value" is correct, one that evaluates to true should mean a "keydown" event -- this way, a working keyboard that correctly implements "volume key release" will not generate an extra "up then down" when we release a volume key on a working keyboard (and yes, some of us use 2, if not 3 keyboards xD)

Keep in mind that although this DOES stop the auto-repeat symptoms for our events within the xf86-input-evdev driver (as you said earlier). I'm not convinced that this is the source of the problem, and would thus classify this as a "hack-fix" to relieve symptoms. (see my next comment)

[jetdog (slicksterdave)]

Within a framebuffer console, no xdm started:

Output from showkey, which parses kernel output from /dev/console , is not based on kernel evdev driver. (So, way before evdev which normally provides events to xf86-input-evdev).

Normally, output from showkey would look like this for regular keys:

"f"
keycode 33 press
keycode 33 release
"k"
keycode 37 press
keycode 37 release
"j"
keycode 36 press
keycode 36 release

Notice that the attached output from "volume down (press x2, then press/hold for 5 seconds), then repeat for volume up" doesn't generate additional "release" events. This seems to be outside of the scope of evdev.

The information is in agreement that our hardware isn't getting the right "release" events to the kernel -- most likely because a release event is not implemented at the hardware level.

In the interest of kernel efficiency, if we were to start running checks in the kernel input driver itself (way out of my league here, but just theoretically), for "if it's a volume key", the additional check would get applied for every key - but that's something we're already doing -- except after a series of calls have made their way to xf86-input-evdev. It almost makes finding a way to generate a "release" event earlier, somewhere in the kernel, justified.

Nonetheless, let me know if you agree with the fix to your patch posted in the above comment -- handling this within input-evdev isn't entirely proper, and may add 1 or two extra non-intensive function calls, but it makes for an easy fix :)

[ktemkin (kyle-ktemkin)]

Actually, I've found the former works better with the U300 series (as mentioned in the bug itself; the U300 toshibas have an odd volume wheel which loses sensitivity with the latter fix), while the latter is a more general-case solution.

As per the source of the problem, I've spoken with some people familiar with the history of evdev/kbd, and the consensus is that we're trying to fix a hardware problem with software. While that's generally not the best approach, we're left little choice.

After a lot of thought, the consensus on the kbd project was to use a hack similar to mine. It is very much a hack- but I don't know what else we can do.

If anyone has any better suggestions, I'd be glad to listen. I expect I'll get more work done on this tomorrow; I plan on borrowing another laptop (I have a U305) that exhibits this problem so I can do some more keyevent testing.

[jetdog (slicksterdave)]

Sorry, Forgot to include the user-friendly version of my log above.

Makes for easier reading :)

Again, the input that generated this was:

vol_down: press, release, press, release, press/hold 5 seconds, release
vol_up: press, release, press, release, press/hold 5 seconds, release

[jetdog (slicksterdave)]

Hmm, this is just a random thought, but perhaps you might be able to write a hacked version of xf86-input-evdev based on the "value" returned by the volume key events (it seems the kernel knows something we don't? :D ). I noticed that for the R4000, the volume keys do not generate value = 0 OR value = 1... they ONLY generate value = 2 for volume keys (when i compare it to other key events, i believe it means that the key is being held "down").

Is it possible that this is the same for the U300 ? If it is... then we may have a means of identifying these "problem" keyboards within evdev - compliant drivers.

You should test the other quirky machines, for their reported "values" with sudo evtest /dev/input/eventX (keyboard) -- to see if they too only create value = 2 events for volume "keys" -- just a thought for a generic solution :)

I'm not sure if these "value" outputs from evtest are the same values seen within the source of input-evdev... but if these problem machines have a lot in common, we may have a way of disabling auto-repeat similar to your hack.

[Tomasz Sterna (smoku)]

Please take a look at https://bugzilla.redhat.com/show_bug.cgi?id=444440#c11

[jetdog (slicksterdave)]

@ Tomasz Sterna : an excellent find. I followed the changes along the kernel cvs, and it looks like a proper fix for the R4000/zv6000 would be very similar to the bugs that were fixed in that report, via the kernel input drivers.

(We may need more information for the U300, particularily, an evtest dump of the volume dial in action.)

Specifically, these links look extremely like what we should be aiming for in any stuck keys:

Take a look at the original bug report, and the event output generated by the kernel (fedora, yes it's a Zepto 6615WD, but bear with it):
https://bugzilla.redhat.com/show_bug.cgi?id=460237

Notice the events reported are the exact same as for the R4000/ZV6000, even the event codes:
0xe0 0x2e
0xe0 0x30

Now look at the fix (for the Zeptec) within the fedora kernel... handled within /drivers/input/keyboard/atkbd.c
http://cvs.fedora.redhat.com/viewvc/rpms/kernel/F-9/linux-2.6-input.git-atkbd-add-quirk-for-inventec.patch?view=log&root=extras&sortby=date&pathrev=kernel-2_6_27_7-53_fc9

I'm very tempted to play with this myself once i get a free moment.

I understand this bug has gotten plastered with zv6000/R4000 non-wheel (although related) problems, so it would be good to get the focus back to the original U300 system.

Can anybody post an evtest for the U300?

[jetdog (slicksterdave)]

I found this within the mainline kernel pertaining to the user with the reported problems in the zv6000. It seems that there is a fix for the zv6100 in the mainline around 2.6.29 -- not sure if it would have the same codes, but it's a possible candidate.

[jetdog (slicksterdave)]

I found this within the mainline kernel pertaining to the user with the reported problems in the zv6000. It seems that there is a fix for the zv6100 in the mainline around 2.6.29 -- not sure if it would have the same codes, but it's a possible candidate.

http://lkml.indiana.edu/hypermail/linux/kernel/0901.1/01125.html

[Andrew Gee (andrewgee)]

I have a U300, and am actually the original reporter of this bug.
Apologies if this isn't right,

I ran the command "sudo evtest /dev/input/event4"

Got the following output when moving the volume wheel. I made sure I only moved the wheel one unit. I didn't continue to scroll the wheel around. I'm not quite sure why is repeated 3 times.

Event: time 1244569762.679864, -------------- Report Sync ------------
Event: time 1244569785.614607, type 4 (Misc), code 4 (ScanCode), value b0
Event: time 1244569785.614636, type 1 (Key), code 115 (VolumeUp), value 0
Event: time 1244569785.614641, -------------- Report Sync ------------
Event: time 1244569785.624559, type 4 (Misc), code 4 (ScanCode), value b0
Event: time 1244569785.624582, type 1 (Key), code 115 (VolumeUp), value 1
Event: time 1244569785.624587, -------------- Report Sync ------------
Event: time 1244569785.654547, type 4 (Misc), code 4 (ScanCode), value b0
Event: time 1244569785.654574, type 1 (Key), code 115 (VolumeUp), value 0
Event: time 1244569785.654580, -------------- Report Sync ------------
Event: time 1244569785.664587, type 4 (Misc), code 4 (ScanCode), value b0
Event: time 1244569785.664612, type 1 (Key), code 115 (VolumeUp), value 1
Event: time 1244569785.664618, -------------- Report Sync ------------
Event: time 1244569785.694586, type 4 (Misc), code 4 (ScanCode), value b0
Event: time 1244569785.694612, type 1 (Key), code 115 (VolumeUp), value 0
Event: time 1244569785.694617, -------------- Report Sync ------------
Event: time 1244569785.704664, type 4 (Misc), code 4 (ScanCode), value b0
Event: time 1244569785.704688, type 1 (Key), code 115 (VolumeUp), value 1

Let me know if I've done anything wrong or you need extra information.

Thanks,
Andrew Gee.

[Bug (bug-redhat-bugs)]

This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9. 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 '9'.

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 9'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 9 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 to the applicable version. 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.

The process we are following is described here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

[jetdog (slicksterdave)]

That's excellent Andrew,

From what it looks like there, you rotated the wheel to increase the volume. Just so we have it documented, can you post the same log, but for a volume down?

(we may need it to create a kernel quirk -- as it seems that nobody ever finished this one in fedora's tree)

[jetdog (slicksterdave)]

I have moved the r4100 bug/patch to a bug report in ubuntu-kernel: -- to keep this thread focused on u300.
https://bugs.launchpad.net/gentoo/+source/linux/+bug/385477
http://bugs.gentoo.org/show_bug.cgi?id=273477

Also, zv6100 issue is located in, as per bug (fixed in 2.6.27):
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/291878

Keepin' things clean :)

[Andrew Gee (andrewgee)]

Volume down evtest for U300:

Event: time 1244620732.513056, -------------- Report Sync ------------
Event: time 1244620732.523047, type 4 (Misc), code 4 (ScanCode), value ae
Event: time 1244620732.523077, type 1 (Key), code 114 (VolumeDown), value 1
Event: time 1244620732.523082, -------------- Report Sync ------------
Event: time 1244620732.552987, type 4 (Misc), code 4 (ScanCode), value ae
Event: time 1244620732.553012, type 1 (Key), code 114 (VolumeDown), value 0
Event: time 1244620732.553018, -------------- Report Sync ------------
Event: time 1244620732.563079, type 4 (Misc), code 4 (ScanCode), value ae
Event: time 1244620732.563104, type 1 (Key), code 114 (VolumeDown), value 1
Event: time 1244620732.563108, -------------- Report Sync ------------
Event: time 1244620732.593029, type 4 (Misc), code 4 (ScanCode), value ae
Event: time 1244620732.593054, type 1 (Key), code 114 (VolumeDown), value 0
Event: time 1244620732.593059, -------------- Report Sync ------------
Event: time 1244620732.603098, type 4 (Misc), code 4 (ScanCode), value ae
Event: time 1244620732.603126, type 1 (Key), code 114 (VolumeDown), value 1

[jetdog (slicksterdave)]

Andrew Gee: Can you run the following?

(Before you do this, make sure if you're in X/KDE/Gnome that you save and close your work, as you already mentioned that trying the volume wheel while in there may distort some of your input devices).

# echo "dmidecode > mydmilog.txt" | sudo bash
(will help us identify your laptop series in the quirk, if we get that far)

# echo "showkey -s > mykeylog.txt" | sudo bash
(For more complete information on the wheel... some of the information provided was slightly inconclusive)

Then move the wheel a single position up, followed by a single position down, and then a single up, and then a single down (try to be precise for these first ones) -- and then move it up several clicks, and then down several clicks? That program will stop logging after 10 seconds of inactivity, and will end automatically.

---

I find it strange that there is a 0,1,0,1,0,1 (total 6) in your volume up, and only a 1,0,1,0,1 (total 5) in your volume down -- also, that the volume down started at '1', vs volume up at '0'.

(To Debuggers reading this: if this is true, just a thought, the physical wheel might be a little imprecise in the scancodes that it transmits ... Getting an up-down-up-down "randomness" might generate more complete logs to try to get to the bottom of this - and i think it would really help to know exactly what and how many, or if there is some kind of variance or imprecision in the sensor - at which point we can decide what we can safely assume for the kernel quirk)

Thank you for the info thus far =D

[Tomasz Sterna (smoku)]

This is from a Toshiba Satellite Pro U300

P.S. The easiest way of regaining input control is switching to textmode and back (Ctrl+Alt+F1 then Alt+F7).

[A. Leon (aleon05)]

This are my results part #1:

[A. Leon (aleon05)]

Ups sorry the mydmilog.txt was not created by the command:

 # echo "dmidecode > mydmilog.txt" | sudo bash

?weird?

[jetdog (slicksterdave)]

I have cleaned up the duplicates for this bug, and changed the summary to deal with only the U300.

If anybody is subscribed to this bug and does not own a U300, please search for a volume repeat/stuck problem related to your hardware, to keep things organized for the maintainers. Unfortunately we have to deal with these keyboard quirks on a hardware-to-hardware basis.

As far as a patch goes for the U300, I will see about writing one for this system, based on the above information. I'm not sure if what I have in mind will work, but I will try to write a patch for the U300 for on the current Ubuntu kernel - and then hopefully someone in this bug subscription is comfortable/capable of compiling an ubuntu kernel to test it on a U300.

(Although I must say, this one is the most unique keyboard hardware quirk I have seen yet).

To illustrate this hardware quirk, for those trying to understand it (or those curious =D):
Wheel Up = on, off, on, off, ON (so keep sending from this point on)
Wheel Down = on, off, on, off, ON (so keep sending from this point on)
But when we do it again:
Wheel Up = negate last "up" state (so OFF), on, off, on, off
Wheel Down = negate last "down" state (so OFF), on, off, on, off
cycle complete.

I will do my best in the absence of any accountable logic on your part, Toshiba xD

[ktemkin (kyle-ktemkin)]

I think I can almost see their design rationale, especially if they wanted the controlling logic to be compatible with more than just their volume wheel- but deviations from any standard are almost always more headache than they're worth for developers, especially when documentation isn't available.

@jetdog:
My U305 has a compatible keyboard module, I can compile and test any kernels you provide.

Looking at various source versions of the old 'kbd' drivers, I'm of the opinion that it might be best to also hack a fix in input_evdev. It doesn't exactly address the source of the problem, but quirking the kernel for all of the keyboard configurations that suffer this issues will be a long and arduous process, especially considering all the testing and scrutiny a change has to be placed under before it can make it upstream.

Wouldn't it be better to, in addition to quirking the kernel, provide a hack in evdev with a single additional non-intensive call that would provide more immediate relief to the users? This is what was done in the 'kbd' drivers, though those used a different method of determining key events.

[Bug (bug-redhat-bugs)]

Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

[Richard (richardmandelbaum)]

Thank you to everyone working on this. I am new to Ubuntu - installed via Wubi on a Toshiba U305-S5127. I am experiencing this same bug and look forward to the solution. I am a newbie and not particularly tech-savvy so I am hoping that there will be a step-by-step guide for those of us who are not tech guys... I would like to switch over completely to Linux to support open source and avoid supporting more corporations than I have to!
Thanks.

[Bastien (bastien-redhat-bugs)]

*** Bug 511408 has been marked as a duplicate of this bug. ***

[Dan (dan-redhat-bugs)]

Can this bug be reopened, since it happens on Fedora 11 still? I don't see how to reopen the bug.

[molecule-eye (niburu1)]

I notice that, at least on my computer, after initiating the volume problem, putting the computer to sleep and then resuming from sleep fixes the disabled keyboard problem.

[Andrew Gee (andrewgee)]

I can confirm this bug still exists in karmic. Wish I knew how to fix the bug :)

[Zeppe (giuseppe-passino)]

yeah, it's still there. follow the instructions here to fix it, as I did: http://ubuntuforums.org/showthread.php?t=974723

[molecule-eye (niburu1)]

I can confirm on Karmic as well. I found a simpler workaround was to simply remap the sticky buttons. In my case the volume buttons stuck, so I remapped volume up to "shift + right arrow" and likewise for volume down and mute. Now the the volume control keys don't stick.

[Romano Giannetti (romano-giannetti)]

I think that bug#273745 and bug#288134 are duplicate of this one. I have a U300 too and it happens to me.

Really old one. I will try the fix.

[jetdog (slicksterdave)]

To all developper's attempting to fix this bug:

This problem exists in the __kernel__. Not in evdev. Not in X. Not in Gnome, KDE, or anywhere else.

Quirking the evdev driver does not fix this problem - and your evdev driver AND the kernel will probably be faced with increased CPU time as a result of key-event message passing. What happens is that once the kernel starts spamming the volume up/down key signals to the various kernel/X input handlers (i.e. anything that begins with xf86-input-____), X gets spammed with key events, causing the lockups you're describing.

The reason the kernel spams evdev is quite simple: We have logs earlier in this thread that indicate that the physical hardware implementing the PS/2 protocol on the keyboard do not create a release event for the volume buttons (this wheel produces "down" ticks, but __does_not_always__ produce "up" ticks).

Quirking evdev, as per the solution by ktemkin described in this thread, and on a repeatedly referenced ubuntuforums post, will __not__ stop this increased key-event message passing! It will only cause evdev to ignore the respective key signals from the kernel, but it is an extremely hackish-fix,and your kernel input handling will still be highly clogged! Also, the problem will reoccur if you (or ubuntu official) were ever to switch away from using xf86-input-evdev.

The problem starts WAY earlier than evdev. It (likely) exists in the input/drivers/atkbd.c kernel input driver. What this fix needs is a quirk for the key scancodes that are not producing "release" events, so that the linux kernel can give "keyup" events for evdev, any other xf86-input handlers, and the resulting userspace applications that use these input handlers. Then your volume wheel will work normally.

We need to get some kernel bugfixers in here! I would fix this myself, but real-life work is unfortunately taking the majority of my time.

I hope this will jumpstart a fix -- i know it's rough trying to find someone to get this stuff done!

[ktemkin (kyle-ktemkin)]

I might be able to find time to write a kernel quirk over the holidays; currently I'm up to my eyebrows in work.

Similar quirks exist for other machines already, see this link for a sample:
https://lists.ubuntu.com/archives/kernel-team/2009-April/005480.html

If everyone subscribed and still experiencing this problem could post their DMI_SYS_VENDOR and DMI_PRODUCT_NAME, it'd be helpful.

The patch I offered above for evdev is designed to mask your symptoms; which is useful during the wait- but a better option still would be to, in conjunction, remap the volume up/down keys to another keyboard combo and avoid touching the wheel. Avoiding those keys altogether will minimize the spurious CPU usage until a quirk is done.

Again, my 'fix' is pretty much a crude hack for evdev that filters out the additional events at the X-input level. It will not fix the underlying problem- the kernel.

Good luck, and if anyone wants to try their hand at quirking the kernel, I'm sure you'd have plenty of ready testers. If not, hopefully I'll get to it before too long.

[Andrew Gee (andrewgee)]

Hi ktemkin:

DMI_SYS_VENDOR = "TOSHIBA"
DMI_PRODUCT_NAME = "Satellite U300"

Hope this helps.

[mrvanes (mrvanes)]

Where do I find DMI_SYS_VENDOR and DMI_PRODUCT_NAME?

[jetdog (slicksterdave)]

"Where do I find DMI_SYS_VENDOR and DMI_PRODUCT_NAME?"

Those are part of the Microsoft DMI information, provided by the physical hardware. There is no giant list of which one gets what DMI -- so we just test a few and see if our findings are consistent. It is used for identifying hardware to kernels and software.

(That DMI flag and your scancodes is about all you need to quirk atkbd... and a tiny bit of C =D)

[mrvanes (mrvanes)]

Let me rephrase my question: What command do I run to find out the DMI_SYS_VENDOR and DMI_PRODUCT_NAME of my hardware? I've googled, but just couldn't find any hint leading to the answer.

[Romano Giannetti (romano-giannetti)]

jetdog: there is an open bug in the kernel tracker, maybe it just need a bit of data from people more expert than me. I added the upstream bug, hope I did not do anything wrong.

mrvanes: I have a command "dmidecode" for this. I think the requested data is this one:

(0)rukbat:~% sudo dmidecode | grep -i vendor
 Vendor: TOSHIBA
(0)rukbat:~% sudo dmidecode | grep -i product
 Product Name: Satellite U305
 Product Name: Satellite U305

And by the way, remapping the volume keys solved all the problems for me. Thanks to all.

[jrf2027 (jrf2027)]

My DMI_SYS_VENDOR and DMI_PRODUCT_NAME are the same as Romano's - TOSHIBA and Satellite U305.

[Tomasz Sterna (smoku)]

And mine:

 Vendor: TOSHIBA
 Product Name: Satellite Pro U300

[jetdog (slicksterdave)]

The DMI information gathering is good. Whoever is making a patch will need the whole array of U300 DMI_PRODUCT_NAME (s).

As we've already seen, a U305 has come up. I did some light research and it seems that only the U300 and U305 are in this series.

If anybody has anything in the U300-series that is not a 300/305, please reply so that we can target your DMI info in the patch.

[Nick Moeck (nickmoeck)]

I am assigning this bug to myself, since I am working on a patch for this bug. From what I can gather, all models of the U305 series have the same DMI_PRODUCT_NAME, same with the U300. Since I am completely new to kernel development, this might take me a little while, since I have to learn how to actually do this kind of stuff, but since I am affected by this bug, I want to fix it :) Please bear with me while I learn. My goal is to have this fixed in time for Lucid, but I estimate that I'll be able to get it resolved much sooner than that.

[Aryeh Gregor (simetrical+launchpad)]

The attached patch fixes the problem for my Satellite U305. I copy-pasted the same for Satellite Pro U300 on the assumption that will work too.

[jetdog (slicksterdave)]

Nice! Way to squash those bugs! I can't confirm this myself since I don't have that laptop, but it would be great if we could get somebody from the kernel team to build a test kernel with this.

Then we can get more confirmations from others, and submit to mainline =D

Particularly, it would be great if we could have somebody with at Toshiba U300 to test this.

[Aryeh Gregor (simetrical+launchpad)]

For anyone who's not clear how to test: compile a kernel using the instructions at <https://wiki.ubuntu.com/KernelTeam/GitKernelBuild>, with my patch applied. You'll have to work around bug 498747, for instance by doing "git checkout v2.6.32" to use an older kernel so it compiles cleanly, or by applying the patch given there when (if) the compile process fails for 2.6.33. Compiling the kernel using those instructions took about two hours on my U305 (100 minutes to actually compile and then 20-30 minutes to make the .deb), so make sure you have something else to do. Say here whether or not it helps, and post the output of "sudo dmidecode | grep -e Product -e Vendor".

Also, whether or not you want to test, if anyone is affected by this but "sudo dmidecode | grep Product" does *not* output exactly either "Satellite U305" or "Satellite Pro U300", please say so so that your model can be included in the fix, since it won't be at present.

Finally, thanks to everyone who posted critical info here, particularly jetdog, ktemkin, and the people who posted their DMI info -- I'm a PHP programmer and barely touch C code, so I was basically just copy-pasting to write the patch, and wouldn't have had a clue how to proceed without the exquisitely thorough explanations and pointers given earlier in the thread.

[Zeppe (giuseppe-passino)]

thanks for the attempt, I'll try myself the patch as soon as I manage (I have to free some room in the HD for the kernel compilation, I'm afraid that 3GB aren't enough). However, I suspect that this is not going to work to me since the output of the dmidecode says:

Product Name: Satellite U300

I believe this case can easily be integrated in the patch though.

[Nick Moeck (nickmoeck)]

I have modified the patch to include the Satellite 300. If anyone else has a different Product Name that is affected, please post is here and we will add it to the patch, or feel free to add it to the patch here (it's pretty simple to figure out how to add it).

[Andrew Gee (andrewgee)]

I've just built the kernel with the patch that has the additional "Satellite U300" DMI product. I'm still getting repeating volume keys.

Vendor: TOSHIBA
Product Name: Satellite U300

[Tomasz Sterna (smoku)]

Nick Moeck: your patch is invalid. You need to edit the @ modified section delimiters to have a valid patch.

Aryeh Gregor: I tried applying your patch on linux-image 2.6.31-17-generic but it does not apply: 'atkbd_volume_forced_release_keys' is not in standard kernel. I've fixed it and you will find the 'generic' patch attached.

Nevertheless it does not fix the problem. See the following evtest output:

Event: time 1263755205.200055, type 4 (Misc), code 4 (ScanCode), value 39
Event: time 1263755205.200081, type 1 (Key), code 57 (Space), value 1
Event: time 1263755205.200086, -------------- Report Sync ------------
Event: time 1263755205.260386, type 4 (Misc), code 4 (ScanCode), value 39
Event: time 1263755205.260416, type 1 (Key), code 57 (Space), value 0

Event: time 1263755205.260421, -------------- Report Sync ------------
Event: time 1263755211.503327, type 4 (Misc), code 4 (ScanCode), value b0
Event: time 1263755211.503356, type 1 (Key), code 115 (VolumeUp), value 0
Event: time 1263755211.503361, -------------- Report Sync ------------
Event: time 1263755211.513389, type 4 (Misc), code 4 (ScanCode), value b0
Event: time 1263755211.513416, type 1 (Key), code 115 (VolumeUp), value 1
Event: time 1263755211.513422, -------------- Report Sync ------------
Event: time 1263755211.543370, type 4 (Misc), code 4 (ScanCode), value b0
Event: time 1263755211.543393, type 1 (Key), code 115 (VolumeUp), value 0
Event: time 1263755211.543396, -------------- Report Sync ------------
Event: time 1263755211.553415, type 4 (Misc), code 4 (ScanCode), value b0
Event: time 1263755211.553432, type 1 (Key), code 115 (VolumeUp), value 1
Event: time 1263755211.553435, -------------- Report Sync ------------
Event: time 1263755211.583391, type 4 (Misc), code 4 (ScanCode), value b0
Event: time 1263755211.583405, type 1 (Key), code 115 (VolumeUp), value 0
Event: time 1263755211.583407, -------------- Report Sync ------------
Event: time 1263755211.593480, type 4 (Misc), code 4 (ScanCode), value b0
Event: time 1263755211.593493, type 1 (Key), code 115 (VolumeUp), value 1

First is 'Space' keypress and release. The second is turning the wheel one notch Up.
a) the event is repeated 3 times - looks like the anti-repeat in drivers/input/keyboard/atkbd.c:482 does not work in this case
b) even with atkbd_setup_forced_release quirk the sequence is wrong - this is why I posted Space keypress for reference
VolumeUp key is depressed (0) then pressed (1) three times
This leaves the button in pressed state, causing the "sticking" behavior.

[Tomasz Sterna (smoku)]

The kernel patching method for adding quirks is not relevant for 2.6.32+ kernels.
The forced_release quirk is accessible via sysfs and it's up to HAL/DeviceKit to add proper quirk.
See: http://lists.freedesktop.org/archives/hal/2009-September/013590.html

[Aryeh Gregor (simetrical+launchpad)]

Tomasz: I wrote the patch against 2.6.33-rc4, so I'm not surprised it doesn't apply to an older kernel. To clarify, are you still getting the user-visible symptoms even with the patch? When I tried it, I stopped getting the symptoms (volume indicator maxing out and flickering, keyboard freezing up, etc.). The volume wheel seemed sluggish/jittery, but it behaved much better. I did seem to still be getting similar codes from showkey -s, but I assumed those were somehow not relevant, since it mostly worked.

I'll try out the sysfs thing when I get access to the machine again. Do you know where this sort of change would be added in HAL/DeviceKit? Are there any example patches? 2.6.32 means Lucid, so a quirk would still be needed if we wanted to fix it for Karmic, I guess (maybe not worth it).

[Tomasz Sterna (smoku)]

Yes, I still have the user visible symptoms.
I guess the key-up, key-down sequencing is fixed in 2.6.33, so it works for you.

I'll try getting Lucid kernel and playing with sysfs.

This bug has been sitting in Ubuntu for years now, so I guess Lucid fix is enough.

[Aryeh Gregor (simetrical+launchpad)]

On 2.6.33-rc4 (presumably also 2.6.32), this mostly works:

sudo bash -c 'echo 174,176,`cat /sys/devices/platform/i8042/serio0/force_release` > /sys/devices/platform/i8042/serio0/force_release'

(I figured out 174,176 by binary search. Protip: don't force_release anything in the range 0-127, since that will prevent keycodes like Ctrl-Alt-F1 from working . . . I had to hard-reset my computer.)

The volume control no longer goes crazy when you turn the dial. But it's not a complete fix -- as noted, the dial sends three or four keypresses at once, so this results in the volume jumping instead of increasing smoothly. A quirk probably does need to be added to the kernel after all, which will cut out the duplicate keypresses. I'll look into writing that.

[Tomasz Sterna (smoku)]

http://lists.freedesktop.org/archives/hal/2009-December/013712.html
"Johannes Stezenbach <js at sig21.net> started on adding this fucntionality
to udev."

[Tomasz Sterna (smoku)]

After upgrading to karmic with 2.6.32-10-generic kernel and adding 174,176 to /sys/devices/platform/i8042/serio0/force_release the bug is finally gone. :-D

Bolting it to /etc/rc.local and I'm done. :-) (This is a workaround, not a _proper_ solution, but it works for now.)

[Aryeh Gregor (simetrical+launchpad)]

I took a stab at fixing the "multiple keypresses" thing, but eventually gave up. It doesn't seem worth it -- volume control works okay as-is, and I'm concerned that maybe in some cases it will start emitting only one keypress at a time and break any fix. We just need to wait for userspace support for this quirk detection, I guess? At any rate, now there's a very good workaround with 2.6.32+, it just needs to be applied automatically.

[Bug (bug-redhat-bugs)]

This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11. 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 '11'.

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 11'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 11 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 to the applicable version. 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.

The process we are following is described here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

[MacRules (macrules)]

This bug still affects me on My Mivvy G310 netbook (seems Viooo Corp PT17 model).
Is there an easy way to apply the fix to adress this machine too?
The problem is also that showkey shows no release events for my volume keys.

[Aryeh Gregor (simetrical+launchpad)]

If you're using 2.6.32 or later, you should be able to fidget with the contents of the force_release file in /sys to add the appropriate keycodes. The exact values can be found by experimentation, and you can add something to /etc/rc.local to set it on startup if you like (changes will not persist across startup).

[tasadar_f (tasadarf)]

Wow, I fix it with method 2: http://ubuntuforums.org/showthread.php?t=974723 .

This fix only has a small defect. When I up or down volume move twice as fast.

I use Ubuntu 9.10 in Acer 5630 series.

[Jerone Young (jerone)]

For Volume key issue in 10.04 you can fix simply by adding the following line before LABEL="force_release_end" in /lib/udev/rules.d/95-keyboard-force-release.rules

ENV{DMI_VENDOR}=="TOSHIBA", ATTR{[dmi/id]product_name}=="Satellite U300|Satellite Pro U300", RUN+="keyboard-force-release.sh $devpath common-volume-keys"

Submitting patch upstream...

[Jerone Young (jerone)]

This is a common issue with volume key getting stuck. You have to fix via udev (as this is to no longer go in the kernel).

[Bug (bug-redhat-bugs)]

Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

[Lee Jarratt (lee.jarratt-deactivatedaccount)]

This is also affecting me with my multimedia keys, had the same problem since 7.10 and it's still affecting me with Maverick Meerkat.

[A. Leon (aleon05)]

I switch to Windows long ago

On Thu, Jul 22, 2010 at 8:32 AM, Lee Jarratt <email address hidden> wrote:

> This is also affecting me with my multimedia keys, had the same problem
> since 7.10 and it's still affecting me with Maverick Meerkat.
>
> --
> Toshiba Satellite U300 volume wheel sticking
> https://bugs.launchpad.net/bugs/271706
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in xserver-xorg-input-evdev: Invalid
> Status in The Linux Kernel: Confirmed
> Status in “linux” package in Ubuntu: In Progress
> Status in “linux” package in Fedora: In Progress
> Status in Gentoo Linux: New
>
> Bug description:
> I'm running up-to-date intrepid. I have a volume control wheel on the side
> of my Toshiba U300 laptop. This volume control did work as expected in
> hardy. It operates like a scroll wheel on a mouse, in the way that it has
> specific points at which it sends a signal. When I got to these points on
> hardy, the volume would just increase or decrease by one block.
>
> With intrepid it gets the volume to go up one block, then waits for a
> second and then keep turning the volume up constantly without stopping. I've
> found if I hold a key on the keyboard down, for example Ctrl, it stops it
> temporarily. When I release Ctrl it start zooming off increasing or
> decreasing again. I have found if I swap desktops by holding down Ctrl Alt
> Left or Right, it stops it zooming off increasing or decreasing completely.
>
> I'm sorry if the above was a bit confusing. It's surprisingly hard to
> explain :)
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/evdev/+bug/271706/+subscribe
>

[Natalia Bidart (nataliabidart)]

This is fixed in current udev trunk's keymap tables. This is worth fixing in an SRU.

[Martin (martin-redhat-bugs)]

This was recently fixed in udev:

http://git.kernel.org/?p=linux/hotplug/udev.git;a=commit;h=310f2896eb04b4aa2fe5241f7cf0590852adb2fe

[Martin Pitt (pitti)]

http://git.kernel.org/?p=linux/hotplug/udev.git;a=commit;h=310f2896eb04b4aa2fe5241f7cf0590852adb2fe

[Martin Pitt (pitti)]

Excellent SRU candidate, and Natalie agreed to test this on her laptop once the SRU lands (I already fixed it locally)

[Bastien (bastien-redhat-bugs)]

Thanks for the notice Martin.

[Chuck (chuck-redhat-bugs)]

Fedora kernel maintainers already get copies of all mail for kernel-maint@

[Martin Pitt (pitti)]

As per https://wiki.ubuntu.com/StableReleaseUpdates#udev%20keymaps I uploaded an udev SRU with the latest keymaps. This now needs to be reviewed/ack'ed by an SRU team member.

Natalie, if you test this, please remove the local /etc/udev/rules.d/ workaround that we added during the sprint.

Thanks!

[Launchpad Janitor (janitor)]

This bug was fixed in the package udev - 161+git20100820-1

---------------
udev (161+git20100820-1) maverick; urgency=low

  * New upstream release 161, plus fixes from git head: (LP: #620977)
    - udevadm trigger now defaults to change instead of add.
    - modem modeswitch removed, use usb_modeswitch instead (see LP #521578)
    - NAME= now ignored
    - udevd creates device nodes itself on startup based on modules.udevname
    - default device permission is 0600
    - lots of bug fixes
    - updated keymaps (LP: #271706, #554066, #569815, #592371)
    - update udev(7) to point out naming of rules files (LP: #616108)
    - cdrom_id: fix media state detection of DVD-RW/DVD+RWs (LP: #581925)
    - cdrom_id: fix media state detection on older hardware (LP: #502143)
  * debian/libudev0.symbols: Add new symbols from upstream version.
  * debian/udev.initramfs-hook: Drop 64-device-mapper.rules, it was removed
    upstream.
  * debian/control: Drop obsolete (pre-lucid) Breaks and Conflicts.
  * debian/rules: Replace obsolete dh_clean -k with dh_prep.
  * debian/control: Slightly more generously version libselinux1-dev build
    dependency (thanks lintian).
  * debian/control: Replace obsolete ${Source-Version} with ${binary:Version}.
  * debian/control: Update Standards-Version to 3.9.1.
  * debian/control: Add Homepage field.
 -- Martin Pitt <email address hidden> Sat, 21 Aug 2010 10:07:44 +0200

[Colin Watson (cjwatson)]

Accepted udev into lucid-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

[Andrew Gee (andrewgee)]

I can confirm the proposed udev update for lucid has solved the glitchy volume wheel.

Thanks!

[Launchpad Janitor (janitor)]

This bug was fixed in the package udev - 151-12.1

---------------
udev (151-12.1) lucid-proposed; urgency=low

  * Pull latest keymaps from trunk. These include the following LP bugs:
    - Toshiba Satellite U300 volume keys (LP: #271706)
    - Samsung N220 and many other models (LP: #554066)
    - Acer travelmate 4720 (LP: #569815)
    - Logitech Cordless Wave Pro (LP: #592371)
 -- Martin Pitt <email address hidden> Fri, 20 Aug 2010 15:33:57 +0200

[tasadar_f (tasadarf)]

yesterday I installed Ubuntu 10.04.1 + all updates (include udev update)

I have Acer Aspire 5634 (5630 series), The error persists.

[Fedora (fedora-redhat-bugs)]

udev-145-22.fc12 has been submitted as an update for Fedora 12.
https://admin.fedoraproject.org/updates/udev-145-22.fc12

[Fedora (fedora-redhat-bugs)]

udev-145-22.fc12 has been pushed to the Fedora 12 testing repository. If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with
 su -c 'yum --enablerepo=updates-testing update udev'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/udev-145-22.fc12

[PabloAB (pabloab777)]

I finally solved with the fix of Jerone Young (Comment #95) but with something else, adding "Satellite U305"
which is the output of the command: sudo dmidecode -s system-product-name
So my line is:
 ENV{DMI_VENDOR}=="TOSHIBA", ATTR{[dmi/id]product_name}=="Satellite U300|Satellite Pro U300|Satellite U305", RUN+="keyboard-force-release.sh $devpath common-volume-keys

Before adding a comment please check your keyboard shortcut setup on System>Preferences>Keyboard Shortcuts.

[Schiphol (manolo-austrohungaro)]

Jerome Young's fix also works for the analogous problem with volume keys in the Toshiba Satellite U500, by adding "SATELLITE U500" to the list. That is,

 ENV{DMI_VENDOR}=="TOSHIBA", ATTR{[dmi/id]product_name}=="Satellite U300|Satellite Pro U300|Satellite U305|SATELLITE U500", RUN+="keyboard-force-release.sh $devpath common-volume-keys

Cheers

[Martin Pitt (pitti)]

Schiphol,

The Satellite U500 indeed is still missing, I'm happy to add it upstream. However, are you sure that this works with "SATELLITE"? All other machines seem to advertise themselves as "Satellite".

[Schiphol (manolo-austrohungaro)]

Martin,

Yep, "SATELLITE", all capitals, for some reason. Btw, is there a similar way to recover the rest of media keys -next and previous track, play/pause, etc.?

Thanks
Manolo

[Martin Pitt (pitti)]

Schiphol [2010-10-22 10:07 -0000]:
> Yep, "SATELLITE", all capitals, for some reason.

OK, committed upstream. Thanks!

> Btw, is there a similar way to recover the rest of media keys -next
> and previous track, play/pause, etc.?

Do they also cause the computer to get stuck, or are they not working
at all? Please follow /usr/share/doc/udev/README.keymap.txt.gz and
file a new bug against udev (with "ubuntu-bug udev"). Thanks!

[Schiphol (manolo-austrohungaro)]

> > Btw, is there a similar way to recover the rest of media keys -next
> > and previous track, play/pause, etc.?

> Do they also cause the computer to get stuck, or are they not working
> at all?

The former. Pretty much what the volume keys do.

> Please follow /usr/share/doc/udev/README.keymap.txt.gz and
> file a new bug against udev (with "ubuntu-bug udev"). Thanks!

I will. Thank you!

[Schiphol (manolo-austrohungaro)]

The new bug report is here: https://bugs.launchpad.net/ubuntu/+source/udev/+bug/665918

Thanks again
Manolo

[Bug (bug-redhat-bugs)]

This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12. 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 '12'.

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 12'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 12 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 to the applicable version. 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.

The process we are following is described here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

[Bug (bug-redhat-bugs)]

Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

[Pavel (pavel-redhat-bugs)]

I am afraid this bug is still present in Fedora 13 and will test with Fedora 14.

Cheers,
Pavel

[Karel (karel-redhat-bugs)]

reopening as per comment #27 - please retest

if this was really fixed by the udev-145-22.fc12 update (and there's no regression in newer Fedora) then please close this bug properly, WONTFIX really isn't appropriate for a bug that has been fixed ...

[Bug (bug-redhat-bugs)]

This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13. 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 '13'.

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 13'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 13 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 to the applicable version. 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.

The process we are following is described here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

[Bug (bug-redhat-bugs)]

Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

[Pavel (pavel-redhat-bugs)]

I have just tested it on Fedora 15 and the bug is still present.

[Karel (karel-redhat-bugs)]

(In reply to comment #31)
> I have just tested it on Fedora 15 and the bug is still present.

reopening then

if the patch mentioned in comment #20 doesn't fix the issue then we have a problem ...

please check that you have the appropriate rule in place -

# grep TOSHIBA /lib/udev/rules.d/95-keyboard-force-release.rules

ENV{DMI_VENDOR}=="TOSHIBA", ATTR{[dmi/id]product_name}=="Satellite U300|Satellite Pro U300|Satellite U305|SATELLITE U500", RUN+="keyboard-force-release.sh $devpath common-volume-keys"

and does your model name match one of the product names listed?

[Pavel (pavel-redhat-bugs)]

Thanks for your reply...

grep TOSHIBA /lib/udev/rules.d/95-keyboard-force-release.rules
ENV{DMI_VENDOR}=="TOSHIBA", ATTR{[dmi/id]product_name}=="Satellite U300|Satellite Pro U300|Satellite U305|SATELLITE U500", RUN+="keyboard-force-release.sh $devpath common-volume-keys"

I don't know where is keyboard-force-release.sh

My notebook is Toshiba Satellite u300-13u.

[Martin (martin-redhat-bugs)]

Pavel,

it seems you have a slightly different model than the one that was originally reported here. I now made the name matches more liberal, which sohuld also catch your model:

http://git.kernel.org/?p=linux/hotplug/udev.git;a=commit;h=daa42554ea1f3bc861805a753d2dd07c1c5db743

[Karel (karel-redhat-bugs)]

Pavle, would you mind patching your udev rules with Martin's update to test it?

as for the script, the full path is /lib/udev/keyboard-force-release.sh and it is included in udev package

[Pavel (pavel-redhat-bugs)]

I hand-applied the patch. Is there any other way to test it than reboot?

[Martin (martin-redhat-bugs)]

Yes, you can run

  udevadm trigger --subsystem-match=input

as root.

[Pavel (pavel-redhat-bugs)]

The patch did *not* help.

[Pavel (pavel-redhat-bugs)]

Created attachment 510827
/sys/devices/virtual/dmi/id/

This archive contains my /sys/devices/virtual/dmi/id/. I hope it helps.

[Martin (martin-redhat-bugs)]

Pavel,

something seems to have gone wrong there:

$ cat product_version
��������������������������������

can you please give me the output of

  cat /sys/class/dmi/id/product_name

? Does it say something reasonable like "Satellite u300" or just the broken garbage that your tarball has?

[Pavel (pavel-redhat-bugs)]

Martin,

it is as broken as you see it in the tarball. Binary garbage full of FF bytes.

[Martin (martin-redhat-bugs)]

Pavel,

thanks for checking. I'm afraid there's no generic way to fix this in the rules then :/

You can fix it locally by creating a file /etc/udev/rules.d/95-keyboard.rules with

--------------------- 8< ------------------
ACTION=="remove", GOTO="force_release_end"
SUBSYSTEM!="serio", GOTO="force_release_end"
KERNEL!="serio*", GOTO="force_release_end"
DRIVER!="atkbd", GOTO="force_release_end"
ENV{DMI_VENDOR}="$attr{[dmi/id]sys_vendor}"
ENV{DMI_VENDOR}=="TOSHIBA", RUN+="keyboard-force-release.sh $devpath common-volume-keys"
--------------------- 8< ------------------

[Martin (martin-redhat-bugs)]

Whoops, sorry. You need to append a line

LABEL="force_release_end"

[Pavel (pavel-redhat-bugs)]

Trying:

# cat /etc/udev/rules.d/95-keyboard.rules
ACTION=="remove", GOTO="force_release_end"
SUBSYSTEM!="serio", GOTO="force_release_end"
KERNEL!="serio*", GOTO="force_release_end"
DRIVER!="atkbd", GOTO="force_release_end"
ENV{DMI_VENDOR}="$attr{[dmi/id]sys_vendor}"
ENV{DMI_VENDOR}=="TOSHIBA", RUN+="keyboard-force-release.sh $devpath common-volume-keys"
LABEL="force_release_end"

It did not help. Unfortunately I don't understand it enough to debug.

I've been using fedora for a long time and I learned not to touch the wheel. But I'm still very curious about fixing this. To learn a bit more about udev, if not for anything else.

[Pavel (pavel-redhat-bugs)]

For me, gnome-shell doesn't get confused anymore. Maybe because of the fix above, maybe not, I don't actually know. I'll test on a fresh F16 install when it's out.

[Fedora (fedora-redhat-bugs)]

This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.

[Fedora (fedora-redhat-bugs)]

This message is a notice that Fedora 15 is now at end of life. Fedora
has stopped maintaining and issuing updates for Fedora 15. It is
Fedora's policy to close all bug reports from releases that are no
longer maintained. At this time, all open bugs with a Fedora 'version'
of '15' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that
we were unable to fix it before Fedora 15 reached 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, you are encouraged to click on
"Clone This Bug" (top right of this page) and open it against that
version of Fedora.

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.

The process we are following is described here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping