ibm-acpi-devel — ibm-acpi Linux driver development

Re: [ibm-acpi-devel] nvram keys to userspace

[Henrique de M. H. <hm...@hm...>]

On Wed, 16 May 2007, Richard Hughes wrote:
> On Wed, 2007-05-16 at 10:10 -0300, Henrique de Moraes Holschuh wrote:
> > The plan is to get all hotkeys sent to userspace through INPUT, using a
> > "hotkey fX" or something equally generic.  I can't translate from fn+f3 to
> > fn+battery, as that's model specific knowledge.
> 
> So you don't want to do any dmi-based matching in thinkpad_acpi at all?
> When the dmi kernel class is upstream this could be pretty easy,
> although I don't mind doing it in userspace with a keymap.

DMI matching in thinkpad-acpi for firmware bug workarounds, and also module
autoload is OK.  For model-specific knowledge related to hotkeys, it is not.
This is how upstream wants it, actually.

> > Well, worse come to worst, we can send them over ACPI.
> 
> Ick :-)

It may be the only choice.  Adding new keys to input is frowned upon...

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: [ibm-acpi-devel] nvram keys to userspace

[Richard H. <hug...@gm...>]

On Wed, 2007-05-16 at 10:10 -0300, Henrique de Moraes Holschuh wrote:
> The plan is to get all hotkeys sent to userspace through INPUT, using a
> "hotkey fX" or something equally generic.  I can't translate from fn+f3 to
> fn+battery, as that's model specific knowledge.

So you don't want to do any dmi-based matching in thinkpad_acpi at all?
When the dmi kernel class is upstream this could be pretty easy,
although I don't mind doing it in userspace with a keymap.

> > Sure, I totally understand. The primary reason I want the status of
> > these (hw) buttons is to integrate them with gnome OSD for stuff like
> > gnome-session and that sort of thing, rather than rely on XOSD like
> > before. There's also some other buttons I want to be able to map to
> > arbitrary stuff, like the 'thinkpad' button. The main problem is the
> > reporting is that some has to be passive "volume has been turned up"
> > rather than active "please turn volume up" - but I still think we can do
> > this with INPUT.
> 
> Yes, we can.  But maybe you could just monitor the forthcoming thinkpad ALSA
> mixer for the hardware state, instead?  You would be monitoring the
> *effects* and not the cause, which is actually a good thing.

Yes, you're completely correct.

> And it doesn't
> mean we can't monitor the keys too, since there are other keys that need
> monitoring anyway.

Sure, web keys and that sort of thing.

> But it is not a good idea to issue volume up/down/mute INPUT events for
> those keys (unless that too is optional), these events are typically active
> ones from multimedia keyboards.  It will cause trouble.  We will need other
> events.

Sure. 

> Well, worse come to worst, we can send them over ACPI.

Ick :-)

> > > It has to be optional, and it needs to support all tpb-like keys.  Other
> > > than that, yes, it might be acceptable.
> > 
> > Sure. Has anybody else looked at INPUT on thinkpad_acpi, or would you
> > like me to just in and start coding? I think converting the hotkeys to
> > INPUT would be my first task, and then working on NVRAM hardware keys
> > when the first stuff is merged. 
> 
> If you send me code, it will speed up adoption.

Okay, I'll spend a few hours on it tonight, and see what I can come up
with. 

> This doesn't mean I promise
> to take the patch as is, of course, but I think that functionality is a good
> idea.

Of course!

> > I really don't want to add yet another daemon that polls stuff and mucks
> > about with acpi keys when we can do this properly (IMO) in the kernel.
> 
> I hate the idea of any extra polling.  We need proper interfaces with unix
> fd semanthics that you can poll() and select() on in sysfs.

I'm glad we agree. I'll get hacking now. Many thanks for your help with
this.

Richard.

Re: [ibm-acpi-devel] nvram keys to userspace

[Henrique de M. H. <hm...@hm...>]

On Wed, 16 May 2007, Richard Hughes wrote:
> > thinkpad-acpi has a feature scheduled to export control of the mixer these
> > keys control as an alsa mixer device, so I wouldn't mind much adding input
> > processing too.  We will need to get there for properly handling the fn+x
> > keys anyway.
> 
> Yes, I was also looking at them. Some already get squirted through ACPI
> (power button type) but most are like battery (FnF3):
> 
> ibm/hotkey HKEY 00000080 00001003
> 
> and only enabled when I do "echo enable,0xffff >/proc/acpi/ibm/hotkey".
> Converting these to INPUT is probably the best plan first.

