From: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
To: Tony Vroon <tony@linx.net>
Cc: Len Brown <lenb@kernel.org>, Ivo van Doorn <ivdoorn@gmail.com>,
linux-acpi@vger.kernel.org, jwoithe@physics.adelaide.edu.au,
Peter Gruber <nokos@gmx.net>,
linux-wireless@vger.kernel.org
Subject: Re: Fuijtsu Lifebook RFKILL support
Date: Sat, 13 Dec 2008 11:28:57 -0200 [thread overview]
Message-ID: <20081213132857.GA11428@khazad-dum.debian.net> (raw)
In-Reply-To: <1229172465.4010.11.camel@localhost>
On Sat, 13 Dec 2008, Tony Vroon wrote:
> > What is the WLAN driver involved? Is it rfkill-aware?
>
> The driver is iwlagn, which does indeed notice that it is killed.
> This information does not reach NetworkManager. Relevant log
> entries: Dec 12 00:59:01 amalthea iwlagn: Radio Frequency Kill
> Switch is On: Dec 12 00:59:01 amalthea Kill switch must be turned
> off for wireless networking to work.
Then, it is just a matter of time for it to be working correctly. In
fact, it might already be if you use wireless-testing and latest
network manager.
Best not to mess with it, any workarounds one adds would just get in
the way in the future.
> [cutting relevant pieces of text together]
> > > 1. rfkill actualy is/looks like a hotplug/hotunplug operation
> > > 1b. You cannot do it at will
> > > Attaching it to the rfkill core simply is not supported
>
> Okay, both Bluetooth & WWAN are USB devices following this terminology.
> So the rfkill framework is not an appropriate tool for this job,
> understood.
>
> Len, I would still like to export the 3 values learned about in this
> event to userspace. Is it alright for me to create 3 read-only files on
> the platform device? (docked, lid, radios)
> It would if anything simplify the code.
FWIW, I think this is also the way to go. It is much easier for
userspace to deal with sysfs attributes. HAL can deal with more
complex stuff, but shell script writers often don't know how to, nor
care to, deal with HAL.
BTW, this also means that it is helpful to shell script writers if you
also export through read-only sysfs attributes the state of any input
devices generating EV_SW. The input layer makes it possible to query
the switch state easily... through IOCTL after you find out the
correct input device(s) to query. Which ain't easy for shell script,
and nobody wrote a "inputdev" helper in a proper language that can do
it, for shell script writers to call.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
next prev parent reply other threads:[~2008-12-13 13:29 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1228957506.4045.11.camel@localhost>
[not found] ` <20081211165247.GA4844@khazad-dum.debian.net>
[not found] ` <1229016827.6446.6.camel@localhost>
[not found] ` <20081211194734.GA18132@khazad-dum.debian.net>
[not found] ` <1229046602.4030.13.camel@localhost>
[not found] ` <20081212195331.GA12679@khazad-dum.debian.net>
2008-12-12 20:33 ` Fuijtsu Lifebook RFKILL support Len Brown
2008-12-13 12:47 ` Tony Vroon
2008-12-13 13:28 ` Henrique de Moraes Holschuh [this message]
2008-12-13 17:57 ` Matthew Garrett
2008-12-13 20:55 ` Tony Vroon
2008-12-13 21:24 ` Matthew Garrett
2008-12-14 3:13 ` Henrique de Moraes Holschuh
2008-12-14 17:05 ` Dan Williams
2008-12-15 11:53 ` Henrique de Moraes Holschuh
2008-12-15 15:19 ` Dan Williams
2008-12-15 17:14 ` Tony Vroon
2008-12-15 17:59 ` Dan Williams
2008-12-16 13:50 ` Tony Vroon
2008-12-16 15:23 ` Dan Williams
2008-12-15 23:42 ` Jonathan Woithe
2008-12-15 23:48 ` Tony Vroon
2008-12-16 0:02 ` Jonathan Woithe
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=20081213132857.GA11428@khazad-dum.debian.net \
--to=hmh@hmh.eng.br \
--cc=ivdoorn@gmail.com \
--cc=jwoithe@physics.adelaide.edu.au \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=nokos@gmx.net \
--cc=tony@linx.net \
/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;
as well as URLs for NNTP newsgroup(s).