[PATCH 32/33] input: add KEY_WIRELESS_CYCLE

[PATCH 32/33] input: add KEY_WIRELESS_CYCLE

[Corentin Chary]

This keycode could be used in a lot of platform specific drivers.
For example, on Asus laptops, Fn+F2 allow to cycle trought wireless
drivers (bt/wl: off/off, on/off, off/on, on/on).

Currently, these key are mapped to KEY_WLAN, and KEY_BLUETOOTH/KEY_WIMAX
are rarely used.

Cc: linux-input@vger.kernel.org
Signed-off-by: Corentin Chary <corentincj@iksaif.net>
---
 include/linux/input.h |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/include/linux/input.h b/include/linux/input.h
index c2b1a7d..c961908 100644
--- a/include/linux/input.h
+++ b/include/linux/input.h
@@ -376,6 +376,7 @@ struct input_absinfo {
 #define KEY_DISPLAY_OFF		245	/* display device to off state */
 
 #define KEY_WIMAX		246
+#define KEY_WIRELESS_CYCLE	247
 
 /* Range 248 - 255 is reserved for special needs of AT keyboard driver */
 
-- 
1.6.5.3

Re: [PATCH 32/33] input: add KEY_WIRELESS_CYCLE

[Dmitry Torokhov]

On Thu, Dec 03, 2009 at 08:45:16AM +0100, Corentin Chary wrote:
> This keycode could be used in a lot of platform specific drivers.
> For example, on Asus laptops, Fn+F2 allow to cycle trought wireless
> drivers (bt/wl: off/off, on/off, off/on, on/on).
> 
> Currently, these key are mapped to KEY_WLAN, and KEY_BLUETOOTH/KEY_WIMAX
> are rarely used.
> 

Is there any application support for such cycling? IOW does anyone cares
to do such cycling?

-- 
Dmitry

Re: [PATCH 32/33] input: add KEY_WIRELESS_CYCLE

[Corentin Chary]

On Thu, Dec 3, 2009 at 8:54 AM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> On Thu, Dec 03, 2009 at 08:45:16AM +0100, Corentin Chary wrote:
>> This keycode could be used in a lot of platform specific drivers.
>> For example, on Asus laptops, Fn+F2 allow to cycle trought wireless
>> drivers (bt/wl: off/off, on/off, off/on, on/on).
>>
>> Currently, these key are mapped to KEY_WLAN, and KEY_BLUETOOTH/KEY_WIMAX
>> are rarely used.
>>
>
> Is there any application support for such cycling? IOW does anyone cares
> to do such cycling?

On Asus laptops (both asus and eeepc) the Fn+F2 key cycle
(bluetooth/wlan: on/on, on/off, off/on, off/off) on windows.
On Linux, it only produces a KEY_WLAN keycode.

-- 
Corentin Chary
http://xf.iksaif.net

Re: [PATCH 32/33] input: add KEY_WIRELESS_CYCLE

[Dmitry Torokhov]

On Thu, Dec 03, 2009 at 09:12:52AM +0100, Corentin Chary wrote:
> On Thu, Dec 3, 2009 at 8:54 AM, Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
> > On Thu, Dec 03, 2009 at 08:45:16AM +0100, Corentin Chary wrote:
> >> This keycode could be used in a lot of platform specific drivers.
> >> For example, on Asus laptops, Fn+F2 allow to cycle trought wireless
> >> drivers (bt/wl: off/off, on/off, off/on, on/on).
> >>
> >> Currently, these key are mapped to KEY_WLAN, and KEY_BLUETOOTH/KEY_WIMAX
> >> are rarely used.
> >>
> >
> > Is there any application support for such cycling? IOW does anyone cares
> > to do such cycling?
> 
> On Asus laptops (both asus and eeepc) the Fn+F2 key cycle
> (bluetooth/wlan: on/on, on/off, off/on, off/off) on windows.
> On Linux, it only produces a KEY_WLAN keycode.
> 

I understand this. I guess the question is whether people working on
system infrastructure (dbus, Networkmanager, etc) care about having such
functionality on Linux? The reason I am asking is that we added all
KEY_WIMAX and so on defines but I am not usre if anyone wants them.

-- 
Dmitry

Re: [PATCH 32/33] input: add KEY_WIRELESS_CYCLE

[Corentin Chary]

On Thu, Dec 3, 2009 at 9:21 AM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> On Thu, Dec 03, 2009 at 09:12:52AM +0100, Corentin Chary wrote:
>> On Thu, Dec 3, 2009 at 8:54 AM, Dmitry Torokhov
>> <dmitry.torokhov@gmail.com> wrote:
>> > On Thu, Dec 03, 2009 at 08:45:16AM +0100, Corentin Chary wrote:
>> >> This keycode could be used in a lot of platform specific drivers.
>> >> For example, on Asus laptops, Fn+F2 allow to cycle trought wireless
>> >> drivers (bt/wl: off/off, on/off, off/on, on/on).
>> >>
>> >> Currently, these key are mapped to KEY_WLAN, and KEY_BLUETOOTH/KEY_WIMAX
>> >> are rarely used.
>> >>
>> >
>> > Is there any application support for such cycling? IOW does anyone cares
>> > to do such cycling?
>>
>> On Asus laptops (both asus and eeepc) the Fn+F2 key cycle
>> (bluetooth/wlan: on/on, on/off, off/on, off/off) on windows.
>> On Linux, it only produces a KEY_WLAN keycode.
>>
>
> I understand this. I guess the question is whether people working on
> system infrastructure (dbus, Networkmanager, etc) care about having such
> functionality on Linux? The reason I am asking is that we added all
> KEY_WIMAX and so on defines but I am not usre if anyone wants them.

KEY_WIMAX may not be used a lot because there is not a lot of device
with such a key,
I think this is not the case for KEY_WIRELESS_CYCLE.

The bad thing is that we will need to patch X11 (and Qt, for
kde/solid) to make it works.

Maybe we should Cc dbus/network manager/solid/linux-wireless ?

-- 
Corentin Chary
http://xf.iksaif.net

Re: [PATCH 32/33] input: add KEY_WIRELESS_CYCLE

[Dmitry Torokhov]

On Thu, Dec 03, 2009 at 09:51:59AM +0100, Corentin Chary wrote:
> On Thu, Dec 3, 2009 at 9:21 AM, Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
> > On Thu, Dec 03, 2009 at 09:12:52AM +0100, Corentin Chary wrote:
> >> On Thu, Dec 3, 2009 at 8:54 AM, Dmitry Torokhov
> >> <dmitry.torokhov@gmail.com> wrote:
> >> > On Thu, Dec 03, 2009 at 08:45:16AM +0100, Corentin Chary wrote:
> >> >> This keycode could be used in a lot of platform specific drivers.
> >> >> For example, on Asus laptops, Fn+F2 allow to cycle trought wireless
> >> >> drivers (bt/wl: off/off, on/off, off/on, on/on).
> >> >>
> >> >> Currently, these key are mapped to KEY_WLAN, and KEY_BLUETOOTH/KEY_WIMAX
> >> >> are rarely used.
> >> >>
> >> >
> >> > Is there any application support for such cycling? IOW does anyone cares
> >> > to do such cycling?
> >>
> >> On Asus laptops (both asus and eeepc) the Fn+F2 key cycle
> >> (bluetooth/wlan: on/on, on/off, off/on, off/off) on windows.
> >> On Linux, it only produces a KEY_WLAN keycode.
> >>
> >
> > I understand this. I guess the question is whether people working on
> > system infrastructure (dbus, Networkmanager, etc) care about having such
> > functionality on Linux? The reason I am asking is that we added all
> > KEY_WIMAX and so on defines but I am not usre if anyone wants them.
> 
> KEY_WIMAX may not be used a lot because there is not a lot of device
> with such a key,
> I think this is not the case for KEY_WIRELESS_CYCLE.
> 
> The bad thing is that we will need to patch X11 (and Qt, for
> kde/solid) to make it works.
> 
> Maybe we should Cc dbus/network manager/solid/linux-wireless ?
> 

That would be a good idea.

-- 
Dmitry

Re: [PATCH 32/33] input: add KEY_WIRELESS_CYCLE

[Corentin Chary]

On Thu, Dec 3, 2009 at 9:57 AM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> On Thu, Dec 03, 2009 at 09:51:59AM +0100, Corentin Chary wrote:
>> On Thu, Dec 3, 2009 at 9:21 AM, Dmitry Torokhov
>> <dmitry.torokhov@gmail.com> wrote:
>> > On Thu, Dec 03, 2009 at 09:12:52AM +0100, Corentin Chary wrote:
>> >> On Thu, Dec 3, 2009 at 8:54 AM, Dmitry Torokhov
>> >> <dmitry.torokhov@gmail.com> wrote:
>> >> > On Thu, Dec 03, 2009 at 08:45:16AM +0100, Corentin Chary wrote:
>> >> >> This keycode could be used in a lot of platform specific drivers.
>> >> >> For example, on Asus laptops, Fn+F2 allow to cycle trought wireless
>> >> >> drivers (bt/wl: off/off, on/off, off/on, on/on).
>> >> >>
>> >> >> Currently, these key are mapped to KEY_WLAN, and KEY_BLUETOOTH/KEY_WIMAX
>> >> >> are rarely used.
>> >> >>
>> >> >
>> >> > Is there any application support for such cycling? IOW does anyone cares
>> >> > to do such cycling?
>> >>
>> >> On Asus laptops (both asus and eeepc) the Fn+F2 key cycle
>> >> (bluetooth/wlan: on/on, on/off, off/on, off/off) on windows.
>> >> On Linux, it only produces a KEY_WLAN keycode.
>> >>
>> >
>> > I understand this. I guess the question is whether people working on
>> > system infrastructure (dbus, Networkmanager, etc) care about having such
>> > functionality on Linux? The reason I am asking is that we added all
>> > KEY_WIMAX and so on defines but I am not usre if anyone wants them.
>>
>> KEY_WIMAX may not be used a lot because there is not a lot of device
>> with such a key,
>> I think this is not the case for KEY_WIRELESS_CYCLE.
>>
>> The bad thing is that we will need to patch X11 (and Qt, for
>> kde/solid) to make it works.
>>
>> Maybe we should Cc dbus/network manager/solid/linux-wireless ?
>>
>
> That would be a good idea.

Here it is.

Dear system infrastructure people,
Do you think a KEY_WIRELESS_CYCLE key would have any application ?

-- 
Corentin Chary
http://xf.iksaif.net

Re: [PATCH 32/33] input: add KEY_WIRELESS_CYCLE

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1582 bytes --]