The plan is to get all hotkeys sent to userspace through INPUT, using a
"hotkey fX" or something equally generic.  I can't translate from fn+f3 to
fn+battery, as that's model specific knowledge.

> Sure, I totally understand. The primary reason I want the status of
> these (hw) buttons is to integrate them with gnome OSD for stuff like
> gnome-session and that sort of thing, rather than rely on XOSD like
> before. There's also some other buttons I want to be able to map to
> arbitrary stuff, like the 'thinkpad' button. The main problem is the
> reporting is that some has to be passive "volume has been turned up"
> rather than active "please turn volume up" - but I still think we can do
> this with INPUT.

Yes, we can.  But maybe you could just monitor the forthcoming thinkpad ALSA
mixer for the hardware state, instead?  You would be monitoring the
*effects* and not the cause, which is actually a good thing.  And it doesn't
mean we can't monitor the keys too, since there are other keys that need
monitoring anyway.

But it is not a good idea to issue volume up/down/mute INPUT events for
those keys (unless that too is optional), these events are typically active
ones from multimedia keyboards.  It will cause trouble.  We will need other
events.

Well, worse come to worst, we can send them over ACPI.

> > It has to be optional, and it needs to support all tpb-like keys.  Other
> > than that, yes, it might be acceptable.
> 
> Sure. Has anybody else looked at INPUT on thinkpad_acpi, or would you
> like me to just in and start coding? I think converting the hotkeys to
> INPUT would be my first task, and then working on NVRAM hardware keys
> when the first stuff is merged. 

If you send me code, it will speed up adoption.  This doesn't mean I promise
to take the patch as is, of course, but I think that functionality is a good
idea.

> I really don't want to add yet another daemon that polls stuff and mucks
> about with acpi keys when we can do this properly (IMO) in the kernel.

I hate the idea of any extra polling.  We need proper interfaces with unix
fd semanthics that you can poll() and select() on in sysfs.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: [ibm-acpi-devel] nvram keys to userspace

[Richard H. <hug...@gm...>]

On Wed, 2007-05-16 at 00:12 -0300, Henrique de Moraes Holschuh wrote:
> On Tue, 15 May 2007, Richard Hughes wrote:
> > Hi, sorry for the direct mail, please feel free to CC this message to
> > the revelant lists.
> 
> That would be ibm...@li....  CC added.

Cheers.

> > I've been asked to add tpd-like interfaces to userspace for an x60, so
> > that the volume up, down and mute buttons are working in userspace. To
> 
> Why?  Did Lenovo break those keys in the X60?  They usually manipulate the
> machine's hardware mixer in firmware, and trying to process them in
> userspace just ends up causing problems...
> 
> > do this I need to use nvram as this is not exported in ACPI.
> 
> Correct.
> 
> > I really have two options, add the code to the thinkpad_acpi.c kernel
> > driver and export the nvram functions and then push the buttons
> > through INPUT so that we can deal with them in the normal way or to
> > add a HAL addon to do the polling in userspace.
> 
> thinkpad-acpi has a feature scheduled to export control of the mixer these
> keys control as an alsa mixer device, so I wouldn't mind much adding input
> processing too.  We will need to get there for properly handling the fn+x
> keys anyway.

Yes, I was also looking at them. Some already get squirted through ACPI
(power button type) but most are like battery (FnF3):

ibm/hotkey HKEY 00000080 00001003

and only enabled when I do "echo enable,0xffff >/proc/acpi/ibm/hotkey".
Converting these to INPUT is probably the best plan first.

> But it needs to be optional, and before I accept any such things, I need to
> know why are them necessary.  No other recent thinkpad I know needs
> something messing with the volume keys, unless you are using the audio
> interface in the dock/port-replicator, which for some foolish reason is
> derived *before* the internal hardware mixer.

Sure, I totally understand. The primary reason I want the status of
these (hw) buttons is to integrate them with gnome OSD for stuff like
gnome-session and that sort of thing, rather than rely on XOSD like
before. There's also some other buttons I want to be able to map to
arbitrary stuff, like the 'thinkpad' button. The main problem is the
reporting is that some has to be passive "volume has been turned up"
rather than active "please turn volume up" - but I still think we can do
this with INPUT.

