* Samsung series 5 ultra keyboard @ 2013-07-27 13:11 Mauro Carvalho Chehab 2013-07-27 18:06 ` Mauro Carvalho Chehab 0 siblings, 1 reply; 4+ messages in thread From: Mauro Carvalho Chehab @ 2013-07-27 13:11 UTC (permalink / raw) To: Dmitry Torokhov; +Cc: linux-input, Mauro Carvalho Chehab 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? 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? Thanks! Mauro ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Samsung series 5 ultra keyboard 2013-07-27 13:11 Samsung series 5 ultra keyboard Mauro Carvalho Chehab @ 2013-07-27 18:06 ` Mauro Carvalho Chehab 2013-07-28 5:22 ` Dmitry Torokhov 0 siblings, 1 reply; 4+ messages in thread From: Mauro Carvalho Chehab @ 2013-07-27 18:06 UTC (permalink / raw) To: Dmitry Torokhov; +Cc: linux-input Em Sat, 27 Jul 2013 10:11:53 -0300 Mauro Carvalho Chehab <m.chehab@samsung.com> 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? > > 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) See: # ir-keytable -d /dev/input/event3 -t Testing events. Please, press CTRL-C to abort. 1374948216.879719: event type EV_MSC(0x04): scancode = 0xce 1374948216.879719: event type EV_KEY(0x01) key_down: KEY_SETUP(0x0001) 1374948216.879719: event type EV_SYN(0x00). 1374948218.420177: event type EV_MSC(0x04): scancode = 0xce 1374948218.420177: event type EV_KEY(0x01) key_down: KEY_SETUP(0x0001) 1374948218.420177: event type EV_SYN(0x00). 1374948219.362185: event type EV_MSC(0x04): scancode = 0x89 1374948219.362185: event type EV_KEY(0x01) key_down: KEY_BRIGHTNESSDOWN(0x0001) 1374948219.362185: event type EV_SYN(0x00). 1374948219.362218: event type EV_KEY(0x01) key_up: KEY_BRIGHTNESSDOWN(0x0001) 1374948219.362218: event type EV_SYN(0x00). 1374948222.746160: event type EV_MSC(0x04): scancode = 0xce 1374948222.746160: event type EV_KEY(0x01) key_down: KEY_SETUP(0x0001) 1374948222.746160: event type EV_SYN(0x00). 1374948223.348321: event type EV_MSC(0x04): scancode = 0x89 1374948223.348321: event type EV_KEY(0x01) key_down: KEY_BRIGHTNESSDOWN(0x0001) 1374948223.348321: event type EV_SYN(0x00). 1374948223.348356: event type EV_KEY(0x01) key_up: KEY_BRIGHTNESSDOWN(0x0001) 1374948223.348356: event type EV_SYN(0x00). 1374948224.864993: event type EV_MSC(0x04): scancode = 0xce 1374948224.864993: event type EV_KEY(0x01) key_down: KEY_SETUP(0x0001) 1374948224.864993: event type EV_SYN(0x00). 1374948227.762895: event type EV_MSC(0x04): scancode = 0x82 1374948227.762895: event type EV_KEY(0x01) key_down: KEY_SWITCHVIDEOMODE(0x0001) 1374948227.762895: event type EV_SYN(0x00). 1374948227.762930: event type EV_KEY(0x01) key_up: KEY_SWITCHVIDEOMODE(0x0001) 1374948227.762930: event type EV_SYN(0x00). 1374948229.212478: event type EV_MSC(0x04): scancode = 0x82 1374948229.212478: event type EV_KEY(0x01) key_down: KEY_SWITCHVIDEOMODE(0x0001) 1374948229.212478: event type EV_SYN(0x00). 1374948229.212513: event type EV_KEY(0x01) key_up: KEY_SWITCHVIDEOMODE(0x0001) 1374948229.212513: event type EV_SYN(0x00). 1374948232.961500: event type EV_MSC(0x04): scancode = 0xd5 1374948232.961500: event type EV_KEY(0x01) key_down: KEY_WLAN(0x0001) 1374948232.961500: event type EV_SYN(0x00). 1374948234.377876: event type EV_MSC(0x04): scancode = 0xd5 1374948234.377876: event type EV_KEY(0x01) key_down: KEY_WLAN(0x0001) 1374948234.377876: event type EV_SYN(0x00). 1374948235.090077: event type EV_MSC(0x04): scancode = 0xa8 1374948235.090077: event type EV_KEY(0x01) key_down: KEY_PROG1(0x0001) 1374948235.090077: event type EV_SYN(0x00). 1374948236.650001: event type EV_MSC(0x04): scancode = 0xa9 1374948236.650001: event type EV_KEY(0x01) key_down: KEY_PROG2(0x0001) 1374948236.650001: event type EV_SYN(0x00). 1374948237.094992: event type EV_MSC(0x04): scancode = 0xb7 1374948237.094992: event type EV_KEY(0x01) key_down: KEY_SYSRQ(0x0001) 1374948237.094992: event type EV_SYN(0x00). 1374948237.213233: event type EV_MSC(0x04): scancode = 0xb7 1374948237.213233: event type EV_KEY(0x01) key_up: KEY_SYSRQ(0x0001) 1374948237.213233: event type EV_SYN(0x00). 1374948247.126649: event type EV_MSC(0x04): scancode = 0xb7 1374948247.126649: event type EV_KEY(0x01) key_down: KEY_SYSRQ(0x0001) 1374948247.126649: event type EV_SYN(0x00). 1374948247.299130: event type EV_MSC(0x04): scancode = 0xb7 1374948247.299130: event type EV_KEY(0x01) key_up: KEY_SYSRQ(0x0001) 1374948247.299130: event type EV_SYN(0x00). 1374948249.158131: event type EV_MSC(0x04): scancode = 0xb7 1374948249.158131: event type EV_KEY(0x01) key_down: KEY_SYSRQ(0x0001) 1374948249.158131: event type EV_SYN(0x00). 1374948249.294389: event type EV_MSC(0x04): scancode = 0xb7 1374948249.294389: event type EV_KEY(0x01) key_up: KEY_SYSRQ(0x0001) 1374948249.294389: event type EV_SYN(0x00). 1374948250.904246: event type EV_MSC(0x04): scancode = 0xa8 1374948250.904246: event type EV_KEY(0x01) key_down: KEY_PROG1(0x0001) 1374948250.904246: event type EV_SYN(0x00). 1374948252.938739: event type EV_MSC(0x04): scancode = 0xa9 1374948252.938739: event type EV_KEY(0x01) key_down: KEY_PROG2(0x0001) 1374948252.938739: event type EV_SYN(0x00). So, perhaps some quirk will be needed at the Kernel driver to artificially produce KEYUP events for those scancodes. Cheers, Mauro ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Samsung series 5 ultra keyboard 2013-07-27 18:06 ` Mauro Carvalho Chehab @ 2013-07-28 5:22 ` Dmitry Torokhov 2013-07-28 10:45 ` Mauro Carvalho Chehab 0 siblings, 1 reply; 4+ messages in thread From: Dmitry Torokhov @ 2013-07-28 5:22 UTC (permalink / raw) To: Mauro Carvalho Chehab; +Cc: linux-input 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@samsung.com> 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. > > > > 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. Thanks, Dmitry -- Dmitry ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Samsung series 5 ultra keyboard 2013-07-28 5:22 ` Dmitry Torokhov @ 2013-07-28 10:45 ` Mauro Carvalho Chehab 0 siblings, 0 replies; 4+ messages in thread From: Mauro Carvalho Chehab @ 2013-07-28 10:45 UTC (permalink / raw) To: Dmitry Torokhov; +Cc: linux-input Em Sat, 27 Jul 2013 22:22:43 -0700 Dmitry Torokhov <dmitry.torokhov@gmail.com> 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@samsung.com> 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 ^ permalink raw reply related [flat|nested] 4+ messages in thread
end of thread, other threads:[~2013-07-28 10:45 UTC | newest] Thread overview: 4+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2013-07-27 13:11 Samsung series 5 ultra keyboard Mauro Carvalho Chehab 2013-07-27 18:06 ` Mauro Carvalho Chehab 2013-07-28 5:22 ` Dmitry Torokhov 2013-07-28 10:45 ` Mauro Carvalho Chehab
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).