On Thu, 2009-12-03 at 10:22 +0100, Corentin Chary wrote:

> >> > I understand this. I guess the question is whether people working on
> >> > system infrastructure (dbus, Networkmanager, etc) care about having such
> >> > functionality on Linux? The reason I am asking is that we added all
> >> > KEY_WIMAX and so on defines but I am not usre if anyone wants them.
> >>
> >> KEY_WIMAX may not be used a lot because there is not a lot of device
> >> with such a key,
> >> I think this is not the case for KEY_WIRELESS_CYCLE.
> >>
> >> The bad thing is that we will need to patch X11 (and Qt, for
> >> kde/solid) to make it works.
> >>
> >> Maybe we should Cc dbus/network manager/solid/linux-wireless ?
> >>
> >
> > That would be a good idea.
> 
> Here it is.
> 
> Dear system infrastructure people,
> Do you think a KEY_WIRELESS_CYCLE key would have any application ?

Not really.

The naming of the key ultimately will not matter one bit, because it'll
be misnamed on most platforms anyway, unless we want to do DMI matching
or something to name the key. And even then, if there's a wifi key but
no bluetooth key, users may prefer to have the wifi key act as a cycle
key instead.

Therefore, this ought to all be policy in the rfkill daemon.
rfkill-input will be going away as soon as somebody writes a simple
daemon that allows doing such things, I really don't see us adding
support for a cycle key to the kernel code, and for the userspace code
it doesn't matter since users will configure it independent of the key
code anyway.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [PATCH 32/33] input: add KEY_WIRELESS_CYCLE