> > The HAL addon is quite trivial (~30 LOC) but means that input events
> > are going via uinput which is oviously non-ideal. I can add code to
> > thinkpad_acpi to do this fairly cleanly (with your help) if this is
> > acceptable to you guys.
> 
> It has to be optional, and it needs to support all tpb-like keys.  Other
> than that, yes, it might be acceptable.

Sure. Has anybody else looked at INPUT on thinkpad_acpi, or would you
like me to just in and start coding? I think converting the hotkeys to
INPUT would be my first task, and then working on NVRAM hardware keys
when the first stuff is merged. 

I really don't want to add yet another daemon that polls stuff and mucks
about with acpi keys when we can do this properly (IMO) in the kernel.

Thanks for your help so far,

Richard Hughes

Re: [ibm-acpi-devel] FC6 / IBM x31 / ACPI Fan control Help

[Henrique de M. H. <hm...@hm...>]

On Tue, 15 May 2007, Robert ... wrote:
> The first clue I can think of to help, is that I don't have the 
> /proc/acpi/ibm/fan and /proc/acpi/ibm/ecdump files. Where do I get them?  I 
> feel this the heart of the problem.

Read the driver's documentation on your kernel tree.  Documents/ibm-acpi.txt
or Documents/thinkpad-acpi.txt.

You need to activate the "experimental" features.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: [ibm-acpi-devel] nvram keys to userspace

[Henrique de M. H. <hm...@hm...>]

On Tue, 15 May 2007, Richard Hughes wrote:
> Hi, sorry for the direct mail, please feel free to CC this message to
> the revelant lists.

That would be ibm...@li....  CC added.

> I've been asked to add tpd-like interfaces to userspace for an x60, so
> that the volume up, down and mute buttons are working in userspace. To

Why?  Did Lenovo break those keys in the X60?  They usually manipulate the
machine's hardware mixer in firmware, and trying to process them in
userspace just ends up causing problems...

> do this I need to use nvram as this is not exported in ACPI.

Correct.

> I really have two options, add the code to the thinkpad_acpi.c kernel
> driver and export the nvram functions and then push the buttons
> through INPUT so that we can deal with them in the normal way or to
> add a HAL addon to do the polling in userspace.

thinkpad-acpi has a feature scheduled to export control of the mixer these
keys control as an alsa mixer device, so I wouldn't mind much adding input
processing too.  We will need to get there for properly handling the fn+x
keys anyway.

But it needs to be optional, and before I accept any such things, I need to
know why are them necessary.  No other recent thinkpad I know needs
something messing with the volume keys, unless you are using the audio
interface in the dock/port-replicator, which for some foolish reason is
derived *before* the internal hardware mixer.

> The HAL addon is quite trivial (~30 LOC) but means that input events
> are going via uinput which is oviously non-ideal. I can add code to
> thinkpad_acpi to do this fairly cleanly (with your help) if this is
> acceptable to you guys.

It has to be optional, and it needs to support all tpb-like keys.  Other
than that, yes, it might be acceptable.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

[ibm-acpi-devel] FC6 / IBM x31 / ACPI Fan control Help

[Robert ... <rob...@ho...>]

I've tried for months to get this to work: control my fan speed in Fedore 
Core 6 (kernel 2.6.20-1.2948) on my thinkpad x31.

The first clue I can think of to help, is that I don't have the 
/proc/acpi/ibm/fan and /proc/acpi/ibm/ecdump files. Where do I get them?  I 
feel this the heart of the problem.

I would be very very grateful if I could help on this.

Thanks,
Robert

[ibm-acpi-devel] thinkpad_acpi and dual boot

[Alexey F. <bug...@fi...>]

Hallo all!
i have one issue what actually not a thinkpad_acpi bug but :-/

The problem is i have dual_head dual_boot system ( thinkpad t43 )
windwos xp and ubuntu feisty. Both of them seted up to use LCD-primary
and CRT-secondary where "CRT" LeftOf "LCD". After windows usage LCD will
be secondary and Xorg fails to start.

The question: is it possible to make thinkpad_acpi option to force LCD
to be primary.

