Bug 10300 - volume wheel does not work in 2.6.25-rc6
volume wheel does not work in 2.6.25-rc6
Status: CLOSED CODE_FIX
Product: Drivers
Classification: Unclassified
Component: Input Devices
All Linux
: P1 normal
Assigned To: drivers_input-devices
:
Depends on:
Blocks: 9832 56331
  Show dependency treegraph
 
Reported: 2008-03-21 11:42 UTC by Romano Giannetti
Modified: 2013-04-09 06:23 UTC (History)
8 users (show)

See Also:
Kernel Version: 2.6.27-rc8
Tree: Mainline
Regression: Yes


Attachments
Using the wheel up and down (136.45 KB, application/x-compressed-tar)
2008-04-16 06:15 UTC, Romano Giannetti
Details
config diff between 2.6.24.4 and 2.6.25 (27.50 KB, text/plain)
2008-04-18 07:04 UTC, Romano Giannetti
Details
evtest output for keyboard. (10.23 KB, text/plain)
2008-05-01 16:57 UTC, Raúl
Details

Description Romano Giannetti 2008-03-21 11:42:44 UTC
Latest working kernel version:2.6.24.2
Earliest failing kernel version:unknown
Distribution:ubuntu 7.10
Hardware Environment:toshiba laptop U305, sound hda-intel, realtek 268 codec
Software Environment:
Problem Description:

Volume wheel events in 2.6.24 started to be handled by ACPI directly (no events to the S.O., I have a toshiba OSD appers when using it). Now it seems that there is no agreement bewteen alsa and the ACPI control. Moving the wheel changes PCM volume (not master), sometime the two channels (left-right), sometime just one channel, sometime none, and each time in a seemingly random way.


Steps to reproduce: move the volume wheel. I marked this low priorty because I use it very rarely (and if I only could map it to the mouse events 5 an 6 t would be much more useful than to control the volume).

acpidump, alsa info, etc are available 
at http://www.dea.icai.upcomillas.es/romano/linux/info/
Comment 1 Takashi Iwai 2008-03-22 09:49:22 UTC
AFAIK, no change in ALSA side regarding the volume wheel control since 2.6.24.
Comment 2 Zhang Rui 2008-03-23 22:59:39 UTC
Please verify if it's a duplicate of bug #10294
Comment 3 Romano Giannetti 2008-03-24 02:15:50 UTC
I don't think. I have sound after resume all right (modulo a lot of noise in mic), it's just the volume wheel that's acting crazy. 
To resume, with ubuntu stock kernel, the wheel is managed by gnome (I have the gnome slider appearing). Since 2.6.24, it changed to be managed by I-don't-know-what (I have an OSD slider that seems bios-managed), and it worked. In 2.6.25-rc, it's like in .24, but it's not working any more.
Not a big problem, really.

Comment 4 Len Brown 2008-03-26 23:24:45 UTC
any chance you can bisect this to the offending commit?
Comment 5 Romano Giannetti 2008-03-28 00:22:47 UTC
Will try to see if I have time over the week end, but I can't promise it. Deadline time for a lot of things here...
Comment 6 Romano Giannetti 2008-03-28 04:03:36 UTC
Hmm. Booted -rc7 and made some more tests. I suspect it's not an ACPI fault.
The reason is that I have a strange behavior by changing PCM levels *also* in the gnome mixer. It's difficult to explain, but I try: 

I open the mixer. PCM is at about 70%, Left and Right linked. I move the slider down, and both go down; when reaching zero, L&R unlink and now the levels goes independently, and quite erratically (they jumps up and down when I try to move them, they unlink spontaneously when I link them and try to move, etc). 

Takashi, could be an alsa-lib/alsa-kernel mismatch? How can I check? 

Comment 7 Zhang Rui 2008-04-02 01:47:46 UTC
Hmm, I'm not familiar with the ALSA thing and I have no idea on how to debug this problem.
As it's a regression, it would be great if you can do a git bisect to find out the buggy commit.
Or you can re-assign it to the proper categary. :)
Comment 8 Romano Giannetti 2008-04-02 01:55:59 UTC
Hmmm, it would be a very long and painful bisection. The problem is, sound is working very bad with anything prior to 2.6.25-rc1, so that I have to install alsa 1.0.16 on top of 2.6.24 to have sound working decently. On my laptop, a bisect run means at least 40 minutes, so I do not know if I can find the time to bisect it. 

I will try to re-assign it to sound.

