Hi Dmitry, on 04 Dec 09 at 15:15, Dmitry Torokhov wrote: [...] >>>>>> http://lirc.sourceforge.net/remotes/lg/6711A20015N >>>>>> >>>>>> This is an air-conditioner remote. >>>>>> The entries that you see in this config file are not really separate >>>>>> buttons. Instead the remote just sends the current settings for e.g. >>>>>> temperature encoded in the protocol when you press some up/down key. >>>>>> You really don't want to map all possible temperature settings to KEY_* >>>>>> events. For such cases it would be nice to have access at the raw scan >>>>>> codes from user space to do interpretation of the data. >>>>>> The default would still be to pass the data to the input layer, but it >>>>>> won't hurt to have the possibility to access the raw data somehow. >>>> >>>>> Interesting. IMHO, the better would be to add an evdev ioctl to return >>>>> the scancode for such cases, instead of returning the keycode. >>>> >>>> That means you would have to set up a pseudo keymap, so that you can get >>>> the key event which you could than react on with a ioctl. Or are you >>>> generating KEY_UNKNOWN for every scancode that is not mapped? >>>> What if different scan codes are mapped to the same key event? How do you >>>> retrieve the scan code for the key event? >>>> I don't think it can work this way. >>>> >> >>> EV_MSC/MSC_SCAN. >> >> How would I get the 64 bit scan codes that the iMON devices generate? >> How would I know that the scan code is 64 bit? >> input_event.value is __s32. >> > I suppose we could add MSC_SCAN_END event so that we can transmit > "scancodes" of arbitrary length. You'd get several MSC_SCAN followed by > MSC_SCAN_END marker. If you don't get MSC_SCAN_END assume the code is 32 > bit. And I set a timeout to know that no MSC_SCAN_END will arrive? This is broken design IMHO. Furthermore lircd needs to know the length of the scan code in bits, not as a multiple of 32. > FWIW there is MSC_RAW as well. It took me some time to convice people that this is not the right way to handle raw timing data. Christoph -- 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