Thank you for your work! :)
Alex

Re: [ibm-acpi-devel] How to handle WWAN card, together with WLAN or separate?

[Henrique de M. H. <hm...@hm...>]

On Wed, 09 May 2007, Henning Schild wrote:
> The statement i quoted is not true for all thinkpads. Please keep in
> mind that some thinkpads have an additional hardware kill switch.

I didn't forget it.  But right now we are dealing with the software kill
switches, only.  The "enable/disable" bluetooth and WWAN to be exact.

> However the new solution will handle rfkill, i would still like to be
> able to trigger something on an hwillswitch event. And of cause the

I will go after the hardware kill switch later.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: [ibm-acpi-devel] How to handle WWAN card, together with WLAN or separate?

[Henning S. <he...@wh...>]

Am Tue, 8 May 2007 23:08:44 -0300
schrieb Henrique de Moraes Holschuh <hm...@hm...>:

> It makes sense to group it with other WLAN rfkill switches, and
> thinkpads only have a single key (typically fn+f5) which is supposed
> to control all radios anyway, so I am inclined to do just that.

I do not fully understand your mail, maybe because i dont know much
about the input subsystem, its types, classes and how it is related to
acpi.
The statement i quoted is not true for all thinkpads. Please keep in
mind that some thinkpads have an additional hardware kill switch.
However the new solution will handle rfkill, i would still like to be
able to trigger something on an hwillswitch event. And of cause the
trigger should be able to get the state of the switch or at least a
different event should be fired.

Henning

Re: [ibm-acpi-devel] How to handle WWAN card, together with WLAN or separate?

[Henrique de M. H. <hm...@hm...>]

On Tue, 08 May 2007, Dmitry Torokhov wrote:
> On Tuesday 08 May 2007 22:08, Henrique de Moraes Holschuh wrote:
> > The rfkill class has been merged in Linux mainline, and if at all possible,
> > thinkpad-acpi will use it to connect or disconnect the internal bluetooth
> > and WWAN devices.
> > 
> > The rfkill class has a concept of "type" of the radio, which is used to,
> > e.g., turn on or off all radios of the same type.  This is coupled to the
> > input subsystem, so that the kernel can switch on/off all radios of a given
> > type if KEY_WLAN or KEY_BLUETOOTH is pressed... (yes, I will add that to
> > thinkpad-acpi shortly).  This behaviour can be overriden on a card-by-card
> > basis.
> > 
> > Now, I can add a new WWAN type for the WWAN card, or I can group it with
> > WLAN.  What I am *not* going to do is to request that KEY_WWAN be added to
> > the input subsystem, so if I add a new type, this means there will be no way
> > to bind (in kernel) a key to a WWAN radio on/off software switch, and the
> > usual scripts in userspace will be needed.
> > 
> > It makes sense to group it with other WLAN rfkill switches, and thinkpads
> > only have a single key (typically fn+f5) which is supposed to control all
> > radios anyway, so I am inclined to do just that.
> > 
> > Comments?
> 
> I would add a new switch type and adjust rfkill-input to toggle both
> WLAN and WWAN switches when user presses KEY_WLAN. More fine-grained
> control can be done in userspace. Does this make sense? 

I suppose it does.  I will do that, then, unless someone convinces me
otherwise.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: [ibm-acpi-devel] How to handle WWAN card, together with WLAN or separate?

[Dmitry T. <dt...@in...>]

On Tuesday 08 May 2007 22:08, Henrique de Moraes Holschuh wrote:
> The rfkill class has been merged in Linux mainline, and if at all possible,
> thinkpad-acpi will use it to connect or disconnect the internal bluetooth
> and WWAN devices.
> 
> The rfkill class has a concept of "type" of the radio, which is used to,
> e.g., turn on or off all radios of the same type.  This is coupled to the
> input subsystem, so that the kernel can switch on/off all radios of a given
> type if KEY_WLAN or KEY_BLUETOOTH is pressed... (yes, I will add that to
> thinkpad-acpi shortly).  This behaviour can be overriden on a card-by-card
> basis.
> 
> Now, I can add a new WWAN type for the WWAN card, or I can group it with
> WLAN.  What I am *not* going to do is to request that KEY_WWAN be added to
> the input subsystem, so if I add a new type, this means there will be no way
> to bind (in kernel) a key to a WWAN radio on/off software switch, and the
> usual scripts in userspace will be needed.
> 
> It makes sense to group it with other WLAN rfkill switches, and thinkpads
> only have a single key (typically fn+f5) which is supposed to control all
> radios anyway, so I am inclined to do just that.
> 
> Comments?
> 