Thanks anyway. 
 

 
Comment 9 Romano Giannetti 2008-04-02 01:58:04 UTC
Changed to ALSA due to comment #6 and comment #7.
Comment 10 Romano Giannetti 2008-04-04 12:07:00 UTC
-rc8 did not fix the issue.
I have a .MOV showing the problem, but it's too big to paste here; if anyone is interested, I can manage to put it on a web server fo a short time...
Comment 11 Rafael J. Wysocki 2008-04-09 14:03:19 UTC
The problem is present in 2.6.25-rc8-git7.

References : http://lkml.org/lkml/2008/4/9/94
Comment 12 Takashi Iwai 2008-04-16 02:56:21 UTC
Sorry for the late response as I've been on a long vacation.

It's really weird about the volume behavior of gnome mixer.  I don't think it's about alsa-kernel/lib mismatch, though.
Anyway, please check the raw mixer (control) values via running
    alsactl -f somefile store
at each volume change.  Then you see which element was really changed how much.
Comment 13 Romano Giannetti 2008-04-16 06:15:10 UTC
Created attachment 15771 [details]
Using the wheel up and down
Comment 14 Romano Giannetti 2008-04-16 06:24:06 UTC
Takashi,

I did what you suggested. I started the laptop (resuming from suspend to ram, but the behaviour is more or less the same), opened the gnome volume control and take a screenshot of it, and immediately after I took a "alsactl -f start_state.txt store" data.
After that, I gave the volume wheel a "shot" down. The result is in one_jot_down.{txt,jpg}. Notice the status assumed by the PCM control. The channels went unjoined, and after that whatever thing I do with the wheel they stayed so. 
You have more data, with 5 more shots down, then 4 up, then 6 more up. Whatever I do, the volumes of the PCM never went back to maximum. They go up and down in an apparently random way, sometime going up, sometime down, every time I use the wheel. 
The only way to have the two (left and right)controls to the max togheter is to put them there, independently, with the mouse, and then joining them. 
After that, with the mouse all is ok, but if I hit the "zero" value, they unjoin again, and I have to rejoin the two channel manually. 
Comment 15 Rafael J. Wysocki 2008-04-17 13:38:28 UTC
Confirmed to be present in 2.6.25-rc9.

References : http://lkml.org/lkml/2008/4/14/57
Comment 16 Romano Giannetti 2008-04-18 03:58:18 UTC
And I confirm here that nothing changed for the final 2.6.25 release.
Comment 17 Takashi Iwai 2008-04-18 04:04:02 UTC
And did you find anything with your bisection?
Comment 18 Takashi Iwai 2008-04-18 05:52:09 UTC
... and the funny thing is that PCM volume is a user-defined mixer element that alsa-lib creates in your case.  That isn't controlled directly by the driver at all.  It's just GNOME that drives it crazy.

So, it really looks irrelevant with the kernel update...
Comment 19 Romano Giannetti 2008-04-18 06:12:07 UTC
So, it could be easily an user-space problem. Can I test it 
in some way? 

Bisection: really I had not time to do it, sorry. I know it's only me
that can do it, but I'm in a very busy period at work, and I had to use
all the time I can to do real work. 

And no, I do not have a machine that make a kernel compile in minutes.
It's about 20 minutes per cycle to me, especially if EXTRAVERSION change
over an iteration. Nevertheless, I will try to do it. 

Thanks a lot anyway for the attention and time spent on this (quite
marginal) thing.

Romano 
Comment 20 Takashi Iwai 2008-04-18 06:23:49 UTC
After seeing that PCM is a user-defined element, now I guess that bisect wouldn't show you any useful point.  So, don't worry about that, you saved your time :)

The question is rather what got broken.  Do you have any idea what you changed except for kernel that may trigger this problem?
Comment 21 Romano Giannetti 2008-04-18 06:57:11 UTC
> After seeing that PCM is a user-defined element, now I guess that bisect
> wouldn't show you any useful point.  So, don't worry about that, you saved your
> time :)

I don't know if it's so true, unfortunately... I have two kernels to
choose:

1) 2.6.24.4 + alsa-driver 1.0.16 (otherwise mics do not work, see
https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3824 )  

2) 2.6.25 (current) 

Without changing userspace, in (1) the volume wheel works, and in (2) 
I have the described problem. So maybe it's a userspace bug, but it's
triggered by a kernel change... unless it's some subtle config change. I
will add the configs diff to this bug shortly.


