Re: rfkill rework in 2.6.31-rc, hal/dbus access changes?

[Marcel Holtmann]

Hi Norbert,

> I have written a Gnome applet for turning off and on the various
> hardware items using the rfkill interface. It was working very well on
> up to 2.6.30. With 2.6.31-rc that infrastructure has been changed, and
> now no access mode I know of still works.
> 
> - formerly writing 0 or 1 to /sys/class/rfkill/rfkillN/state worked, now
>   it returns access denied.

actually Johannes sent a patch to fix this. It will still return an
error if the RFKILL switch is hard-blocked btw.

> - access via Hal/Dbus (what I am doing) stopped working, too

Not the first time HAL broke in this area, because its RFKILL support is
a bunch of hacked up scripts. Send a patch to the HAL mailing list.

> In the Documentation I only see reference to /dev/rfkill, which isn't a
> usefull access method because for the applet to work for every user
> (based on the permissions of hal) we need hal/dbus access.

You could just go ahead and work on fixing HAL.

> Is this intended behaviour? Is there any other documentation but the
> very short rfkill.txt in the kernel's Documentation?

Changing RFKILL soft-block via the state file got fixed, but it is still
a total broken interface. If you rely on it (directly or via HAL) your
application is useless. And if you are polling the state of the RFKILL
switches via HAL, then your application is even worse. You need to
wake-up too often to actually see RFKILL state changes.

The /dev/rfkill interface is the only way to get a proper interface with
all RFKILL switches in your system. And this includes enumeration, async
notification and changing states on a per technology basis.

Regards

Marcel


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/