On Saturday 16 June 2018 09:05:41 Takashi Iwai wrote: > On Fri, 15 Jun 2018 21:09:59 +0200, > Pali Rohár wrote: > > > > On Friday 15 June 2018 14:51:47 Takashi Iwai wrote: > > > On Fri, 08 Jun 2018 13:10:57 +0200, > > > Pali Rohár wrote: > > > > > > > > Hi! With up-to-date thinkpad_acpi.ko driver on ThinkPad T480s I'm seeing > > > > a strange behavior of LEDs which are integrated into mic mute (Fn+F4) > > > > and mute (Fn+F1) keys. > > > > > > > > When thinkpad_acpi.ko is not loaded, then mute key is working fine. When > > > > pressed, it correctly generates KEY_MUTE on AT Translated Set 2 keyboard > > > > input device and also turn on/of mute led. But when micmute key is > > > > pressed then, nothing happen. No key event is reported and also led is > > > > not turned on/off. > > > > > > > > On the other hand, when thinkpad_acpi.ko is loaded, then both buttons > > > > mute and micmute correctly generates input events; mute via AT keyboard > > > > and micmute via ThinkPad Extra Buttons. But led is not changed. When > > > > thinkpad_acpi.ko is loaded it turn off both leds (mute and micmute) and > > > > leds after pressing any of those buttons, leds are not turned on again. > > > > > > > > When thinkpad_acpi.ko is unloaded, then pressing mute button again start > > > > switching led on/off. > > > > > > > > So it seems that some init sequence of thinkpad_acpi.ko breaks mute led. > > > > And fini sequence of thinkpad_acpi.ko makes mute led working again. > > > > > > Usually the mute LED on Thinkpad is triggered from HD-audio driver > > > (sound/pci/hda/thinkpad_helper.c), and it's a soft-bound via > > > symbol_request(tpacpi_led_set). I thought thinkpad_acpi is > > > auto-loaded when the module gets bound. > > > > > > A possible explanation would be that TPT480s has neither IBM0068, > > > LEN0068 nor LEN0268 ACPI HIDs, hence the driver is not auto-loaded. > > > > I have Debian Stretch kernel (4.9) which does not have LEN0268 alias for > > thinkpad_acpi.ko. So thinkpad_acpi.ko is not loaded automatically. But I > > have put thinkpad_acpi into /etc/modules and it is now automatically > > loaded at boot. > > That's odd. It's exposed via > MODULE_DEVICE_TABLE(acpi, ibm_htk_device_ids); > > It's been already in 4.9. At this point, something is fishy. $ /sbin/modinfo thinkpad_acpi | grep alias alias: dmi:bvnIBM:bvrI[MU]ET??WW* alias: tpacpi alias: acpi*:LEN0068:* alias: acpi*:IBM0068:* No there is no LEN0268 on 4.9. > > I also compiled upstream version of thinkpad_acpi.ko, loaded it in > > Stretch kernel, but it behaves in same way. > > > > Maybe... there could be a problem that thinkpad_acpi.ko must be already > > loaded when sound subsystem is doing initialization? If yes, this could > > explain it as /etc/modules is loaded at later stage and manually loading > > of new version of thinkpad_acpi.ko at runtime does not help when sound > > subsystem is already running. > > Not really. The HD-audio driver tries to bind with tpacpi_led_set() > via symbol_request(). i.e. if it's not present, it tries to load a > module. > > Check whether hda_fixup_thinkpad_acpi() is called and the symbol gets > loaded or not. > > But, I don't think it's worth to debug such an old kernel primarily. It is default one used by the last released Debian stable version. > Could you test the latest Linus tree or 4.17.x at least as a test > basis? Ok, will do that later. > > > (In HD-audio driver side, the ACPI ID is checked and the mute LED > > > control is applied only to these three IDs, too.) > > > Meanwhile, when you load thinkpad_acpi, it does still recognize some > > > device and initialize it. By the initialization, it goes out of BIOS > > > control, and the OS control is expected... This is my wild guess. > > > > > > > > > BTW, the reason we have no LED class for these is that we don't want > > > to confuse users by providing multiple ways to access to the single > > > stuff. We've had already the mute LED control from the audio driver > > > since long time ago, we don't want to drop and enforce the user-space > > > solution (that is anyway flakier than in kernel in most cases). > > > > If possible... I would prefer swapped LED behavior: turn led on when > > microphone is turned on AND turn led off when microphone is turned off. > > Because current behavior is to have turned led off when microphone is > > on which seems a bit strange. Also microphone is in majority of time not > > used and when is not used it is (or should be) turned off. On the other > > hand e.g. CAPSLOCK led is turned on when CAPSLOCK is enabled (and not > > opposite) -- which matches uses, it is not used in majority of time. > > Currently the mixer control to change such LED behavior is provided > only for Dell laptops. It'd be trivial to port to Thinkpad, though. > I can provide a patch once after you test with the recent kernels. > > > thanks, > > Takashi -- Pali Rohár pali.rohar@xxxxxxxxx
Attachment:
signature.asc
Description: PGP signature
