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

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

[Norbert Preining]

Hi all,

(please Cc)

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.

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

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.

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

Thanks a lot and all the best

Norbert

-------------------------------------------------------------------------------
Dr. Norbert Preining <preining@logic.at>        Vienna University of Technology
Debian Developer <preining@debian.org>                         Debian TeX Group
gpg DSA: 0x09C5B094      fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094
-------------------------------------------------------------------------------
AFFPUDDLE (n.)
A puddle which is hidden under a pivoted paving stone. You only know
it's there when you step on the paving stone and the puddle shoots up
your leg.
			--- Douglas Adams, The Meaning of Liff

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

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

[Norbert Preining]

Hi Marcel, hi all,

On Sa, 11 Jul 2009, Marcel Holtmann wrote:
> > - 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.

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

Best wishes

Norbert

-------------------------------------------------------------------------------
Dr. Norbert Preining <preining@logic.at>        Vienna University of Technology
Debian Developer <preining@debian.org>                         Debian TeX Group
gpg DSA: 0x09C5B094      fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094
-------------------------------------------------------------------------------
FROLESWORTH (n.)
Measure. The minimum time it is necessary to spend frowning in deep
concentration at each picture in an art gallery in order that everyone
else doesn't think you've a complete moron.
			--- Douglas Adams, The Meaning of Liff

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

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

[Norbert Preining]

On Sa, 11 Jul 2009, Marcel Holtmann wrote:
> > So, /dev/rfkill and the rfkill user mode program is the way to go?
> 
> Yes that is the way to go.

Ok, I have rewritten my rfkill gnome applet with threads and polling
/dev/rfkill. Did work out fine.

I hope the format will not change too often ;-)

Best wishes

Norbert

-------------------------------------------------------------------------------
Dr. Norbert Preining <preining@logic.at>        Vienna University of Technology
Debian Developer <preining@debian.org>                         Debian TeX Group
gpg DSA: 0x09C5B094      fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094
-------------------------------------------------------------------------------
BEALINGS
The unsavoury parts of a moat which a knight has to pour out of his
armour after being the victim of an araglin (q.v.). In medieval
Flanders, soup made from bealins was a very slightly sought-after
delicacy.
			--- Douglas Adams, The Meaning of Liff

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

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 409 bytes --]

On Mon, 2009-08-10 at 12:43 +0200, Norbert Preining wrote:

> Ok, I have rewritten my rfkill gnome applet with threads and polling
> /dev/rfkill. Did work out fine.

Umm. That's wrong in multiple ways. You don't need threads, and you
don't need to poll. Just open /dev/rfkill, add the fd to the event loop
and read events.

> I hope the format will not change too often ;-)

It won't.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

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

[Norbert Preining]

Hi Johannes,

thanks a lot for your remarks, and sorry, in fact I am a complete
ignorant wrt all these things, just programming what I need ;-)
Some questions:

On Mo, 10 Aug 2009, Johannes Berg wrote:
> Umm. That's wrong in multiple ways. You don't need threads, and you
> don't need to poll. Just open /dev/rfkill, add the fd to the event loop
> and read events.

Aehm, I am doing exactely what the user space 
	rfkill event
is doing. Isn't that supposed to be?

And threads I need (AFAIU) because the read from the fd will blcok
until there is an event, and in the mean time the user might
do something with the applet (like disabling manually the rfkill,
or configuration). So one thread is listening to user events (the 
normal pygtk loop) and one is reading from /dev/rfkill and 
in case something comes in it takes the respective actions.

In python-speak I do:

	fd = os.open("/dev/rfkill", os.O_RDONLY)
	p = select.poll()
	p.register(fd, select.POLLIN | select.POLLHUP)
	n = p.poll()
	if (t == select.POLLIN)
	  buf = os.read(fd, 8)
	....

Isn't that supposed to work like that?

At least that is what rfkill.c does in the event loop.

Best wishes

Norbert

-------------------------------------------------------------------------------
Dr. Norbert Preining <preining@logic.at>        Vienna University of Technology
Debian Developer <preining@debian.org>                         Debian TeX Group
gpg DSA: 0x09C5B094      fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094
-------------------------------------------------------------------------------
TODBER (n.)
One whose idea of a good time is to stand behind his front hedge and
give surly nods to people he doesn't know.
			--- Douglas Adams, The Meaning of Liff

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

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1082 bytes --]

On Mon, 2009-08-10 at 14:28 +0200, Norbert Preining wrote:

> And threads I need (AFAIU) because the read from the fd will blcok
> until there is an event, and in the mean time the user might
> do something with the applet (like disabling manually the rfkill,
> or configuration). So one thread is listening to user events (the 
> normal pygtk loop) and one is reading from /dev/rfkill and 
> in case something comes in it takes the respective actions.
> 
> In python-speak I do:
> 
> 	fd = os.open("/dev/rfkill", os.O_RDONLY)
> 	p = select.poll()
> 	p.register(fd, select.POLLIN | select.POLLHUP)
> 	n = p.poll()
> 	if (t == select.POLLIN)
> 	  buf = os.read(fd, 8)
> 	....
> 
> Isn't that supposed to work like that?

Oh, that's what you mean by polling...

Well, you still don't need threads, since you can just add your fd to
the gtk event loop. You'd probably use
http://library.gnome.org/devel/glib/unstable/glib-IO-Channels.html#g-io-add-watch and http://library.gnome.org/devel/glib/unstable/glib-IO-Channels.html#g-io-channel-unix-new

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]