Comment 22 Romano Giannetti 2008-04-18 07:04:15 UTC
Created attachment 15801 [details]
config diff between 2.6.24.4 and 2.6.25
Comment 23 Takashi Iwai 2008-04-18 07:14:47 UTC
Hm, that's puzzling.  To me it's not clear whether the problem appears always.  Doesn't the volume wheel work before suspend?  And what about the GNOME mixer problem?

Also, does alsamixer show the same problem after suspend?
Comment 24 Sander Jansen 2008-04-18 13:52:26 UTC
I also have a Toshiba U305(-S7446). Having the volume wheel mapped to the gnome mixer, always results in the volume always going way down, or way up. Using 'showkey' in the console, I can see that turning the wheel results in one extra key press event after stop turning the wheel:

keycode 115 press
keycode 115 release
keycode 115 press
keycode 115 release
keycode 115 press   

Then when you start turning it again:

keycode 115 release
keycode 115 press
keycode 115 release
keycode 115 press
keycode 115 release
keycode 115 press

This is with Kernel 2.6.24 on Arch Linux.



Comment 25 Romano Giannetti 2008-04-21 03:21:56 UTC
So it could be an input layer problem?
In console, using showkey, every time I move the wheel up I have a line
with:

0xf3 0x73 0xf3 0x73 0xf3 0x73

and every time I roll it "down":

0xf2 0x72 0xf2 0x72 0xf2 0x72

In X11, using xev, no key is reported; using the wheel I have the
erratic behaviour described but no key event.
Comment 26 Raúl 2008-05-01 16:52:36 UTC
Same problem here on a Toshiba Satellite U300-13H laptop. Tested on several 2.6.24 versions and 2.6.25 currently. On console I get almost the same output that Romano (with different scan codes). On X I have the same problem and is that when I stop rolling the wheel, last event received is a key down. Some times the first event when I start rolling is key down.

Also mind that rolling very little translates to a certain amount of key up/down events, where I would expect just one. This means that I am unable to get just a single key down/up sequence.

I'm attaching the evtest output for the situation.

Regards,
Comment 27 Raúl 2008-05-01 16:57:22 UTC
Created attachment 16004 [details]
evtest output for keyboard.

More info on http://bugs.freedesktop.org/show_bug.cgi?id=13511
Comment 28 Romano Giannetti 2008-05-07 00:50:21 UTC
Good news...
Volume wheel works ok here with 2.6.26-rc1-110-ga153063. No idea what could have resurrected it. If someone want that I check one or two commit, I'll do it; I do not have time at hands now to do a full bisect...
Comment 29 Raúl 2008-05-07 23:40:56 UTC
Thanks for your testing Romano.

It looks like commit eb08b6b973cb91311431c6eea3cc232b97152a84 on evdev.c have been to blame(for the fix).

I'll try to backport it to 2.6.25.2 and I'll report back as well.

Regards,
Comment 30 Anonymous Emailer 2008-05-09 00:21:10 UTC
Reply-To: romano@dea.icai.upcomillas.es