[Henrique de Moraes Holschuh]

On Wed, 02 Dec 2009, Dmitry Torokhov wrote:
> On Thu, Dec 03, 2009 at 08:45:16AM +0100, Corentin Chary wrote:
> > This keycode could be used in a lot of platform specific drivers.
> > For example, on Asus laptops, Fn+F2 allow to cycle trought wireless
> > drivers (bt/wl: off/off, on/off, off/on, on/on).
> > 
> > Currently, these key are mapped to KEY_WLAN, and KEY_BLUETOOTH/KEY_WIMAX
> > are rarely used.
> 
> Is there any application support for such cycling? IOW does anyone cares
> to do such cycling?

Well, the default ThinkPad behaviour would be to cycle as well, and I'd use
this new keycode if it becomes available.

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

Re: [Kde-hardware-devel] [PATCH 32/33] input: add KEY_WIRELESS_CYCLE

[Will Stephenson]

On Thursday 03 December 2009 10:43:32 Johannes Berg wrote:
> On Thu, 2009-12-03 at 10:22 +0100, Corentin Chary wrote:
> > Dear system infrastructure people,
> > Do you think a KEY_WIRELESS_CYCLE key would have any application ?
> 
> Not really.
> 
> The naming of the key ultimately will not matter one bit, because it'll
> be misnamed on most platforms anyway, unless we want to do DMI matching
> or something to name the key. And even then, if there's a wifi key but
> no bluetooth key, users may prefer to have the wifi key act as a cycle
> key instead.
> 
> Therefore, this ought to all be policy in the rfkill daemon.
> rfkill-input will be going away as soon as somebody writes a simple
> daemon that allows doing such things, I really don't see us adding
> support for a cycle key to the kernel code, and for the userspace code
> it doesn't matter since users will configure it independent of the key
> code anyway.

