Darren Salt wrote: > I demand that Oliver Endriss may or may not have written... > > > Johannes Stezenbach wrote: > >> It would be better to use Gerd Knorr's ir-common (for av7110, too), so > >> keymaps could be manipulated using the standard EVIOCSKEYCODE ioctl, e.g. > >> by using input-kbd from Gerd Knorr's input-utils package. > > > Agreed. > > > How should we handle control data > > - RC5/RCMM selection > > - inversion setting > > if we drop /proc/av7110_ir? > > Thankfully, budget-ci doesn't have those complications... ;-) > > Should we add module parameters or keep /proc/av7110_ir just for that? > > Wouldn't this really need to be per-device? If so, these should be extra > parameters in the relevant input device directory in sysfs. (If the driver is > still meant to be 2.4-compatible, the existing method should be retained for > that at least.) Iirc EVIOC[GS]KEYCODE ioctls are not implemented in the 2.4 series. Anyway, I would keep /proc/av7110_ir for some time. > > 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. > > > Unfortunately, the input layer cannot handle sparse keymaps. > > Binding a device to one address or a subset of available addresses should > allow reduction of this somewhat - although, AFAICS, the current interface > only allows one address anyway, so if that restriction is maintained, that's > 256 bytes of keymap and one control word per device. Yes, but that's not optimal. See my other mail. Oliver -- -------------------------------------------------------- VDR Remote Plugin available at http://www.escape-edv.de/endriss/vdr/ --------------------------------------------------------
