On Mon, 2007-05-21 at 09:32 -0300, Henrique de Moraes Holschuh wrote:
> On Mon, 21 May 2007, Richard Hughes wrote:
> > Has there been any work on implementing rfkill for thinkpad_acpi? If
> > there is nobody working on this I am offering to add support into
> > thinkpad_acpi this week.
>
> Yes, I have been talking to the rfkill people, but we had some disagreements
> on how to best to it. I let it rest for a week or so to think better about
> some issues they raised, and also in order not to waste too much bandwidth
> from either side of the issue.
>
> Basically, I want a "fetch data from the hardware to know what state it is
> in for real" interface. They want a "find a way to make sure the hardware
> is doing what we told it to do" interface.
Yes, sort of orthogonal issues.
> I might even find out that we are better off not using rfkill in
> thinkpad-acpi itself, and letting the bluetooth and wwan drivers process it.
> We shall see.
Less than ideal from a userspace POV, as I really just wanted to write
one bit of glue code in HAL to get all the rfkill stuff to work.
> The thinkpad ACPI interface does a lot more than just
> radio-kill, it actually kills power to the *devices* themselves, AFAIK
> (removes them from the USB bus, causing hotunplug events). Anyone with a
> bluetooth and WWAN device, please speak up.
Yes, so understand. The latter is very important from a powersave point
of view, and I can understand how disconnecting from the bus would nuke
the device, and not allow you to turn on the device with the rfkill
interface. I did not think of this.
> So far, what I got is that rfkill is all about handling "please disable
> radios" system-wide events, and not about providing drivers with a standard
> sysfs interface to enable/disable radio functionality. At least for now.
Yes, agreed. For the moment I can bodge it, and just use an addon for
HAL, but I'm guessing other hardware has this issue, and we should
probably fix this the right way.
Richard.
|