Toshiba Satellite U300 volume wheel sticking

Bug #271706 reported by Andrew Gee on 2008-09-18
214
This bug affects 30 people
Affects Status Importance Assigned to Milestone
Linux
Fix Released
Medium
xserver-xorg-input-evdev
Invalid
Undecided
Unassigned
Gentoo Linux
New
Undecided
Unassigned
linux (Fedora)
In Progress
Unknown
udev (Ubuntu)
High
Martin Pitt
Declined for Intrepid by Martin Pitt
Declined for Jaunty by Martin Pitt
Lucid
Medium
Martin Pitt
Maverick
High
Martin Pitt

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 :)

Mackenzie Morgan (maco.m) wrote :

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) wrote :

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) wrote :

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

Tomasz Sterna (smoku) wrote :

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) wrote :

Provided detailed information and proposed solution.

Changed in xorg:
status: Incomplete → New
Timo Aaltonen (tjaalton) wrote :

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.

Changed in xorg:
status: New → Confirmed
Changed in linux:
status: Unknown → In Progress
Josh (theformerprophet) wrote :

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) wrote :

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) wrote :

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) wrote :

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

plindeman (peter-lindeman-nl) wrote :

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) wrote :

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

Ztrange (ztrange) wrote :

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

AaronMT (aaron-train) wrote :

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

MAcks (xmacn-konto) wrote :

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.

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 ?

jrf2027 (jrf2027) wrote :

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

Zeppe (giuseppe-passino) wrote :

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

1 comments hidden view all 114 comments
Ben Schaffhausen (bhs128) wrote :

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) wrote :

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) wrote :

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) wrote :

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.

Dave in Berkeley (daweick) wrote :

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

drewp (drewp) wrote :

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) wrote :

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)

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) wrote :

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) wrote :

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) wrote :

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

Taner Senyurt (turshu) wrote :

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

ktemkin (kyle-ktemkin) wrote :

@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) wrote :

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

A. Leon (aleon05) wrote :

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

jetdog (slicksterdave) wrote :
Download full text (3.4 KiB)

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...

Read more...

ktemkin (kyle-ktemkin) wrote :

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):
assignee: nobody → ktemkin (kyle-ktemkin)
status: Confirmed → In Progress
Download full text (3.9 KiB)

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...

Read more...

jetdog (slicksterdave) wrote :

@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) on 2009-06-12
summary: - Volume control wheel on laptop is sticking in ubuntu
+ Toshiba Satellite U300 volume wheel sticking
Changed in linux (Fedora):
status: In Progress → Won't Fix
Changed in linux (Fedora):
status: Won't Fix → In Progress
34 comments hidden view all 114 comments
Tomasz Sterna (smoku) wrote :

And mine:

 Vendor: TOSHIBA
 Product Name: Satellite Pro U300

Changed in linux:
status: Unknown → Confirmed
jetdog (slicksterdave) on 2009-11-23
Changed in evdev:
status: New → Invalid
jetdog (slicksterdave) wrote :

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) wrote :

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.

Changed in linux (Ubuntu):
assignee: ktemkin (kyle-ktemkin) → Nick Moeck (nmoeck)

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) wrote :

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.

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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

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) wrote :

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.

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) wrote :

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) wrote :

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.)

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.

Nick Moeck (nickmoeck) on 2010-01-29
Changed in linux (Ubuntu):
assignee: Nick Moeck (nmoeck) → nobody
MacRules (macrules) wrote :

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.

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) wrote :

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.

tags: added: patch
Jerone Young (jerone) wrote :

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) wrote :

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).

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.

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) wrote :

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

affects: linux (Ubuntu) → udev (Ubuntu)
Changed in udev (Ubuntu):
assignee: nobody → Martin Pitt (pitti)
importance: Undecided → High
Martin Pitt (pitti) wrote :
Changed in udev (Ubuntu Maverick):
status: In Progress → Fix Committed
Martin Pitt (pitti) wrote :

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

Changed in udev (Ubuntu Lucid):
assignee: nobody → Martin Pitt (pitti)
importance: Undecided → Medium
status: New → In Progress
Martin Pitt (pitti) wrote :

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!

Changed in udev (Ubuntu Lucid):
status: In Progress → Fix Committed
Launchpad Janitor (janitor) wrote :

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

Changed in udev (Ubuntu Maverick):
status: Fix Committed → Fix Released

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!

tags: added: verification-needed
Andrew Gee (andrewgee) wrote :

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

Thanks!

Martin Pitt (pitti) on 2010-08-27
tags: added: verification-done
removed: verification-needed
Launchpad Janitor (janitor) wrote :

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

Changed in udev (Ubuntu Lucid):
status: Fix Committed → Fix Released
tasadar_f (tasadarf) wrote :

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

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

PabloAB (pabloab777) wrote :

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.

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) wrote :

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".

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

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!

> > 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!

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

Thanks again
Manolo

Changed in linux:
status: Confirmed → Fix Released
Changed in linux:
importance: Unknown → Medium
Displaying first 40 and last 40 comments. View all 114 comments or add a comment.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.