linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dan Williams <dcbw@redhat.com>
To: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: Tony Vroon <tony@linx.net>, 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: Sun, 14 Dec 2008 12:05:43 -0500	[thread overview]
Message-ID: <1229274343.6775.15.camel@localhost.localdomain> (raw)
In-Reply-To: <20081213132857.GA11428@khazad-dum.debian.net>

On Sat, 2008-12-13 at 11:28 -0200, Henrique de Moraes Holschuh wrote:
> 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.

If HAL's killswitch support doesn't know about the kernel killswitch
device, or it cannot get the state of the killswitch, then certainly
NetworkManager isn't going to know about it.

Dan

> 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.
> 


  parent reply	other threads:[~2008-12-14 17:06 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
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 [this message]
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=1229274343.6775.15.camel@localhost.localdomain \
    --to=dcbw@redhat.com \
    --cc=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).