Most laptops have keys that are intended to toggle all device state, not
just wifi. These are currently generally mapped to KEY_WLAN. As a result,
rfkill will only kill or enable wifi in response to the key press. This
confuses users and can make it difficult for them to enable bluetooth
and wwan devices.
This patch adds a new keycode, KEY_RFKILL_ALL. It indicates that the
system should toggle the state of all rfkillable devices.
Signed-off-by: Matthew Garrett <[email protected]>
---
include/linux/input.h | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/include/linux/input.h b/include/linux/input.h
index 8b3bc3e..20a622e 100644
--- a/include/linux/input.h
+++ b/include/linux/input.h
@@ -595,6 +595,8 @@ struct input_absinfo {
#define KEY_NUMERIC_STAR 0x20a
#define KEY_NUMERIC_POUND 0x20b
+#define KEY_RFKILL 0x20c /* Key that controls all radios */
+
/* We avoid low common keys in module aliases so they don't get huge. */
#define KEY_MIN_INTERESTING KEY_MUTE
#define KEY_MAX 0x2ff
--
1.6.2.5
Add support for handling KEY_RFKILL in the rfkill input module. This
simply toggles the state of all rfkill devices. The comment in rfkill.h
is also updated to reflect that RFKILL_TYPE_ALL may be used inside the
kernel.
Signed-off-by: Matthew Garrett <[email protected]>
---
include/linux/rfkill.h | 2 +-
net/rfkill/input.c | 8 ++++++++
2 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/include/linux/rfkill.h b/include/linux/rfkill.h
index 278777f..4c39f7e 100644
--- a/include/linux/rfkill.h
+++ b/include/linux/rfkill.h
@@ -32,7 +32,7 @@
/**
* enum rfkill_type - type of rfkill switch.
*
- * @RFKILL_TYPE_ALL: toggles all switches (userspace only)
+ * @RFKILL_TYPE_ALL: toggles all switches (requests only - not a switch type)
* @RFKILL_TYPE_WLAN: switch is on a 802.11 wireless network device.
* @RFKILL_TYPE_BLUETOOTH: switch is on a bluetooth device.
* @RFKILL_TYPE_UWB: switch is on a ultra wideband device.
diff --git a/net/rfkill/input.c b/net/rfkill/input.c
index a7295ad..3713d7e 100644
--- a/net/rfkill/input.c
+++ b/net/rfkill/input.c
@@ -212,6 +212,9 @@ static void rfkill_event(struct input_handle *handle, unsigned int type,
case KEY_WIMAX:
rfkill_schedule_toggle(RFKILL_TYPE_WIMAX);
break;
+ case KEY_RFKILL:
+ rfkill_schedule_toggle(RFKILL_TYPE_ALL);
+ break;
}
} else if (type == EV_SW && code == SW_RFKILL_ALL)
rfkill_schedule_evsw_rfkillall(data);
@@ -295,6 +298,11 @@ static const struct input_device_id rfkill_ids[] = {
.keybit = { [BIT_WORD(KEY_WIMAX)] = BIT_MASK(KEY_WIMAX) },
},
{
+ .flags = INPUT_DEVICE_ID_MATCH_EVBIT | INPUT_DEVICE_ID_MATCH_KEYBIT,
+ .evbit = { BIT_MASK(EV_KEY) },
+ .keybit = { [BIT_WORD(KEY_RFKILL)] = BIT_MASK(KEY_RFKILL) },
+ },
+ {
.flags = INPUT_DEVICE_ID_MATCH_EVBIT | INPUT_DEVICE_ID_MATCH_SWBIT,
.evbit = { BIT(EV_SW) },
.swbit = { [BIT_WORD(SW_RFKILL_ALL)] = BIT_MASK(SW_RFKILL_ALL) },
--
1.6.2.5
On Thu, Sep 10, 2009 at 10:21 AM, Matthew Garrett <[email protected]> wrote:
> This patch adds a new keycode, KEY_RFKILL_ALL.
> include/linux/input.h | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
> +#define KEY_RFKILL 0x20c /* Key that controls all radios */
But this above is KEY_RFKILL, not KEY_RKILL_ALL. Typo?
Luis
On Thu, Sep 10, 2009 at 10:27:01AM -0700, Luis R. Rodriguez wrote:
> On Thu, Sep 10, 2009 at 10:21 AM, Matthew Garrett <[email protected]> wrote:
>
> > This patch adds a new keycode, KEY_RFKILL_ALL.
>
> > ?include/linux/input.h | ? ?2 ++
> > ?1 files changed, 2 insertions(+), 0 deletions(-)
>
> > +#define KEY_RFKILL ? ? ? ? ? ? 0x20c /* Key that controls all radios */
>
> But this above is KEY_RFKILL, not KEY_RKILL_ALL. Typo?
Sorry, yes - forgot to update the commit message to match the change in
the patch and subject.
--
Matthew Garrett | [email protected]
On Thu, Sep 10, 2009 at 06:21:31PM +0100, Matthew Garrett wrote:
> Most laptops have keys that are intended to toggle all device state, not
> just wifi. These are currently generally mapped to KEY_WLAN. As a result,
> rfkill will only kill or enable wifi in response to the key press. This
> confuses users and can make it difficult for them to enable bluetooth
> and wwan devices.
>
> This patch adds a new keycode, KEY_RFKILL_ALL. It indicates that the
The new name in description does not match the code...
> system should toggle the state of all rfkillable devices.
Hmm, rfkill changes usually go through net tree so unless they want me
to push it though I'll just ACK the new keycode.
>
> Signed-off-by: Matthew Garrett <[email protected]>
Acked-by: Dmitry Torokhov <[email protected]>
> ---
> include/linux/input.h | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/include/linux/input.h b/include/linux/input.h
> index 8b3bc3e..20a622e 100644
> --- a/include/linux/input.h
> +++ b/include/linux/input.h
> @@ -595,6 +595,8 @@ struct input_absinfo {
> #define KEY_NUMERIC_STAR 0x20a
> #define KEY_NUMERIC_POUND 0x20b
>
> +#define KEY_RFKILL 0x20c /* Key that controls all radios */
> +
> /* We avoid low common keys in module aliases so they don't get huge. */
> #define KEY_MIN_INTERESTING KEY_MUTE
> #define KEY_MAX 0x2ff
--
Dmitry
Hi Matthew,
> Add support for handling KEY_RFKILL in the rfkill input module. This
> simply toggles the state of all rfkill devices. The comment in rfkill.h
> is also updated to reflect that RFKILL_TYPE_ALL may be used inside the
> kernel.
>
> Signed-off-by: Matthew Garrett <[email protected]>
looks good and seems to got lost somehow.
Acked-by: Marcel Holtmann <[email protected]>
Regards
Marcel
Hi Matthew,
> > Most laptops have keys that are intended to toggle all device state, not
> > just wifi. These are currently generally mapped to KEY_WLAN. As a result,
> > rfkill will only kill or enable wifi in response to the key press. This
> > confuses users and can make it difficult for them to enable bluetooth
> > and wwan devices.
> >
> > This patch adds a new keycode, KEY_RFKILL_ALL. It indicates that the
>
> The new name in description does not match the code...
>
> > system should toggle the state of all rfkillable devices.
>
> Hmm, rfkill changes usually go through net tree so unless they want me
> to push it though I'll just ACK the new keycode.
>
> >
> > Signed-off-by: Matthew Garrett <[email protected]>
>
> Acked-by: Dmitry Torokhov <[email protected]>
Acked-by: Marcel Holtmann <[email protected]>
Regards
Marcel
On Wed, Feb 17, 2010 at 7:03 PM, Matthew Garrett <[email protected]> wrote:
> On Tue, Feb 16, 2010 at 09:22:47PM -0800, Dmitry Torokhov wrote:
>
>> I'd like some breathing room aroung KEY_NUMERIC? Any issues with making
>> it 247 or 0x211?
>
> None. Do you want to make that change, or should I resubmit?
>
Wait wait... do you can get another KEY_?
The reason: Some new devices come with a WPS "Push Button".
And there's no code for them yet.
Regards, Chr.
On Wed, Feb 17, 2010 at 10:40 PM, Dmitry Torokhov
<[email protected]> wrote:
> On Feb 17, 2010, at 1:28 PM, Christian Lamparter <[email protected]>
> wrote:
>
>> On Wed, Feb 17, 2010 at 9:52 PM, Dmitry Torokhov
>> <[email protected]> wrote:
>>>
>>> Sorry, I was not clear enough. I meant something in works in Linux
>>> software
>>> stack, I was aware that certain router have these buttons already.
>>>
>>
>> wpa_supplicant and hostapd's CLI have this wps_pbc command.
>> It's more a question of: what application will get to receive the event.
>
> Right. So as soon as you have an idea about userspace consumer
> for the event ping me and I'd be glad to add a key definition for the event.
Idea? Be a bit more specific...
As a matter of fact, there are a few potential consumer in the kernel:
arm/mach-kirkwood/mv88f6281gtw_ge-setup.c:
.code = KEY_F1,
.gpio = 46,
.desc = "WPS Button(F1)",
.active_low = 1,
arm/mach-orion5x/wrt350n-v2-setup.c:
.code = KEY_WLAN,
.gpio = 2,
.desc = "WPS Button",
.active_low = 1,
and there's a lot more "out-off-tree":
https://dev.openwrt.org/browser/trunk/target/linux/ar71xx/files/arch/mips/ar71xx
mach-tew-632brp.c:
.desc = "wps",
.type = EV_KEY,
.code = BTN_1,
.threshold = 3,
.gpio = TEW_632BRP_GPIO_BTN_WPS,
carl9170:
input_set_capability(input, EV_KEY, BTN_0);
as you can see, people are using BTN_1, BTN_0, F1, WLAN (rfkill?)
as WPS Button substitute. Maybe it would be a good idea to get it right
now!
On Wed, Feb 17, 2010 at 7:45 PM, Matthew Garrett <[email protected]> wrote:
> On Wed, Feb 17, 2010 at 07:43:56PM +0100, Christian Lamparter wrote:
>
>> Wait wait... do you can get another KEY_?
>>
>> The reason: Some new devices come with a WPS "Push Button".
>> And there's no code for them yet.
>
> What's a WPS button?
The Idea of this button is to "hook up" to WPS network with a
simple push of two buttons.
(One on the AP, another one at the STA).
That's right: no SSID and no keys.
> There's no fundamental issue with getting new KEY_
> codes defined, but bear in mind that anything greater than 255 won't be
> seen by X at present.
it would be great to get the "Push" event to Network Manager/
or any other wpa_supplicant GUI du jour one day.
In the mean time, it would help to have a common scan-code
ready.
On Wed, Feb 17, 2010 at 8:17 PM, Dmitry Torokhov
<[email protected]> wrote:
> On Wed, Feb 17, 2010 at 07:43:56PM +0100, Christian Lamparter wrote:
>> The reason: Some new devices come with a WPS "Push Button".
>> And there's no code for them yet.
>>
> Yes, we can add a new key definition if you provide clear description of
> what the intended use is and if we can't map such use to any existing
> key definitions.
I found one http://en.wikipedia.org/wiki/Wi-Fi_Protected_Setup (if you
don't mind):
There's the relevant part: (PBC stands for Push Button Control/Configuration?)
"PBC Method, in which the user simply has to push a button, either an actual
or virtual one, on both the AP (or a Registrar of the Network) and the new
wireless client device (STA)
.
Support of this model is mandatory for APs and optional for STAs."
And there are already a few potential users:
OpenWRT routers as well as some rt30xx, ar9170 and ar9271 devices.
On Wed, 17 Feb 2010 12:52:06 -0800, Dmitry Torokhov
<[email protected]> wrote:
> On Feb 17, 2010, at 12:18 PM, Christian Lamparter
<[email protected]
> > wrote:
>
>> On Wed, Feb 17, 2010 at 8:54 PM, Dmitry Torokhov
>> <[email protected]> wrote:
>>>
>>> Is there anything currently in works that would make use of this
>>> button?
>>> I do not want to allocate keycode "for the future" which may never
>>> come.
>>> We did it with KEY_BATTERY but I do not think anyone actually uses
>>> it.
>>
>> Of course, there are lots of routers:
>>
>> Linksys: wrt160nl
>> Netgear: wnr2000, wndr3700
>> TP-Link: wr1043n, ... wr741nd
>> TrendNET: TEW-632BRP
>> Planex: MZK-W300NH, MZK-W04NU
>> ...
>>
>> And a few new client adapters, I know about:
>> TP-Link: WN821 v2, WN721N, WN727N
>> Netgear: WNDA3100 v2
>> ...
>>
>> (Not to mention all the coming products).
>
> Sorry, I was not clear enough. I meant something in works in Linux
> software stack, I was aware that certain router have these buttons
> already.
I know that the hostapd config file has an entire WPS section, but
have no experience using WPS, so can't speak as to how to configure
or use it. I don't know if it's planned to include support for a
push button trigger.
from hostapd.conf in git:
# Config Methods
# List of the supported configuration methods
# Available methods: usba ethernet label display ext_nfc_token
int_nfc_token
# nfc_interface push_button keypad
#config_methods=label display push_button keypad
Pat Erley
Hi Matthew,
> Add support for handling KEY_RFKILL in the rfkill input module. This
> simply toggles the state of all rfkill devices. The comment in rfkill.h
> is also updated to reflect that RFKILL_TYPE_ALL may be used inside the
> kernel.
>
> Signed-off-by: Matthew Garrett <[email protected]>
looks good.
Acked-by: Marcel Holtmann <[email protected]>
Regards
Marcel
HI Matthew,
On Tue, Feb 16, 2010 at 04:36:24PM -0500, Matthew Garrett wrote:
> Most laptops have keys that are intended to toggle all device state, not
> just wifi. These are currently generally mapped to KEY_WLAN. As a result,
> rfkill will only kill or enable wifi in response to the key press. This
> confuses users and can make it difficult for them to enable bluetooth
> and wwan devices.
>
> This patch adds a new keycode, KEY_RFKILL. It indicates that the system
> should toggle the state of all rfkillable devices.
>
> Signed-off-by: Matthew Garrett <[email protected]>
> ---
> include/linux/input.h | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/include/linux/input.h b/include/linux/input.h
> index 735ceaf..3294a89 100644
> --- a/include/linux/input.h
> +++ b/include/linux/input.h
> @@ -594,7 +594,7 @@ struct input_absinfo {
> #define KEY_NUMERIC_9 0x209
> #define KEY_NUMERIC_STAR 0x20a
> #define KEY_NUMERIC_POUND 0x20b
> -
> +#define KEY_RFKILL 0x20c /* Key that controls all radios */
> #define KEY_CAMERA_FOCUS 0x210
>
I'd like some breathing room aroung KEY_NUMERIC? Any issues with making
it 247 or 0x211?
--
Dmitry
On Wed, 17 Feb 2010, Dmitry Torokhov wrote:
> We did it with KEY_BATTERY but I do not think anyone actually uses it.
thinkpad-acpi does (in-tree).
--
"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
On Wed, Feb 17, 2010 at 11:03:08PM +0100, Christian Lamparter wrote:
> On Wed, Feb 17, 2010 at 10:40 PM, Dmitry Torokhov
> <[email protected]> wrote:
> > On Feb 17, 2010, at 1:28 PM, Christian Lamparter <[email protected]>
> > wrote:
> >
> >> On Wed, Feb 17, 2010 at 9:52 PM, Dmitry Torokhov
> >> <[email protected]> wrote:
> >>>
> >>> Sorry, I was not clear enough. I meant something in works in Linux
> >>> software
> >>> stack, I was aware that certain router have these buttons already.
> >>>
> >>
> >> wpa_supplicant and hostapd's CLI have this wps_pbc command.
> >> It's more a question of: what application will get to receive the event.
> >
> > Right. So as soon as you have an idea about userspace consumer
> > for the event ping me and I'd be glad to add a key definition for the event.
> Idea? Be a bit more specific...
>
> As a matter of fact, there are a few potential consumer in the kernel:
>
> arm/mach-kirkwood/mv88f6281gtw_ge-setup.c:
> .code = KEY_F1,
> .gpio = 46,
> .desc = "WPS Button(F1)",
> .active_low = 1,
>
> arm/mach-orion5x/wrt350n-v2-setup.c:
> .code = KEY_WLAN,
> .gpio = 2,
> .desc = "WPS Button",
> .active_low = 1,
>
>
>
>
> and there's a lot more "out-off-tree":
> https://dev.openwrt.org/browser/trunk/target/linux/ar71xx/files/arch/mips/ar71xx
>
> mach-tew-632brp.c:
> .desc = "wps",
> .type = EV_KEY,
> .code = BTN_1,
> .threshold = 3,
> .gpio = TEW_632BRP_GPIO_BTN_WPS,
>
> carl9170:
> input_set_capability(input, EV_KEY, BTN_0);
>
>
> as you can see, people are using BTN_1, BTN_0, F1, WLAN (rfkill?)
> as WPS Button substitute. Maybe it would be a good idea to get it right
> now!
I see, then I will be queueing the patch below...
--
Dmitry
Input: add KEY_WPS_BUTTON definition
The new key definition is supposed to be used for buttons that initiate
WiFi Protected Setup sequence:
http://en.wikipedia.org/wiki/Wi-Fi_Protected_Setup
Signed-off-by: Dmitry Torokhov <[email protected]>
---
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 04416f6..6825308 100644
--- a/include/linux/input.h
+++ b/include/linux/input.h
@@ -597,6 +597,7 @@ struct input_absinfo {
#define KEY_NUMERIC_POUND 0x20b
#define KEY_CAMERA_FOCUS 0x210
+#define KEY_WPS_BUTTON 0x211 /* WiFi Protected Setup key */
/* We avoid low common keys in module aliases so they don't get huge. */
#define KEY_MIN_INTERESTING KEY_MUTE
On Feb 17, 2010, at 1:28 PM, Christian Lamparter <[email protected]
> wrote:
> On Wed, Feb 17, 2010 at 9:52 PM, Dmitry Torokhov
> <[email protected]> wrote:
>>
>> Sorry, I was not clear enough. I meant something in works in Linux
>> software
>> stack, I was aware that certain router have these buttons already.
>>
>
> wpa_supplicant and hostapd's CLI have this wps_pbc command.
> It's more a question of: what application will get to receive the
> event.
Right. So as soon as you have an idea about userspace consumer for the
event ping me and I'd be glad to add a key definition for the event.
--
Dmitry
On Wed, Feb 17, 2010 at 06:49:35PM +0000, Bastien Nocera wrote:
> On Wed, 2010-02-17 at 18:45 +0000, Matthew Garrett wrote:
> > On Wed, Feb 17, 2010 at 07:43:56PM +0100, Christian Lamparter wrote:
> >
> > > Wait wait... do you can get another KEY_?
> > >
> > > The reason: Some new devices come with a WPS "Push Button".
> > > And there's no code for them yet.
> >
> > What's a WPS button? There's no fundamental issue with getting new KEY_
> > codes defined, but bear in mind that anything greater than 255 won't be
> > seen by X at present.
>
> Won't be seen by most X applications. The server should definitely see
> it, so should applications that use XInput2-aware widget sets.
>
> (Which obviously means not much at all right now).
Because XKB2 never happened we don't actually have any way of configuring
keysyms in the server for keys > 255 or getting this layout information to
the client. So XI2 applications that want to use higher keycodes are reliant
on the keycode itself which is strictly speaking random - at least the
protocol makes no guarantee that they remain fixed.
In practice that's not quite true and the keycodes are likely to remain
fixed but relying on that hurt us quite badly in the keyboard -> evdev
conversion.
Cheers,
Peter
On Wed, Feb 17, 2010 at 9:52 PM, Dmitry Torokhov
<[email protected]> wrote:
>
> Sorry, I was not clear enough. I meant something in works in Linux software
> stack, I was aware that certain router have these buttons already.
>
wpa_supplicant and hostapd's CLI have this wps_pbc command.
It's more a question of: what application will get to receive the event.
On Wed, Feb 17, 2010 at 06:03:42PM +0000, Matthew Garrett wrote:
> On Tue, Feb 16, 2010 at 09:22:47PM -0800, Dmitry Torokhov wrote:
>
> > I'd like some breathing room aroung KEY_NUMERIC? Any issues with making
> > it 247 or 0x211?
>
> None. Do you want to make that change, or should I resubmit?
>
I'll change to 247 then.
Thanks.
--
Dmitry
On Feb 17, 2010, at 12:02 PM, Matthew Garrett <[email protected]>
wrote:
> On Wed, Feb 17, 2010 at 11:54:35AM -0800, Dmitry Torokhov wrote:
>
>> Is there anything currently in works that would make use of this
>> button?
>> I do not want to allocate keycode "for the future" which may never
>> come.
>> We did it with KEY_BATTERY but I do not think anyone actually uses
>> it.
>
> KEY_BATTERY is heavily used in userspace. I think all the hardware
> that
> generates it does so via i8042 rather than a platform driver, so it
> wouldn't show up in the kernel.
>
Ah, I see. I hope the keycode is not used to signal battery status
change but to invoke battery/power manager applet...
--
Dmitry
On Wed, Feb 17, 2010 at 07:43:56PM +0100, Christian Lamparter wrote:
> On Wed, Feb 17, 2010 at 7:03 PM, Matthew Garrett <[email protected]> wrote:
> > On Tue, Feb 16, 2010 at 09:22:47PM -0800, Dmitry Torokhov wrote:
> >
> >> I'd like some breathing room aroung KEY_NUMERIC? Any issues with making
> >> it 247 or 0x211?
> >
> > None. Do you want to make that change, or should I resubmit?
> >
> Wait wait... do you can get another KEY_?
>
> The reason: Some new devices come with a WPS "Push Button".
> And there's no code for them yet.
>
Yes, we can add a new key definition if you provide clear description of
what the intended use is and if we can't map such use to any existing
key definitions.
--
Dmitry
On Wed, Feb 17, 2010 at 08:42:45PM +0100, Christian Lamparter wrote:
> On Wed, Feb 17, 2010 at 8:17 PM, Dmitry Torokhov
> <[email protected]> wrote:
> > On Wed, Feb 17, 2010 at 07:43:56PM +0100, Christian Lamparter wrote:
> >> The reason: Some new devices come with a WPS "Push Button".
> >> And there's no code for them yet.
> >>
> > Yes, we can add a new key definition if you provide clear description of
> > what the intended use is and if we can't map such use to any existing
> > key definitions.
>
> I found one http://en.wikipedia.org/wiki/Wi-Fi_Protected_Setup (if you
> don't mind):
>
> There's the relevant part: (PBC stands for Push Button Control/Configuration?)
>
> "PBC Method, in which the user simply has to push a button, either an actual
> or virtual one, on both the AP (or a Registrar of the Network) and the new
> wireless client device (STA)
> .
> Support of this model is mandatory for APs and optional for STAs."
>
> And there are already a few potential users:
> OpenWRT routers as well as some rt30xx, ar9170 and ar9271 devices.
Is there anything currently in works that would make use of this button?
I do not want to allocate keycode "for the future" which may never come.
We did it with KEY_BATTERY but I do not think anyone actually uses it.
--
Dmitry
On Thu, Feb 18, 2010 at 08:34:50AM +1000, Peter Hutterer wrote:
> On Wed, Feb 17, 2010 at 06:49:35PM +0000, Bastien Nocera wrote:
> > On Wed, 2010-02-17 at 18:45 +0000, Matthew Garrett wrote:
> > > On Wed, Feb 17, 2010 at 07:43:56PM +0100, Christian Lamparter wrote:
> > >
> > > > Wait wait... do you can get another KEY_?
> > > >
> > > > The reason: Some new devices come with a WPS "Push Button".
> > > > And there's no code for them yet.
> > >
> > > What's a WPS button? There's no fundamental issue with getting new KEY_
> > > codes defined, but bear in mind that anything greater than 255 won't be
> > > seen by X at present.
> >
> > Won't be seen by most X applications. The server should definitely see
> > it, so should applications that use XInput2-aware widget sets.
> >
> > (Which obviously means not much at all right now).
>
> Because XKB2 never happened we don't actually have any way of configuring
> keysyms in the server for keys > 255 or getting this layout information to
> the client. So XI2 applications that want to use higher keycodes are reliant
> on the keycode itself which is strictly speaking random - at least the
> protocol makes no guarantee that they remain fixed.
>
> In practice that's not quite true and the keycodes are likely to remain
> fixed but relying on that hurt us quite badly in the keyboard -> evdev
> conversion.
>
FWIW the event codes defines in linux/input.h form ABI and thus will not
be changed (exception is adding aliases better describing intended key
usage, such as KEY_COFFEE -> KEY_SCREENLOCK).
--
Dmitry
On Wed, Feb 17, 2010 at 12:49:14PM -0800, Dmitry Torokhov wrote:
> On Feb 17, 2010, at 12:02 PM, Matthew Garrett <[email protected]>
> wrote:
>> KEY_BATTERY is heavily used in userspace. I think all the hardware
>> that
>> generates it does so via i8042 rather than a platform driver, so it
>> wouldn't show up in the kernel.
>>
>
> Ah, I see. I hope the keycode is not used to signal battery status
> change but to invoke battery/power manager applet...
Correct. On Gnome, at least, it pops up a dialog with the current
battery state.
--
Matthew Garrett | [email protected]
On Feb 17, 2010, at 12:18 PM, Christian Lamparter <[email protected]
> wrote:
> On Wed, Feb 17, 2010 at 8:54 PM, Dmitry Torokhov
> <[email protected]> wrote:
>>
>> Is there anything currently in works that would make use of this
>> button?
>> I do not want to allocate keycode "for the future" which may never
>> come.
>> We did it with KEY_BATTERY but I do not think anyone actually uses
>> it.
>
> Of course, there are lots of routers:
>
> Linksys: wrt160nl
> Netgear: wnr2000, wndr3700
> TP-Link: wr1043n, ... wr741nd
> TrendNET: TEW-632BRP
> Planex: MZK-W300NH, MZK-W04NU
> ...
>
> And a few new client adapters, I know about:
> TP-Link: WN821 v2, WN721N, WN727N
> Netgear: WNDA3100 v2
> ...
>
> (Not to mention all the coming products).
Sorry, I was not clear enough. I meant something in works in Linux
software stack, I was aware that certain router have these buttons
already.
--
Dmitry
On Wed, Feb 17, 2010 at 07:43:56PM +0100, Christian Lamparter wrote:
> Wait wait... do you can get another KEY_?
>
> The reason: Some new devices come with a WPS "Push Button".
> And there's no code for them yet.
What's a WPS button? There's no fundamental issue with getting new KEY_
codes defined, but bear in mind that anything greater than 255 won't be
seen by X at present.
--
Matthew Garrett | [email protected]
On Wed, Feb 17, 2010 at 11:54:35AM -0800, Dmitry Torokhov wrote:
> Is there anything currently in works that would make use of this button?
> I do not want to allocate keycode "for the future" which may never come.
> We did it with KEY_BATTERY but I do not think anyone actually uses it.
KEY_BATTERY is heavily used in userspace. I think all the hardware that
generates it does so via i8042 rather than a platform driver, so it
wouldn't show up in the kernel.
--
Matthew Garrett | [email protected]
On Tue, Feb 16, 2010 at 09:22:47PM -0800, Dmitry Torokhov wrote:
> I'd like some breathing room aroung KEY_NUMERIC? Any issues with making
> it 247 or 0x211?
None. Do you want to make that change, or should I resubmit?
--
Matthew Garrett | [email protected]
Hi Matthew,
> Most laptops have keys that are intended to toggle all device state, not
> just wifi. These are currently generally mapped to KEY_WLAN. As a result,
> rfkill will only kill or enable wifi in response to the key press. This
> confuses users and can make it difficult for them to enable bluetooth
> and wwan devices.
>
> This patch adds a new keycode, KEY_RFKILL. It indicates that the system
> should toggle the state of all rfkillable devices.
>
> Signed-off-by: Matthew Garrett <[email protected]>
Acked-by: Marcel Holtmann <[email protected]>
Regards
Marcel
On Wed, Feb 17, 2010 at 08:16:37PM -0800, Dmitry Torokhov wrote:
> On Thu, Feb 18, 2010 at 08:34:50AM +1000, Peter Hutterer wrote:
> > On Wed, Feb 17, 2010 at 06:49:35PM +0000, Bastien Nocera wrote:
> > > On Wed, 2010-02-17 at 18:45 +0000, Matthew Garrett wrote:
> > > > On Wed, Feb 17, 2010 at 07:43:56PM +0100, Christian Lamparter wrote:
> > > >
> > > > > Wait wait... do you can get another KEY_?
> > > > >
> > > > > The reason: Some new devices come with a WPS "Push Button".
> > > > > And there's no code for them yet.
> > > >
> > > > What's a WPS button? There's no fundamental issue with getting new KEY_
> > > > codes defined, but bear in mind that anything greater than 255 won't be
> > > > seen by X at present.
> > >
> > > Won't be seen by most X applications. The server should definitely see
> > > it, so should applications that use XInput2-aware widget sets.
> > >
> > > (Which obviously means not much at all right now).
> >
> > Because XKB2 never happened we don't actually have any way of configuring
> > keysyms in the server for keys > 255 or getting this layout information to
> > the client. So XI2 applications that want to use higher keycodes are reliant
> > on the keycode itself which is strictly speaking random - at least the
> > protocol makes no guarantee that they remain fixed.
> >
> > In practice that's not quite true and the keycodes are likely to remain
> > fixed but relying on that hurt us quite badly in the keyboard -> evdev
> > conversion.
> >
>
> FWIW the event codes defines in linux/input.h form ABI and thus will not
> be changed (exception is adding aliases better describing intended key
> usage, such as KEY_COFFEE -> KEY_SCREENLOCK).
of course. the problem that would arise is that if a driver starts using a
different source for keycodes - such as happend when we changed from the old
keyboard driver to evdev. for years the keycodes remained the same and
applications relied on them. when we then started using evdev as the
keyboard driver a number of keycodes changed and some apps misbehaved.
(you may remember the Up/PrintScreen issues).
It is in fact still somewhat of an issue if you're using evdev and the kbd
driver at the same time - though the sensible use-cases for this scenario
are somewhat narrow.
Relying on keycodes - even if they're abi - is generally dangerous as it
circumvents the keyboard layouts configured by the users. After some talks
to our input methods guys it was shown that some input methods only work on
a qwerty layout but break rather badly on a azerty layout. And an anecdote
from our office - a password generator dongle started typing in wrong
passwords when it was accidentally configured with dvorak instead of qwerty.
Since the dongle could only send keycodes - which were then converted into
the keysyms depending on the layout - some of the passwords didn't match up
anymore.
So - for client applications to rely on keycodes is a time-bomb, we really
need to get our act together and allow for 32-bit keycode layout
configuration in X.
Cheers,
Peter
On Wed, 2010-02-17 at 18:45 +0000, Matthew Garrett wrote:
> On Wed, Feb 17, 2010 at 07:43:56PM +0100, Christian Lamparter wrote:
>
> > Wait wait... do you can get another KEY_?
> >
> > The reason: Some new devices come with a WPS "Push Button".
> > And there's no code for them yet.
>
> What's a WPS button? There's no fundamental issue with getting new KEY_
> codes defined, but bear in mind that anything greater than 255 won't be
> seen by X at present.
Won't be seen by most X applications. The server should definitely see
it, so should applications that use XInput2-aware widget sets.
(Which obviously means not much at all right now).
On Wed, Feb 17, 2010 at 8:54 PM, Dmitry Torokhov
<[email protected]> wrote:
>
> Is there anything currently in works that would make use of this button?
> I do not want to allocate keycode "for the future" which may never come.
> We did it with KEY_BATTERY but I do not think anyone actually uses it.
Of course, there are lots of routers:
Linksys: wrt160nl
Netgear: wnr2000, wndr3700
TP-Link: wr1043n, ... wr741nd
TrendNET: TEW-632BRP
Planex: MZK-W300NH, MZK-W04NU
...
And a few new client adapters, I know about:
TP-Link: WN821 v2, WN721N, WN727N
Netgear: WNDA3100 v2
...
(Not to mention all the coming products).