Bug 10300
| Summary: | volume wheel does not work in 2.6.25-rc6 | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | Romano Giannetti (romano.giannetti) |
| Component: | Input Devices | Assignee: | drivers_input-devices |
| Status: | CLOSED CODE_FIX | ||
| Severity: | normal | CC: | aklitzing, florian, jetdog330, martin.pitt, rasasi78, rjw, s.jansen, tiwai |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 2.6.27-rc8 | Subsystem: | |
| Regression: | Yes | Bisected commit-id: | |
| Bug Depends on: | |||
| Bug Blocks: | 9832, 56331 | ||
| Attachments: |
Using the wheel up and down
config diff between 2.6.24.4 and 2.6.25 evtest output for keyboard. |
||
|
Description
Romano Giannetti
2008-03-21 11:42:44 UTC
AFAIK, no change in ALSA side regarding the volume wheel control since 2.6.24. Please verify if it's a duplicate of bug #10294 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. any chance you can bisect this to the offending commit? 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... 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? 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. :) 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. Changed to ALSA due to comment #6 and comment #7. -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... The problem is present in 2.6.25-rc8-git7. References : http://lkml.org/lkml/2008/4/9/94 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.
Created attachment 15771 [details]
Using the wheel up and down
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.
Confirmed to be present in 2.6.25-rc9. References : http://lkml.org/lkml/2008/4/14/57 And I confirm here that nothing changed for the final 2.6.25 release. And did you find anything with your bisection? ... 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... 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 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? > 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. Created attachment 15801 [details]
config diff between 2.6.24.4 and 2.6.25
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? 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. 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. 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, Created attachment 16004 [details] evtest output for keyboard. More info on http://bugs.freedesktop.org/show_bug.cgi?id=13511 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... 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, 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). 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. Still here with 2.6.26-rc9 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. Still here in 2.6.27 (Arch Linux) 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 (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. I can't remember if I've changed anything else besides enabling the powersaving mode for the AC97 chip. 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 BTW, I do not think this is sound-related. 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 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 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 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 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. |