This sounds reasonable to me, as the wireless guy in the KDE camp.  I don't 
want to have to handle these keypresses in a user session anyway - I prefer 
that NetworkManager picks up on them and notifies the client of the state 
change.

Will
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 32/33] input: add KEY_WIRELESS_CYCLE

[Matthew Garrett]

On Thu, Dec 03, 2009 at 10:22:16AM +0100, Corentin Chary wrote:

> Dear system infrastructure people,
> Do you think a KEY_WIRELESS_CYCLE key would have any application ?

Not really. I've got a KEY_RFKILL patch queued, with the intended 
semantics being for rfkill-input to just toggle all devices. If a 
userspace rfkill daemon is running, it could use that to implement the 
cycle policy you want. I don't think we need both.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 32/33] input: add KEY_WIRELESS_CYCLE

[Andrey Rahmatullin]

[-- Attachment #1: Type: text/plain, Size: 774 bytes --]

On Thu, Dec 03, 2009 at 09:12:52AM +0100, Corentin Chary wrote:
> >> This keycode could be used in a lot of platform specific drivers.
> >> For example, on Asus laptops, Fn+F2 allow to cycle trought wireless
> >> drivers (bt/wl: off/off, on/off, off/on, on/on).
> >>
> >> Currently, these key are mapped to KEY_WLAN, and KEY_BLUETOOTH/KEY_WIMAX
> >> are rarely used.
> > Is there any application support for such cycling? IOW does anyone cares
> > to do such cycling?
> On Asus laptops (both asus and eeepc) the Fn+F2 key cycle
> (bluetooth/wlan: on/on, on/off, off/on, off/off) on windows.
> On Linux, it only produces a KEY_WLAN keycode.
Default eee901's Xandros cycles and even shows an OSD with BT and WLAN
state images.

-- 
WBR, wRAR (ALT Linux Team)

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [PATCH 32/33] input: add KEY_WIRELESS_CYCLE

[Dmitry Torokhov]

On Sun, Dec 06, 2009 at 11:58:29AM +0500, Andrey Rahmatullin wrote:
> On Thu, Dec 03, 2009 at 09:12:52AM +0100, Corentin Chary wrote:
> > >> This keycode could be used in a lot of platform specific drivers.
> > >> For example, on Asus laptops, Fn+F2 allow to cycle trought wireless
> > >> drivers (bt/wl: off/off, on/off, off/on, on/on).
> > >>
> > >> Currently, these key are mapped to KEY_WLAN, and KEY_BLUETOOTH/KEY_WIMAX
> > >> are rarely used.
> > > Is there any application support for such cycling? IOW does anyone cares
> > > to do such cycling?
> > On Asus laptops (both asus and eeepc) the Fn+F2 key cycle
> > (bluetooth/wlan: on/on, on/off, off/on, off/off) on windows.
> > On Linux, it only produces a KEY_WLAN keycode.
> Default eee901's Xandros cycles and even shows an OSD with BT and WLAN
> state images.
> 

You are describing the visible result. Whether it is done as a custom
policy to KEY_WLAN presses or utilizes a separate key definition - is
not known.

Anyway, we got the response form wireless developers and infrastructure
people and thyy do not care about having a new defintion so I guess that
settles it.

-- 
Dmitry

Re: [PATCH 32/33] input: add KEY_WIRELESS_CYCLE

[Corentin Chary]

On Sun, Dec 6, 2009 at 8:17 AM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> On Sun, Dec 06, 2009 at 11:58:29AM +0500, Andrey Rahmatullin wrote:
>> On Thu, Dec 03, 2009 at 09:12:52AM +0100, Corentin Chary wrote:
>> > >> This keycode could be used in a lot of platform specific drivers.
>> > >> For example, on Asus laptops, Fn+F2 allow to cycle trought wireless
>> > >> drivers (bt/wl: off/off, on/off, off/on, on/on).
>> > >>
>> > >> Currently, these key are mapped to KEY_WLAN, and KEY_BLUETOOTH/KEY_WIMAX
>> > >> are rarely used.
>> > > Is there any application support for such cycling? IOW does anyone cares
>> > > to do such cycling?
>> > On Asus laptops (both asus and eeepc) the Fn+F2 key cycle
>> > (bluetooth/wlan: on/on, on/off, off/on, off/off) on windows.
>> > On Linux, it only produces a KEY_WLAN keycode.
>> Default eee901's Xandros cycles and even shows an OSD with BT and WLAN
>> state images.
>>
>
> You are describing the visible result. Whether it is done as a custom
> policy to KEY_WLAN presses or utilizes a separate key definition - is
> not known.
Old xandros builds use the acpi event.
New builds have switched to eeepc-laptop (based on my 2.6.30
backport), so they may use an input event (KEY_WLAN).

> Anyway, we got the response form wireless developers and infrastructure
> people and thyy do not care about having a new defintion so I guess that
> settles it.
Yep

-- 
Corentin Chary
http://xf.iksaif.net

Re: [PATCH 32/33] input: add KEY_WIRELESS_CYCLE

[Matthew Garrett]

On Sun, Dec 06, 2009 at 09:21:12AM +0100, Corentin Chary wrote:

> Old xandros builds use the acpi event.
> New builds have switched to eeepc-laptop (based on my 2.6.30
> backport), so they may use an input event (KEY_WLAN).

Yeah. We should probably change that to KEY_RFKILL once that lands.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 32/33] input: add KEY_WIRELESS_CYCLE