I would add a new switch type and adjust rfkill-input to toggle both
WLAN and WWAN switches when user presses KEY_WLAN. More fine-grained
control can be done in userspace. Does this make sense? 

-- 
Dmitry

[ibm-acpi-devel] How to handle WWAN card, together with WLAN or separate?

[Henrique de M. H. <hm...@hm...>]

The rfkill class has been merged in Linux mainline, and if at all possible,
thinkpad-acpi will use it to connect or disconnect the internal bluetooth
and WWAN devices.

The rfkill class has a concept of "type" of the radio, which is used to,
e.g., turn on or off all radios of the same type.  This is coupled to the
input subsystem, so that the kernel can switch on/off all radios of a given
type if KEY_WLAN or KEY_BLUETOOTH is pressed... (yes, I will add that to
thinkpad-acpi shortly).  This behaviour can be overriden on a card-by-card
basis.

Now, I can add a new WWAN type for the WWAN card, or I can group it with
WLAN.  What I am *not* going to do is to request that KEY_WWAN be added to
the input subsystem, so if I add a new type, this means there will be no way
to bind (in kernel) a key to a WWAN radio on/off software switch, and the
usual scripts in userspace will be needed.

It makes sense to group it with other WLAN rfkill switches, and thinkpads
only have a single key (typically fn+f5) which is supposed to control all
radios anyway, so I am inclined to do just that.

Comments?

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: [ibm-acpi-devel] [PATCH 8/9] ACPI: thinkpad-acpi: add sysfs support to hotkey subdriver

[Henrique de M. H. <hm...@hm...>]

On Sun, 06 May 2007, Luming Yu wrote:
> I don't like the idea of stuffing kernel space with model-specific
> knowledge (i.e. a table) even if it is in a driver. These tables
> should be in user space...

Yeah, I am reserving that option for stuff that absolutely must be in the
driver because it needs the knowledge to do something, and so far there is
nothing like that.  Maybe the LEDs will require it to be properly named, but
that is a very small table of exceptions, much like a blacklist.

> >We deliver to userspace something like "Fn+F1" pressed, instead of "blank
> >screen" pressed, because "blank screen" is in different keys depending on
> >thinkpad model.
> 
> Yes, you should generate generic key event through input layer..

It will move to the input layer eventually.  Right now, they are ACPI
events.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: [ibm-acpi-devel] [PATCH 8/9] ACPI: thinkpad-acpi: add sysfs support to hotkey subdriver

[Luming Y. <lum...@gm...>]

> > I was wondering how you know what action should be associated with what key?
>
> I don't.  I could though, using model-specific knowledge (i.e. a table) and
> help from the linux thinkpad community and thinkwiki.org.

I don't like the idea of stuffing kernel space with model-specific
knowledge (i.e. a table) even if it is in a driver. These tables
should be in user space...

>
> We deliver to userspace something like "Fn+F1" pressed, instead of "blank
> screen" pressed, because "blank screen" is in different keys depending on
> thinkpad model.

Yes, you should generate generic key event through input layer..

Re: [ibm-acpi-devel] [PATCH 3/9] ACPI: thinkpad-acpi: fix a fan watchdog invocation

[Henrique de M. H. <hm...@hm...>]

(adding lm-sensors to the cc list)

On Thu, 03 May 2007, Thomas Renninger wrote:
> I didn't have a closer look to the fan watchdog, but it looks like a
> ThinkPad specific thing?

The fan watchdog could be generic and done for any driver that knows how to
set a fan to a default, "safe" state even during a temperature-zone-
is-critical situation (i.e. the driver must know enough to never slow down a
fan that has been kicked into emergency mode, if a fan watchdog
functionality is to be safe).

The hwmon interface and sysfs glue could indeed be generic, and need just
one callback to the driver-specific code.  If a fan control chip or firmware
can do it in hardware, the callback programs the hardware.  If it is done in
software by the driver, the callback schedules the watchdog task.

