From: Ivo van Doorn <ivdoorn@gmail.com>
To: Dan Williams <dcbw@redhat.com>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
John Linville <linville@tuxdriver.com>, Jiri Benc <jbenc@suse.cz>,
Lennart Poettering <lennart@poettering.net>,
Johannes Berg <johannes@sipsolutions.net>,
Larry Finger <Larry.Finger@lwfinger.net>
Subject: Re: [RFC] rfkill - Add support for input key to control wireless radio
Date: Thu, 7 Dec 2006 22:58:14 +0100 [thread overview]
Message-ID: <200612072258.14926.IvDoorn@gmail.com> (raw)
In-Reply-To: <1165497754.2972.6.camel@localhost.localdomain>
Hi,
> > > > 2 - Hardware key that does not control the hardware radio and does not report anything to userspace
> > >
> > > Kind of uninteresting button ;)
> >
> > And this is the button that rfkill was originally designed for.
> > Laptops with integrated WiFi cards from Ralink have a hardware button that don't send anything to
> > userspace (unless the ACPI event is read) and does not directly control the radio itself.
>
> My take: if there is a button on your keyboard or laptop labeled "Kill
> my radio now", it _NEEDS_ to be somehow communicated to userspace what
> happened when the user just pressed it a second ago. Personally, I
> don't particularly care how that happens, and I don't particularly care
> what the driver does. But if the driver, or the hardware, decides that
> the button press means turning off the transmitter on whatever device
> that button is for, a tool like NetworkManager needs to know this
> somehow. Ideally, this would be a HAL event, and HAL would get it from
> somewhere.
>
> The current situation with NM is unacceptable, and I can't do anything
> about it because there is no standard interface for determining whether
> the wireless card was disabled/enabled via rfkill. I simply refuse to
> code solutions to every vendor's rfkill mechanism (for ipw, reading
> iwpriv or sysfs, for example). I don't care how HAL gets the event, but
> when HAL gets the event, it needs to broadcast it and NM needs to tear
> down the connection and release the device.
>
> That means (a) an event gets sent to userspace in some way that HAL can
> read it, and (b) the event is clearly associated with specific piece[s]
> of hardware on your system. If HAL can't easily figure out what device
> the event is for, then the event is also useless to both HAL and
> NetworkManager and whatever else might use it.
This would be possible with rfkill and the ideas from Dmitry.
The vendors that have a button that directly toggle the radio, should
create an input device themselves and just send the KEY_RFKILL event when toggled.
All other types should use rfkill for the toggling handling, that way HAL only needs to
listen to KEY_RFKILL coming from the input devices that are associated to the keys.
> Again, I don't care how that happens, but I like the fact that there's
> renewed interest in getting this fixed.
Ivo
next prev parent reply other threads:[~2006-12-07 21:58 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-12-03 18:36 [RFC] rfkill - Add support for input key to control wireless radio Ivo van Doorn
2006-12-03 19:18 ` Arjan van de Ven
2006-12-03 22:03 ` Ivo van Doorn
2006-12-03 19:20 ` Arjan van de Ven
2006-12-03 22:05 ` Ivo van Doorn
2006-12-03 22:28 ` Ivo van Doorn
2006-12-05 0:18 ` Randy Dunlap
2006-12-05 21:20 ` Ivo van Doorn
2006-12-03 19:44 ` Dan Williams
2006-12-03 22:16 ` Ivo van Doorn
2006-12-04 8:53 ` Marcel Holtmann
2006-12-04 22:15 ` Dmitry Torokhov
2006-12-04 23:27 ` Ivo van Doorn
2006-12-06 14:37 ` Dmitry Torokhov
2006-12-06 15:18 ` Dan Williams
2006-12-06 15:24 ` Dmitry Torokhov
2006-12-06 19:31 ` Ivo van Doorn
2006-12-06 20:18 ` Dmitry Torokhov
2006-12-06 21:41 ` Ivo van Doorn
2006-12-06 22:04 ` Dmitry Torokhov
2006-12-07 21:53 ` Ivo van Doorn
2006-12-12 5:12 ` Dmitry Torokhov
2006-12-12 7:47 ` Ivo Van Doorn
2006-12-17 17:43 ` Ivo van Doorn
2007-01-30 16:33 ` Ivo van Doorn
2006-12-07 13:22 ` Dan Williams
2006-12-07 21:58 ` Ivo van Doorn [this message]
2006-12-06 22:05 ` Jiri Benc
2006-12-06 22:10 ` Dmitry Torokhov
2006-12-05 10:32 ` Christoph Hellwig
2006-12-05 21:21 ` Ivo van Doorn
2007-01-31 3:40 ` Stephen Hemminger
2007-01-31 10:39 ` Ivo van Doorn
2007-01-31 11:20 ` Ivo van Doorn
2007-03-30 5:27 ` Dmitry Torokhov
2007-03-30 5:29 ` Dmitry Torokhov
2007-03-30 14:59 ` Ivo van Doorn
2007-03-30 15:28 ` Dmitry Torokhov
2007-03-30 17:13 ` Ivo van Doorn
2007-03-30 18:37 ` Dmitry Torokhov
2007-03-31 12:49 ` Ivo van Doorn
2007-04-02 4:38 ` Dmitry Torokhov
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=200612072258.14926.IvDoorn@gmail.com \
--to=ivdoorn@gmail.com \
--cc=Larry.Finger@lwfinger.net \
--cc=dcbw@redhat.com \
--cc=dmitry.torokhov@gmail.com \
--cc=jbenc@suse.cz \
--cc=johannes@sipsolutions.net \
--cc=lennart@poettering.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linville@tuxdriver.com \
--cc=netdev@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.