[Henrique de Moraes Holschuh]

On Sun, 06 Dec 2009, Matthew Garrett wrote:
> On Sun, Dec 06, 2009 at 09:21:12AM +0100, Corentin Chary wrote:
> > Old xandros builds use the acpi event.
> > New builds have switched to eeepc-laptop (based on my 2.6.30
> > backport), so they may use an input event (KEY_WLAN).
> 
> Yeah. We should probably change that to KEY_RFKILL once that lands.

Depends on what is being done in userspace to the other KEY_(radio type).

What I do know, is that I will miss a keycode that rfkills just my WLAN... I
use that for power management, it is nice to have a key that is for WLAN
only, and another that is for bluetooth-only...

It is a pity KEY_RFKILL is arriving too late to avoid the loss of KEY_WLAN
(or is it?)

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

Re: [PATCH 32/33] input: add KEY_WIRELESS_CYCLE

[Matthew Garrett]

On Mon, Dec 07, 2009 at 09:47:49AM -0200, Henrique de Moraes Holschuh wrote:

> What I do know, is that I will miss a keycode that rfkills just my WLAN... I
> use that for power management, it is nice to have a key that is for WLAN
> only, and another that is for bluetooth-only...

KEY_WLAN will still be there, and you can still remap. But the default 
behaviour should be for thinkpad-acpi (for instance) to generate 
KEY_RFKILL, since Fn+F5 isn't supposed to be wlan only.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 32/33] input: add KEY_WIRELESS_CYCLE