> IMO we could need some general fan watchdog as fans are breaking away
> here and there.
> Latest reports came from HPs and FSC models ...

It won't help if the breakage is due to the driver not being able to
communicate with the fan properly, but it would help very much so if it is
caused by something else that keeps turning the fan off.

I don't know how well it would work with a generic ACPI framework for fans,
given that the ACPI control model for fans is braindead (no fan speed
control or tachometer reading support -- that was an extreme oversight) and
not really trustable in the last crop of crap the laptop vendors are pushing
out as DSDTs.

We'd need a rearming watchdog for what you want, though.  The one I added
for thinkpad-acpi/ibm-acpi is a single-fire one that doesn't rearm, as it
targets userspace fan control applications that die or get stuck (userspace
fan control applications *are* quite popular in T4x ThinkPads both in Linux
and Windows).  It would be simple enough to add a "fan_watchdog_rearm"
attribute that is set to either zero (don't rearm) or one (rearm), and that
is less confusing than, e.g. using negative numbers for one sort of watchdog
and positive numbers for the other sort.

> A check whether the fan/power resource is still in the assumed state
> or whether something changed it behind the back is a general good idea?

That is a future feature I was thinking about adding to thinkpad-acpi, so I
vote yes for machines in which we can trust the firmware.

It would easily belly-flop the kind of crap people are delivering on laptop
DSDTs nowadays, though...

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: [ibm-acpi-devel] [PATCH 3/9] ACPI: thinkpad-acpi: fix a fan watchdog invocation

[Thomas R. <tr...@su...>]

On Fri, 2007-04-27 at 22:00 -0300, Henrique de Moraes Holschuh wrote:
> The fan control watchdog was being called in one place even when the fan
> control operation had failed.  Fix it.

I didn't have a closer look to the fan watchdog, but it looks like a
ThinkPad specific thing?

IMO we could need some general fan watchdog as fans are breaking away
here and there.
Latest reports came from HPs and FSC models ...

A check whether the fan/power resource is still in the assumed state
or whether something changed it behind the back is a general good idea?

     Thomas

[ibm-acpi-devel] Brightness in X60 tablet (was Z61m)

[Antti P M. <an...@ik...>]

Just some data about the brightness control in X60 tablet. I've only
had this thing for about a week and overall things are quite sweet
with Ubuntu feisty :-)

The brightness _control_ works out of the box but the on screen
display (provided by gnome-power-manager) does not get the right
level, i.e. indication is broken. The hal is configured not to do any
control in response to brightness keys as this would cause a loop:
control generates key event which is caught, which causes control,
which causes event, which.. etc.

Anyway, for me the ACPI video module is _needed_ in order for the
brightness control to work. If I remove the video module, acpi_listen
does still see Fn+Home but Fn+End does not cause any events. Also the
brightness level stays unchanged.

When I have the ACPI video module loaded, the events reported by
acpi_listen are

down:
video LCD0 00000087 00000000
ibm/hotkey HKEY 00000080 00005010

up:
ibm/hotkey HKEY 00000080 00001010
video LCD0 00000086 00000000
ibm/hotkey HKEY 00000080 00005010

If I remove ibm_acpi module but have video module loaded, the
situation is the same: the brightness control works, but indication
not. I dumped /dev/nvram with different levels and looks like the
brigtness level is at offset 0x5e lower nibble just like expected by
the thinkpad-keys.c in hotkey-setup package:

