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

[Marcel Holtmann]

Hi Norbert,

> > > - 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.
> 
> I found that and have just now rebooted into -rc2 with this patch
> applied, and yes, it works again.
> 
> > > - 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.
> 
> Indeed *with* Johannes' patch also HAL/Dbus access works again, so I
> don't have to dig into that again. Probably at the end of the line both
> hal and sys access to the state file ended up in the same dead end which
> was fixed by the patch.
> 
> So thanks, Johannes, all fine now.
> 
> > You could just go ahead and work on fixing HAL.
> 
> That is far out of my abilities, I was happy to hack a gnome applet in
> python using hal/dbus, that fine.
> 
> > The /dev/rfkill interface is the only way to get a proper interface with
> 
> But reading from that file directly is not a piece of cake, at least I
> haven't seen any specification of the format. I have downloaded the
> rfkill user space utility and will try to use that one instead, but that
> makes it more difficult due to access permission gamble.

There is no gamble with the access permission. Unix access permission
are quite clear. Actually the sysfs state file here is the gamble since
you don't know what you get. Actually HAL has no idea what happened
after writing to that file. Either is it soft-block, hard-block, did it
work or even when the RFKILL is active.

Also the specification is in the rfkill.h header file including what you
can expect. It can't be simpler than poll/read/write.

> So, /dev/rfkill and the rfkill user mode program is the way to go?

Yes that is the way to go.

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/