(I'm romano. different email. stupid firewall.)

On Wed, 2008-05-07 at 23:40 -0700, bugme-daemon@bugzilla.kernel.org
wrote:

> It looks like commit eb08b6b973cb91311431c6eea3cc232b97152a84 on evdev.c have
> been to blame(for the fix).
> 
> I'll try to backport it to 2.6.25.2 and I'll report back as well.

Nope. I tried to add it to 2.6.25.1 and the wheel bug is still present,
so the blame is not for it (at least, not only).


Comment 31 Romano Giannetti 2008-05-20 04:21:26 UTC
Correction: 2.6.26-rc3 *still* has the bug. I do not know what happened with 
the 2.6.26-rc2, maybe a glitch. Or maybe this is suspend/resume related...  will test.

Comment 32 Romano Giannetti 2008-07-07 03:09:30 UTC
Still here with 2.6.26-rc9
Comment 33 Romano Giannetti 2008-09-23 04:34:18 UTC
Still here with 2.6.27-rc6. Sad, because 2.6.27 otoh runs my laptop pretty well, but hey, it's not such a big bug.

I should have the courage to reinstall it from scratch, $DEITY only knows what the status of the system after three upgrades can be... but not time at the moment.

Comment 34 Sander Jansen 2008-10-16 20:46:33 UTC
Still here in 2.6.27 (Arch Linux)
Comment 35 Tiago Pierezan Camargo 2008-10-17 00:49:11 UTC
Gone here. An Arch Linux box with 2.6.27. I've changed my sound configuration recently (have gave oss4 a try). Maybe something I've done during the rollback to alsa helped to solve the problem. 

Driver: snd-intel8x0
Comment 36 Sander Jansen 2008-10-17 07:29:57 UTC
(In reply to comment #35)
> Gone here. An Arch Linux box with 2.6.27. I've changed my sound configuration
> recently (have gave oss4 a try). Maybe something I've done during the rollback
> to alsa helped to solve the problem. 
> 
> Driver: snd-intel8x0
> 

I'm not sure if ALSA is involved in this. My volume wheel has never been used directly by ALSA as far as I know, and I had to bind the keys directly to the gnome-mixer to adjust the volume.

It seems more like a input-layer problem to me. I'm always getting a key press as the last event instead of a key release when I turn the volume wheel. 
Comment 37 Tiago Pierezan Camargo 2008-10-17 07:39:32 UTC
I can't remember if I've changed anything else besides enabling the powersaving mode for the AC97 chip.
Comment 38 Romano Giannetti 2008-11-03 00:45:27 UTC
ANy news form this? The fact that the wheel sends release event before press events greatly confuses the new X.org (Ubuntu Intrepid Ibex is completely mess up by it, see for example 

https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-keyboard/+bug/273745

Comment 39 Romano Giannetti 2008-11-03 00:45:58 UTC
BTW, I do not think this is sound-related. 
Comment 40 Raúl 2008-12-14 15:43:27 UTC
Still alive on 2.6.27.8. I'd like to add that doing some tests with esekeyd test utility keytest I found out that each wheel "movement" means 3 button events in a row. For instance, I got this moving the wheel down just a little bit:

#keytest
keytest (ESE Key Deamon 1.2.5)

(input device name as 1st option override autodetection)

Pres ANY (fun)key... or Ctrl-C to exit...

VOLUMEDOWN VOLUMEDOWN VOLUMEDOWN


HTH
Comment 41 Dave Andrews 2009-11-23 03:13:49 UTC
Hello!  Some recent developments on this bug in ubuntu/launchpad!

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/271706

We're getting the same problem with you, as well as the strange sequence reported earlier:

"I can see that turning the wheel results in one extra
key press event after stop turning the wheel:

keycode 115 press
keycode 115 release
keycode 115 press
keycode 115 release
keycode 115 press   

Then when you start turning it again:

keycode 115 release
keycode 115 press
keycode 115 release
keycode 115 press
keycode 115 release
keycode 115 press
"

Also, we have a showkey log running from console.  It seems that it's starting in the keyboard input drivers, way before evdev.

http://launchpadlibrarian.net/27809229/mykeylog-U300.txt

Someone will have to write a quirk for input/keyboard/atkbd.c

This is a fairly straightforward fix and we still have a fair number of users with this laptop.  The only weird thing I can think of is whether there is an issue since this device is producing the needed release key some of the time.

Will quirking atkbd.c for this DMI possibly result in the kernel producing __TWO__ volume key release events when the hardware produces a "press"? (i.e. one for software-quirked/forced key release, one for the inconsistent normal hardware-originating releases seen above?)

Maybe only one way to find out! xD
Comment 42 Florian Mickler 2010-04-28 09:10:27 UTC
Hello Romano!
First of all: is this bug still present for you?

(In reply to comment #25)
> So it could be an input layer problem?
> In console, using showkey, every time I move the wheel up I have a line
> with:
> 
> 0xf3 0x73 0xf3 0x73 0xf3 0x73
> 
> and every time I roll it "down":
> 
> 0xf2 0x72 0xf2 0x72 0xf2 0x72

on a kernel >=v2.6.32 please try to set up the force_release keymap as described in commit http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;h=1ba36e11b227e32f818aea5b4d84f5cbff71e7db :

echo 114,115 > /sys/bus/serio/drivers/atkbd/serio*/force_release

and check if this fixes your problem.

(my assumption beeing, that you keys only get released at the next button press)

If this does fix it, you need to upgrade the userspace component which usually does fix this up for your kind of setup, and open a bug against it, if it doesn't fix it.

I don't know exactly who set's this kind of quirks up these days.. one of hal, devicekit, somethingorotherkit or udev...

cheers,
Flo
Comment 43 Romano Giannetti 2010-04-29 16:35:09 UTC
Florian:
I do not know. I have disabled the wheel ages ago (tired to have to fight with this), and to be honest I really do not remember how (it was something gnome-related). 
If I discover how to reenable it, I will test. 
Thanks
Comment 44 Martin Pitt 2010-07-23 12:38:01 UTC
This was recently fixed in udev:

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

You can close this bug report on the kernel side.

Note You need to log in before you can comment on or make changes to this bug.