[Bug 308191] New: hotkey-setup:thinkpad-keys is needlessly/ too often hogging cpu
https://bugzilla.novell.com/show_bug.cgi?id=308191 Summary: hotkey-setup:thinkpad-keys is needlessly/too often hogging cpu Product: openSUSE 10.3 Version: Beta 3 Platform: i386 OS/Version: openSUSE 10.3 Status: NEW Severity: Major Priority: P5 - None Component: Mobile Devices AssignedTo: thoenig@novell.com ReportedBy: fseidel@novell.com QAContact: qa@suse.de CC: zoz@novell.com, cstender@novell.com Found By: Development /usr/sbin/thinkpad-keys is always on of the top-3 causes to always keep my cpu hot (most times even in top-2), so my cpu is prevented to go to C4 state by thinkpad-keys only. thinkpad-keys rereads its whole dataset from nvram up to 25times per second (cpu/time expensive and in a maximum unoptimal way) just to show up OSD (on screen display) info. Additionally this is needles to many points: 1. thinkpad_acpi (kernel module) can be told to issue acpi-events which then can be processed (no need for polling at all). ---but even without using acpi-events: 2. 5HZ would be enough (5 e.g. volume-changes per second should be enough - especially as this is expensive polling just for the OSD popup). 3. The expensive reading of nvram needs to be optimized to just read parts of interest (and not everything (with 25HZ), process all changes, then see if those found changes are of interest and so forth...) I would very much prefer to use acpi-events from the thinkpad_acpi driver, as additionally thinkpad-keys messes with the hardware-volume mixer of thinkpads. But this is due to a wrong compile of the source (the source documents this, but we compile the part for soft-mixers (only found i extremly old/outdated thinkpads), but not the part for hardware-mixers found in todays thinkpads. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=308191#c1
Timo Hoenig
/usr/sbin/thinkpad-keys is always on of the top-3 causes to always keep my cpu hot (most times even in top-2), so my cpu is prevented to go to C4 state by thinkpad-keys only. thinkpad-keys rereads its whole dataset from nvram up to 25times per second (cpu/time expensive and in a maximum unoptimal way) just to show up OSD (on screen display) info.
Reduce the interval and you will see that it does not work very well.
Additionally this is needles to many points: 1. thinkpad_acpi (kernel module) can be told to issue acpi-events which then can be processed (no need for polling at all).
Please share which ACPI events are being generated for volume up/down and mute.
---but even without using acpi-events: 2. 5HZ would be enough (5 e.g. volume-changes per second should be enough - especially as this is expensive polling just for the OSD popup).
See above.
3. The expensive reading of nvram needs to be optimized to just read parts of interest (and not everything (with 25HZ), process all changes, then see if those found changes are of interest and so forth...)
I would very much prefer to use acpi-events from the thinkpad_acpi driver, as additionally thinkpad-keys messes with the hardware-volume mixer of thinkpads.
If we rely on ACPI events we'd still have to pass the events using uinput to keep the OSD working. We're still stuck with the double adjustment as we do not have a "handled in hardware" flag as for brightness keys.
But this is due to a wrong compile of the source (the source documents this, but we compile the part for soft-mixers (only found i extremly old/outdated thinkpads), but not the part for hardware-mixers found in todays thinkpads.
Hm? I don't understand what you're trying to say. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=308191#c2
Frank Seidel
(In reply to comment #0 from Frank Seidel)
/usr/sbin/thinkpad-keys is always on of the top-3 causes to always keep my cpu hot (most times even in top-2), so my cpu is prevented to go to C4 state by thinkpad-keys only. thinkpad-keys rereads its whole dataset from nvram up to 25times per second (cpu/time expensive and in a maximum unoptimal way) just to show up OSD (on screen display) info.
Reduce the interval and you will see that it does not work very well.
What problems do you see there (e.g. with 5HZ)?
Additionally this is needles to many points: 1. thinkpad_acpi (kernel module) can be told to issue acpi-events which then can be processed (no need for polling at all).
Please share which ACPI events are being generated for volume up/down and mute.
Reproduction shouldn't be that difficult .. as i told, of course you have to activate them in the ibm/thinkpad_acpi module. for volume up: ibm/hotkey HKEY 00000080 00001015 for volume down: ibm/hotkey HKEY 00000080 00001016 for mute: ibm/hotkey HKEY 00000080 00001017
3. The expensive reading of nvram needs to be optimized to just read parts of interest (and not everything (with 25HZ), process all changes, then see if those found changes are of interest and so forth...)
I would very much prefer to use acpi-events from the thinkpad_acpi driver, as additionally thinkpad-keys messes with the hardware-volume mixer of thinkpads.
If we rely on ACPI events we'd still have to pass the events using uinput to keep the OSD working.
Hu? Passing the events on isn't the problem! But polling all the time..
We're still stuck with the double adjustment as we do not have a "handled in hardware" flag as for brightness keys.
What double adjustment?
But this is due to a wrong compile of the source (the source documents this, but we compile the part for soft-mixers (only found i extremly old/outdated thinkpads), but not the part for hardware-mixers found in todays thinkpads.
Hm? I don't understand what you're trying to say.
That the misbehaving volume (when changed via the volume keys) is due to using the soft-mixer codepatch in thinkpad-keys, instead of the hardware-mixer path. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=308191#c3
Timo Hoenig
What problems do you see there (e.g. with 5HZ)?
When I added my interactivity code to t-k it was not usable as the OSD did not react timely. As I've written before, just give it a try. But as...
Reproduction shouldn't be that difficult .. as i told, of course you have to activate them in the ibm/thinkpad_acpi module.
for volume up: ibm/hotkey HKEY 00000080 00001015 for volume down: ibm/hotkey HKEY 00000080 00001016 for mute: ibm/hotkey HKEY 00000080 00001017
we actually get the events, we can drop the nvram stuff altogether. I'll re-write t-k to pass those events using the input layer and uinput.
What double adjustment?
HW mixer + SW mixer as GNOME and KDE mixers react on the event.
That the misbehaving volume (when changed via the volume keys) is due to using the soft-mixer codepatch in thinkpad-keys, instead of the hardware-mixer path.
I can't recall what code you're referring to, I'll have a look next week. Do we have to modify thinkpad-acpi on the kernel side to get the events or is touching the hotkey mask enough to get the events? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=308191#c4
--- Comment #4 from Frank Seidel
https://bugzilla.novell.com/show_bug.cgi?id=308191
Frank Seidel
https://bugzilla.novell.com/show_bug.cgi?id=308191#c5
Timo Hoenig
participants (1)
-
bugzilla_noreply＠novell.com