--- nvram-4.txt 2007-04-29 11:24:20.000000000 +0300
+++ nvram-5.txt 2007-04-29 11:24:25.000000000 +0300
@@ -3,7 +3,7 @@
 00000020  03 a5 00 fc 20 88 c1 01  00 7c 00 00 00 00 00 00  |.... ....|......|
 00000030  00 00 08 40 b0 bb 00 63  bb d4 2f 07 d0 30 80 00  |...@...c../..0..|
 00000040  00 00 00 00 c0 05 52 f8  01 1d 00 5b 0f 02 00 00  |......R....[....|
-00000050  00 00 04 00 fe 38 ff a0  03 71 d0 06 13 c2 a4 f1  |.....8...q......|
+00000050  00 00 04 00 fe 38 ff a0  03 71 d0 06 13 c2 85 f1  |.....8...q......|
 00000060  c4 03 90 fe 00 06 71 00  03 12 fc 00 00 00 49 53  |......q.......IS|
 00000070  b2 00                                             |..|
 00000072

--- nvram-5.txt 2007-04-29 11:24:25.000000000 +0300
+++ nvram-6.txt 2007-04-29 11:24:29.000000000 +0300
@@ -3,7 +3,7 @@
 00000020  03 a5 00 fc 20 88 c1 01  00 7c 00 00 00 00 00 00  |.... ....|......|
 00000030  00 00 08 40 b0 bb 00 63  bb d4 2f 07 d0 30 80 00  |...@...c../..0..|
 00000040  00 00 00 00 c0 05 52 f8  01 1d 00 5b 0f 02 00 00  |......R....[....|
-00000050  00 00 04 00 fe 38 ff a0  03 71 d0 06 13 c2 85 f1  |.....8...q......|
+00000050  00 00 04 00 fe 38 ff a0  03 71 d0 06 13 c2 a6 f1  |.....8...q......|
 00000060  c4 03 90 fe 00 06 71 00  03 12 fc 00 00 00 49 53  |......q.......IS|
 00000070  b2 00                                             |..|
 00000072

The ibm_acpi module seems to read the level from EC, offset 0x31 but
for me the value there changes only if I control the brightness via
e.g. /proc/acpi/ibm/brightness. Control via /proc/acpi/ibm/brightness
is visible to /dev/nvram.

So I suppose one way to fix the indication would be to make hal read
the level via /dev/nvram. But I suppose it would be nice for
/proc/acpi/ibm/brightness to also indicate the right level.

For me the /proc/acpi/video/VID/LCD0/brightness shows always zero for
the current brightness:

levels:  100 30 30 40 50 60 70 80 90 100
current: 0

Can I provide some more info? Something from lshal:

  smbios.system.version = 'ThinkPad X60 Tablet'  (string)
  smbios.system.product = '6363A7G'  (string)
  smbios.system.manufacturer = 'LENOVO'  (string)
  smbios.bios.release_date = '12/14/2006'  (string)
  smbios.bios.version = '7JET19WW (1.04 )'  (string)
  smbios.bios.vendor = 'LENOVO'  (string)

-- 
http://www.iki.fi/~ananaza/

Re: [ibm-acpi-devel] [PATCH 8/9] ACPI: thinkpad-acpi: add sysfs support to hotkey subdriver

[Henrique de M. H. <hm...@hm...>]

On Sat, 28 Apr 2007, Len Brown wrote:
> On Friday 27 April 2007 21:00, Henrique de Moraes Holschuh wrote:
> > Add the hotkey sysfs support.
> > 
> > Signed-off-by: Henrique de Moraes Holschuh <hm...@hm...>
> > ---
> >  Documentation/thinkpad-acpi.txt |   58 ++++++++++++++----
> >  drivers/misc/thinkpad_acpi.c    |  127 +++++++++++++++++++++++++++++++++++++++
> >  drivers/misc/thinkpad_acpi.h    |    2 +
> >  3 files changed, 176 insertions(+), 11 deletions(-)
> 
> I haven't tried this out.
> I was wondering how you know what action should be associated with what key?

I don't.  I could though, using model-specific knowledge (i.e. a table) and
help from the linux thinkpad community and thinkwiki.org.

We deliver to userspace something like "Fn+F1" pressed, instead of "blank
screen" pressed, because "blank screen" is in different keys depending on
thinkpad model.

The BIOS *does* know, and that's what the Mask does. If you leave a bit
off, the bios handles that key (typically doing nothing), but for some keys
like "suspend to disk", it actually generates a ACPI suspend event... etc.

> if that association can be made, is is possible to send the events to
> the input layer like other keyboard events?

I plan to connect to the input layer later on, yes.  But I haven't started
down that road yet.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

[ibm-acpi-devel] thinkpad-acpi release 0.14-20070428 available in sf.net

[Henrique de M. H. <hm...@hm...>]

I have released version 0.14-20070428 of thinkpad-acpi through the
sourceforge.net release system.

It is available as patches against Linux 2.6.20.10 and 2.6.21.1 at:
http://sourceforge.net/project/showfiles.php?group_id=117042&package_id=230205

For those who missed my post to this mailing-list, ibm-acpi was renamed
thinkpad-acpi for various reasons.  *This means you need to change your
kernel configuration*.  Make oldconfig right after applying the patch is
probably the easiest way to make sure you have thinkpad-acpi activated.

This release has a lot of changes, including the first parts of a sysfs
interface for thinkpad-acpi, and the fact that fan-control now requires that
you give the module a "fan_control=1" parameter to be enabled.

Please test and report any errors, this stuff has been sent upstream for
2.6.22.

Patches are available only for 2.6.20 and 2.6.21.  Sorry, but the changes
are too extensive, and I don't have the time to backport and test them for
2.6.18 and 2.6.19.  If anyone would like to work seriously on thinkpad-acpi
backports for a past kernel version, please contact me through the
ibm-acpi-devel mailinglist.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: [ibm-acpi-devel] [OT] screen savers

[Sascha H. <sas...@gm...>]

2007/4/28, Henrique de Moraes Holschuh <hm...@hm...>:

> It is amusing to know that gnome-screensaver is just as much a utter piece
> of crap as its KDE counterpart.

LOL, its not the only amusing part of gnome-screensaver.
I dont know if you use Gnome but in gnome's power-manager where you
set the time until the screen goes into standby or the time when the
Laptop goes into suspend the minimum time you can configure is 11
minutes.
11 minutes? Why?
Im probably not the only one that asked himself this question and yes
this is also because of gnome-screensaver.
gnome-screensaver has a default kick-in time of 10m and
gnome-power-manager calculates his minimum-time by this 10+1 to avoid
starting before the screensaver.
Now we have 11m minimum time before the screen can go into standby on
every distro in the world because of the stupid screensaver.

> Just switch to xscreensaver.

No, thx, i dont need a screensaver :-)

> > Now i just have to figure out why gnome-power-manager is not turning
> > off the screen anymore, time to hop to the next mailing-list i guess.
>
> Good luck, you will need it.

Thx.


Sascha

[ibm-acpi-devel] [OT] screen savers

[Henrique de M. H. <hm...@hm...>]

On Sat, 28 Apr 2007, Sascha Heid wrote:
> It turned out that it is gnome-screensaver (at least for now).
> It is set to 1m but i have it disabled in the GUI dialog so i assumed
> it would not "run".
> There is a gnome-screensaver process running though and killing it
> fixes the problem.

It is amusing to know that gnome-screensaver is just as much a utter piece
of crap as its KDE counterpart.

Just switch to xscreensaver.

> Now i just have to figure out why gnome-power-manager is not turning
> off the screen anymore, time to hop to the next mailing-list i guess.

Good luck, you will need it.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: [ibm-acpi-devel] ibm_acpi forces Screen out of standby after 1m

[Sascha H. <sas...@gm...>]

Sorry for accusing the wrong software again (it was xorg one hour ago) :-)
It turned out that it is gnome-screensaver (at least for now).
It is set to 1m but i have it disabled in the GUI dialog so i assumed
it would not "run".
There is a gnome-screensaver process running though and killing it
fixes the problem.

Now i just have to figure out why gnome-power-manager is not turning
off the screen anymore, time to hop to the next mailing-list i guess.


Sascha

[ibm-acpi-devel] Conversion of ibm-acpi to hwmon sysfs sent to ACPI tree

[Henrique de M. H. <hm...@hm...>]

FYI: I have sent a group of patches to Len Brown (ACPI tree maintainer) that
adds hwmon support to thinkpad-acpi (ibm-acpi's new name).  It exports 16
temperatures and one fan with PWM control through the hwmon interface, and
targets 2.6.22.

The patches make extensive use of ENXIO for temperature sensors that are
hotpluggable but for which we cannot detect the plug/unplug events.  Reading
a sensor that is not present at that instant returns ENXIO.

The patches are available in the ibm-acpi-devel and linux-acpi ML archives,
and also by request or through
http://repo.or.cz/w/linux-2.6/linux-acpi-2.6/ibm-acpi-2.6.git

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: [ibm-acpi-devel] [PATCH 1/9] ACPI: thinkpad-acpi: add a fan-control feature master toggle

[Henrique de M. H. <hm...@hm...>]

Drat, sorry about this, I gave git send-email a mbox file instead of a
directory by mistake.  I will resend it.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh