Toshiba Satellite U300 volume wheel sticking
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Linux |
Fix Released
|
Medium
|
|||
xserver-xorg-input-evdev |
Invalid
|
Undecided
|
Unassigned | ||
Gentoo Linux |
New
|
Undecided
|
Unassigned | ||
linux (Fedora) |
Won't Fix
|
Low
|
|||
udev (Ubuntu) |
Fix Released
|
High
|
Martin Pitt | ||
Lucid |
Fix Released
|
Medium
|
Martin Pitt | ||
Maverick |
Fix Released
|
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 :)
Changed in linux: | |
status: | Unknown → In Progress |
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 |
Changed in linux: | |
status: | Unknown → Confirmed |
Changed in evdev: | |
status: | New → Invalid |
Changed in linux (Ubuntu): | |
assignee: | ktemkin (kyle-ktemkin) → Nick Moeck (nmoeck) |
Changed in linux (Ubuntu): | |
assignee: | Nick Moeck (nmoeck) → nobody |
tags: | added: patch |
affects: | linux (Ubuntu) → udev (Ubuntu) |
Changed in udev (Ubuntu): | |
assignee: | nobody → Martin Pitt (pitti) |
importance: | Undecided → High |
Changed in udev (Ubuntu Maverick): | |
status: | In Progress → Fix Committed |
Changed in udev (Ubuntu Lucid): | |
assignee: | nobody → Martin Pitt (pitti) |
importance: | Undecided → Medium |
status: | New → In Progress |
Changed in udev (Ubuntu Lucid): | |
status: | In Progress → Fix Committed |
Changed in udev (Ubuntu Maverick): | |
status: | Fix Committed → Fix Released |
tags: | added: verification-needed |
tags: |
added: verification-done removed: verification-needed |
Changed in udev (Ubuntu Lucid): | |
status: | Fix Committed → Fix Released |
Changed in linux: | |
status: | Confirmed → Fix Released |
Changed in linux: | |
importance: | Unknown → Medium |
Changed in linux (Fedora): | |
importance: | Unknown → Low |
status: | In Progress → Won't Fix |
yep, same problem. we never get a key up event, resulting in endless key repeats
by the server.
(In reply to comment #8) lists.freedeskt op.org/ archives/ xorg/2008- June/036634. html
> (In reply to comment #7)
> > sounds like http://
>
> 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.