From: Alec Leamas <leamas.alec@gm...>  20140102 14:42:13

On 20140102 14:32, Paul Gration wrote: > > On Wed, Jan 1, 2014 at 3:36 PM, Alec Leamas <leamas.alec@... > <mailto:leamas.alec@...>> wrote: > > On 20131230 21:14, Marco wrote: > > also compatible to BN5901015A (shipped with UExxC6500 TV) > > tested with TV UE40C6500. > > Config found at lircconfig.commandir.com > <http://lircconfig.commandir.com>; > > plus Special Service Buttons "FACTORY" and "3SPEED" found at > > forum.samygo.tv <http://forum.samygo.tv>; > > > > begin remote > > name BN5901039A > > bits 16 > > flags SPACE_ENCCONST_LENGTH > > eps 30 > > aeps 100 > > header 4579 4465 > > one 609 1637 > > zero 609 514 > > ptrail 609 > > gap 108231 > > pre_data_bits 16 > > pre_data 0xE0E0 > > > > begin codes > > power 0x40BF > > source 0x807F > > 1 0x20DF > > 2 0xA05F > > 3 0x609F > > 4 0x10EF > > 5 0x906F > > 6 0x50AF > > 7 0x30CF > > 8 0xB04F > > 9 0x708F > > 0 0x8877 > > ttx 0x34CB > > prech 0xC837 > > mute 0xF00F > > chlist 0xD629 > > vol+ 0xE01F > > vol 0xD02F > > p+ 0x48B7 > > p 0x08F7 > > menu 0x58A7 > > content 0x9E61 > > guide 0xF20D > > tools 0xD22D > > info 0xF807 > > up 0x06F9 > > down 0x8679 > > left 0xA659 > > right 0x46B9 > > ok 0x16E9 > > return 0x1AE5 > > exit 0xB44B > > a 0x36C9 > > b 0x28D7 > > c 0xA857 > > d 0x6897 > > media.p 0x31CE > > internet 0xC936 > > dual 0x00FF > > ad 0xE41B > > p.size 0x7C83 > > subst 0xA45B > > rew 0xA25D > > ff 0x12ED > > pause 0x52AD > > rec 0x926D > > play 0xE21D > > stop 0x629D > > factory 0xDC23 > > 3speed 0x3CC3 > > > > end codes > > > > end remote  > > > > [cut] > Messages like this should always be welcome. > > That said, it would be even more welcome if the configuration was > updated to use the proper symbols within the namespace e. g., using > KEY_NUMERIC_1 .. KEY_NUMERIC_9, KEY_VOLUMEUP etc. i. e., the symbols > listed by irrecord l. Standardizing the symbols makes is so much > easier to reuse .lircrc files and/or to use the kernel built in > decoding > if it would be implemented later. > > alec > > > Alec, would KEY_NUMERIC_1 be preferred to KEY_1 from the namespace? > And do you / anyone else know if there is there an intended difference > for these? Ouch... I dived into this some time ago. To be frank I only remember my conclusion at that point was to use KEY_NUMERIC_1 etc, not the reasons behind. Trying to reevaluate:  Whatever we use, trying to stick to one of these forms would of course be the best.  The KEY_NUMERIC_ corresponds to the buttons on the numeric keyboard whereas the KEY_1 etc corresponds to a the regular QWERTY keys on a standard PC keyboard.  One could argue that a remote is closer to a numeric keyboard than to a standard keyboard.  OTOH, a simple search in current remotes reveals 72 uses of KEY_1 vs just 2 of KEY_NUMERIC_1.  The kernel builtin decoding seems to use KEY_1..KEY_9 [1]. I'm pretty sure this is a more complete picture than what I had last time. A tentative conclusion would be to use KEY_1 etc in new configs, trying to stay consistent with most existing ones and also the kernel builtin decoding. Or? alec [1] http://lxr.linux.no/#linux+v3.12.6/drivers/media/rc/irmce_kbddecoder.c 