Em Sat, 27 Jul 2013 22:22:43 -0700 Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx> escreveu: > Hi Mauro, > > On Sat, Jul 27, 2013 at 03:06:42PM -0300, Mauro Carvalho Chehab wrote: > > Em Sat, 27 Jul 2013 10:11:53 -0300 > > Mauro Carvalho Chehab <m.chehab@xxxxxxxxxxx> escreveu: > > > > > Hi Dmitry, > > > > > > I received a new notebook those days that has an extra feature of a "Fn Lock" > > > key. > > > > > > When this key is pressed, it produces a scan code 0xa8, and the direction > > > keys (and other keys) start to produce different codes. When pressed again, > > > it produces a scan code 0xa9, and the keys return to their normal behavior. > > > > > > The input layer doesn't currently produce any EV_KEY event for those two > > > scancodes. It produces just EV_MSC events (and, of course, EV_SYN). > > > > > > I was wandering that the better would be to have a LED indicator to > > > track this, and maybe have two new keycodes, like KEY_FN_LOCK_ON and > > > KEY_FN_LOCK_OFF. > > > > > > This way, some userspace program, like mate-lockkeys-applet could be > > > presenting not only the CAPS LOCK indicator, but also the FN LOCK > > > indicator. > > > > > > Do you think it would be doable? > > Hmm, the behavior better matches a switch than a key, but we do have > quite a few key-like ON/OFF keys/switches so yes, we could add a couple > more. We could map it as a switch. Yet, there are just a couple switches left on kernel 3.10. So, if I understood well, the patch for input.h would be something like the one below, right? diff --git a/include/uapi/linux/input.h b/include/uapi/linux/input.h index d584047..13c3c79 100644 --- a/include/uapi/linux/input.h +++ b/include/uapi/linux/input.h @@ -716,6 +716,10 @@ struct input_keymap_entry { #define BTN_DPAD_LEFT 0x222 #define BTN_DPAD_RIGHT 0x223 +#define KEY_FNNLOCK_TOGGLE 0x224 /* Request switch Fn on or off */ +#define KEY_FNLOCK_ON 0x225 +#define KEY_FNLOCK_OFF 0x226 + #define BTN_TRIGGER_HAPPY 0x2c0 #define BTN_TRIGGER_HAPPY1 0x2c0 #define BTN_TRIGGER_HAPPY2 0x2c1 @@ -853,6 +857,7 @@ struct input_keymap_entry { #define SW_FRONT_PROXIMITY 0x0b /* set = front proximity sensor active */ #define SW_ROTATE_LOCK 0x0c /* set = rotate locked/disabled */ #define SW_LINEIN_INSERT 0x0d /* set = inserted */ +#define SW_FNLOCK 0x0e /* set = Fn locked */ #define SW_MAX 0x0f #define SW_CNT (SW_MAX+1) The changes at atkbd could be a little more complex, as it will require to support more than one fixups at the same time: - the release Fn fixup; - the table fixup for the two addicional keycodes; - the switch (or led) fixup. I'll work on it after we decide the better approach (either as a switch or as a LED). > > > > > > FYI, this is how this keyboard identifies itself: > > > > > > $ cat /sys/class/input/event3/device/uevent > > > PRODUCT=11/1/1/ab41 > > > NAME="AT Translated Set 2 keyboard" > > > PHYS="isa0060/serio0/input0" > > > PROP=0 > > > EV=120013 > > > KEY=500f02000403 3803078f870d001 feffffdffbefffff fffffffffffffffe > > > MSC=10 > > > LED=7 > > > MODALIAS=input:b0011v0001p0001eAB41-e0,1,4,11,14,k71,72,73,74,75,76,77,79,7A,7B,7C,7D,7E,7F,80,8C,8E,8F,94,95,96,9B,9C,9D,9E,9F,A3,A4,A5,A6,AC,AD,B7,B8,B9,C0,C1,CA,D9,E0,E1,E2,E3,EC,EE,ram4,l0,1,2,sfw > > > > > > I'm not sure if the PRODUCT there is unique, and if it could be used > > > to add this kind of extra feature to the input subsystem (or if it would > > > be just fine to add those extra features at the standard AT keyboard > > > driver, although I personally don't like this idea, as other keyboards > > > might be using scancodes 0xa8/0xa9 for other meanings). > > > > > > What do you think? > > > > Just discovered something weird while trying to write some code for > > systemd/udev: there are a few keys that only produce key down events: > > Fn + F1 (KEY_SETUP) > > Fn + F12 (KEY_WLAN) > > Fn Lock (both scan codes 0xa8 and 0xa9) > > That is not new, quite a few laptops do not bother with producing > release events. There is force_release attribute on serio ports bound to > atkbd and udev has code to manipulate it to ensure all keys are > released properly. You just need to add rule for your model. Ok, that's a trivial patch. Patch for that sent (and of course tested on the notebook). Thanks! Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html