On Mon, Dec 19, 2005, Oliver Endriss wrote: > Johannes Stezenbach wrote: > > On Sun, Dec 18, 2005, Oliver Endriss wrote: > > > RC5+ uses 5 bit addresses and 7 bit data. > > > If we put the address bits in the keymap we end up with a > > > 2^12 * 2 = 8 KByte keymap for each device. > > > > Couldn't one mask out the address bits in the driver > > before calling ir_input_keydown()? (Probably after > > matching with the correct address?) > > Sure, that's the way it is done in av7110_ir.c right now. > > As a consequence, there are limitations: > > - There is no easy way to read back the address of a raw code. > In the application you either have to disable address matching, or you > must prompt the user to hold down a key while you cycle through all > possible addresses. Reporting of raw keycodes isn't done in any of the remote control drivers, or is it? drivers/input/keyboard/atkbd.c uses input_event(atkbd->dev, EV_MSC, MSC_RAW, codea) and also input_event(atkbd->dev, EV_MSC, MSC_SCAN, code);, where "code" is an int. > - Some remote controls use two different addresses. If the address is not > part of the raw code two keys might be mapped to the same code. > Otherwise it works only if you disable address matching. This is not an > option if you have another rc5 device in the same room... > Because of that some users had to patch the driver. > > Imho the new implementation must be more flexible and easier to use than > the old one. If the address is not part of the raw code there is no real > improvement. :-( ACK > > > Unfortunetely, the input layer cannot handle sparse keymaps. > > > > Fortunately it's OpenSource ;-) so you could fix it. > > Unfortunately, digging through the input layer is not on my todo list. > Iirc the EVIOC[GS]KEYCODE routines access the keymap array directly. > I'll ask Vojtech whether this can be fixed by adding an - optional - > keymap routine. Sounds good. Johannes
