thinkpad-keys on T60p permanently uses 2% CPU even when the system is idle

[Alex Bligh]

Dapper live CD daily build from 23 May 2006

On an IBM T60p (fast processor) thinkpad-keys uses 2% CPU. It seems to be locked in a cycle of lseek(), read() a few times, then a nanosleep for 5 milliseconds.

Whilst it works perfectly well, eating 2% CPU is not great nor very power-usage friendly. Can it not select() on the FD it is reading instead?

[Matthew Garrett (mjg59)]

It can't select() since the writes to nvram don't go through the OS.

--
Matthew Garrett | <email address hidden>

[Paul Sladen (sladen)]

'/dev/nvram' is a virtual file that reads out the embedded controller space after the 14th byte (hiding the real-time-clock which lives at the front of the EC).

A read from the nvram actually involves (1) write off to address register (2) poll until ready (3) read byte from data register. Luckily the kernel driver hides all of this, but is also means that it's a black box and it's unclear where the delay on these new LenovoPads is coming from. (And I don't own/have access to any hardware which exhibits the issue).

The nvram bits itself get toggled by the BIOS in system-management-mode or someother magic that we don't know about.

I think what I'll do for dapper is change the polling from 20Hz (20*4=80 reads/second) to 10Hz, or maybe even 5Hz (although 5Hz misses the 100msec latency suggested by UI guidelines).

5Hz is what 'tpb' used to default to... In the longer term I have an idea to do low-speed polling until a button is pressed and then switch briefly into a faster mode as most presses (eg. Volume keys) come in quick bursts.

[Amit Shah (am1tshah)]

I have a ThinkPad T60 and am running Kubuntu Feisty. thinkpad-keys always uses 2% CPU on my system.