From: Marcel Holtmann <marcel@holtmann.org>
To: Norbert Preining <preining@logic.at>
Cc: linux-kernel@vger.kernel.org, Johannes Berg <johannes@sipsolutions.net>
Subject: Re: rfkill rework in 2.6.31-rc, hal/dbus access changes?
Date: Sat, 11 Jul 2009 14:12:25 -0700 [thread overview]
Message-ID: <1247346745.9709.129.camel@localhost.localdomain> (raw)
In-Reply-To: <20090711195911.GA31549@gamma.logic.tuwien.ac.at>
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
next prev parent reply other threads:[~2009-07-11 21:12 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-11 9:14 rfkill rework in 2.6.31-rc, hal/dbus access changes? Norbert Preining
2009-07-11 18:54 ` Marcel Holtmann
2009-07-11 19:59 ` Norbert Preining
2009-07-11 21:12 ` Marcel Holtmann [this message]
2009-08-10 10:43 ` Norbert Preining
2009-08-10 12:22 ` Johannes Berg
2009-08-10 12:28 ` Norbert Preining
2009-08-10 12:40 ` Johannes Berg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1247346745.9709.129.camel@localhost.localdomain \
--to=marcel@holtmann.org \
--cc=johannes@sipsolutions.net \
--cc=linux-kernel@vger.kernel.org \
--cc=preining@logic.at \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox