On Sunday 12 October 2003 10:35, Holger Waechtler wrote:
Oliver Endriss wrote:
The current implementation has a number of restrictions: - Permissions of /proc/av7110_ir cannot be changed without recompiling the driver, i.e. chown/chmod do not work. - Only one keymap can be loaded for all devices.
What about loading keymaps using the ioctl interface of the event device? This would require a new evdev ioctl which could be passed to the low-level input device driver (i.e. av7110_ir.c). This way access control of the evdev driver could be used for the keymap interface, too. (I don't know whether Vojtech would accept this.)
Can you please prepare a simple patch doing this? I'm sure Vojtech will comment this and include it if it's properly implemented. Maybe you need to explain him the problem of loading RC5/RCMM keycode tables for remote controls again a little more in detail.
Let's see what he thinks about this issue. If he likes this idea, I'll prepare a patch.
Basically we need keymaps because remote controls are not really
standardized. We need a configuration interface to define the raw code <-> key code mappings, and some other parameters (device
address, signal inversion).
btw: I still believe that it's useful in some environments to load keymaps for all users at boot time -- maybe all keycode configuration ioctl's should override the default keymap which gets used until a per-user map is configured. What do you think?
Hm, per-user keymaps? I think this would be too complicated. We should not care about user-ids in the driver. The application/user which is allowed to open the event device in r/w mode, *may* load a new keymap. This keymap will simply replace the existing one.
Basically it's just a replacement for the /proc/av7110_ir interface. av7110_loadkeys can be re-written to use /dev/input/eventX ioctls.
If someone needs to load a keymap during startup, it can be done using something like post-install dvb-ttpci av7110_loadkeys xyz.rc5 -o /dev/input/event0 in /etc/modules.conf. (Basically the same way as it can be done now.)
Improvements: - Loadable keymap per device. - Application with r/w access to /dev/input/eventX may replace keymap.
sounds good so far. This would only require a new pass-through ioctl for configuration of the lowlevel driver. Maybe 2: one to request capabilities and type (a remote control receiver? which protocols can it handle, which vendor/model?) and a second one for the actual configuration.
Additionally, I'd like to implement multiple keymaps per device.
A user might want to use different remote control units, which use the
same protocol but different device addresses. In this case we need a keymap per device address.
Since some remote controls transmit on multiple device adresses I'd prefer a struct { addr, code }, the keycode table would contain the list of all keycodes on all addresses. This should be more flexible and easier to code, not?
Holger
-- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