[Henrique de Moraes Holschuh]

On Mon, 07 Dec 2009, Matthew Garrett wrote:
> On Mon, Dec 07, 2009 at 09:47:49AM -0200, Henrique de Moraes Holschuh wrote:
> > What I do know, is that I will miss a keycode that rfkills just my WLAN... I
> > use that for power management, it is nice to have a key that is for WLAN
> > only, and another that is for bluetooth-only...
> 
> KEY_WLAN will still be there, and you can still remap. But the default 
> behaviour should be for thinkpad-acpi (for instance) to generate 
> KEY_RFKILL, since Fn+F5 isn't supposed to be wlan only.

That's not what I got from this thread.  What I got was that KEY_WLAN would
be overloaded with KEY_RFKILL semanthics, regardless of anything we did in
the kernel side.

I hope I got it wrong.

I am strongly with you here: add a *new* KEY_RFKILL, fix the kernel drivers
and any eventual userspace to use the new KEY_RFKILL, and have KEY_WLAN do
what it is supposed to do.

And, if what we call KEY_WLAN is actually supposed to be KEY_RFKILL, swap
their definitions when adding KEY_RFKILL, so that USB HID devices will
generate KEY_RFKILL instead of KEY_WLAN.

It will be more work, but the end result would be superior, IMO.

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

Re: [PATCH 32/33] input: add KEY_WIRELESS_CYCLE

[Matthew Garrett]

On Mon, Dec 07, 2009 at 11:23:34AM -0200, Henrique de Moraes Holschuh wrote:
> On Mon, 07 Dec 2009, Matthew Garrett wrote:
> > On Mon, Dec 07, 2009 at 09:47:49AM -0200, Henrique de Moraes Holschuh wrote:
> > > What I do know, is that I will miss a keycode that rfkills just my WLAN... I
> > > use that for power management, it is nice to have a key that is for WLAN
> > > only, and another that is for bluetooth-only...
> > 
> > KEY_WLAN will still be there, and you can still remap. But the default 
> > behaviour should be for thinkpad-acpi (for instance) to generate 
> > KEY_RFKILL, since Fn+F5 isn't supposed to be wlan only.
> 
> That's not what I got from this thread.  What I got was that KEY_WLAN would
> be overloaded with KEY_RFKILL semanthics, regardless of anything we did in
> the kernel side.

No.

> I am strongly with you here: add a *new* KEY_RFKILL, fix the kernel drivers
> and any eventual userspace to use the new KEY_RFKILL, and have KEY_WLAN do
> what it is supposed to do.

Right. That's what the patch I sent does.

> And, if what we call KEY_WLAN is actually supposed to be KEY_RFKILL, swap
> their definitions when adding KEY_RFKILL, so that USB HID devices will
> generate KEY_RFKILL instead of KEY_WLAN.

I don't think this is in HID?

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 32/33] input: add KEY_WIRELESS_CYCLE

[Henrique de Moraes Holschuh]

On Mon, 07 Dec 2009, Matthew Garrett wrote:
> > That's not what I got from this thread.  What I got was that KEY_WLAN would
> > be overloaded with KEY_RFKILL semanthics, regardless of anything we did in
> > the kernel side.
> 
> No.

Good.

> > And, if what we call KEY_WLAN is actually supposed to be KEY_RFKILL, swap
> > their definitions when adding KEY_RFKILL, so that USB HID devices will
> > generate KEY_RFKILL instead of KEY_WLAN.
> 
> I don't think this is in HID?

I don't think it is.  I wrote that along the lines of "even if that were to
happen, there is a way to fix things properly".

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