linux-kernel - Re: [PATCH 3/8] rfkill: handle KEY_RADIO and SW

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 12 Apr 2008 15:02:19 -0300
From:	Henrique de Moraes Holschuh <hmh@....eng.br>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc:	linux-kernel@...r.kernel.org, Ivo van Doorn <IvDoorn@...il.com>,
	"John W. Linville" <linville@...driver.com>
Subject: Re: [PATCH 3/8] rfkill: handle KEY_RADIO and SW_RADIO events

On Sat, 12 Apr 2008, Dmitry Torokhov wrote:
> On Fri, Apr 11, 2008 at 05:37:19PM -0300, Henrique de Moraes Holschuh wrote:
> > The *_RADIO input events are related to all radios in a system.  There are
> > two: KEY_RADIO and SW_RADIO.
> > 
> 
> KEY_RADIO is reserved for selecting radio input (as pooosed to TV, AUX,
> etc) with a remote control. Rfkill woudl need a separate keycode if it
> needs "all types of radios" event.

Hmm, let me check where I got the wrong idea of using KEY_RADIO from,
because thinkpad-acpi already uses KEY_WLAN which means that at least in
the past I did know KEY_RADIO was not to be used for wireless data
communication devices like that...  jeez, looks like spontaneous brain
corruption on that topic hapenned to me sometime ago, and it came out in
a linux-thinkpad thread a few weeks ago.  The wrong semanthics for
KEY_RADIO seem to have stuck to my mind since then.  Drat, I *really*
apologise for this one.

This, of course, is a major NAK for this patch.  And I am considering
dropping the handling of KEY_<whatever replaces RADIO> completely from
it.  SW_RADIO (after a rename, see below) still needs to be handled,
though.

> Btw, is there any devices in the wild that actually have separate
> switches for different types of transmitters?

Separate switches?  I know of none.

Separate hot keys/buttons?  I haven't seen it, but check commit
90da11514562020ea7d697982f912ac949adc317's comment.  That was the commit
which added KEY_WLAN and KEY_BLUETOOTH, back in 2.6.18-rc.  Maybe ask
Lennart Poettering about it?

What I have seen in laptops is:

"Wireless Switch" (SW_RADIO -- this one has a bad name, might even be
what caused me to screw up with the KEY_RADIO thing, and it hints that
my brain corruption was deep rooted, since I was the one who came up
with SW_RADIO).   These switches do their plain best to remove all RF
output when in the "wireles off" position, and stop bothering RF output
when in the "wireless on" position.  Transitions from off->on are often
used as a hint to bring up wireless data communication services (such as
firing up wirelesss settings GUI pannels, etc).

"Wireless hot-key", which either brings up an GUI related to which
wireless data communication radios are active and their configuration,
or directly changes the set of active wireless data communication
radios.

One could easily argue that, should we make it possible for userspace to
interact with the global rfkill state for each rfkill switch type, all
handling of the "Wireless hot-key" should be done in userspace.  I will
go with that for now, and think about it some more.

New patches coming soon.  Please don't merge ANY of the patches in this
set, I will respin the entire series.

-- 
  "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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/