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

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

[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

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

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

[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

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

[Martin (martin-redhat-bugs)]

This was recently fixed in udev:

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

[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@

[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

[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