[linux-dvb] Re: Getting IR-codes directly from DVB-S?

[Oliver Endriss <o.endriss@gmx.de>]

On Sunday 12 October 2003 16:30, Holger Waechtler wrote:
> Oliver Endriss wrote:
> > 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.

Basically we need 2 pass-through ioctls:
- set low level configuration
- get low level configuration

Each of these ioctls could have several sub-types:
- access config flags (for example: signal inversion)
- access keymap (raw addr/code <-> key code mapping)
- ...

It should be possible to read the current keymap from the device.
This way one could write something like a keymap editor, or
add another remote control to a loaded keymap.

Another feature which is really missing in the event device stuff is a
interface to read *raw* keycodes from the device. We need these if we
want to implement a keymap learning mode or a keymap editor.
Maybe we have to add this sub-function to the low-level interface, too.
With the current implementation you have to build keymaps by reading
debug messages and putting everything together manually. :-(

> > 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?

That's fine. Its easy to implement and flexible.
For transfer to/from the driver we could use something like
  struct {u32 rawaddr;  u32 rawcode; u32 keycode} keymap[]
I'd like to keep address and code in seperate fields, because different
hardware might combine address and code in a different way.
-> Different drivers may use the same keymap files.

For the keymap files (*.rc5) I suggest a syntax like this:
  address 1
  0x00 KEY_0
  0x01 KEY_1
  ...
  address 2
  ...
This way we can combine multiple devices in one keymap, which is useful
for some universal remotes. Furthermore, it is easy to change the
address only. Some remote controls have buttons like VCR1/VCR2
which might use the same keycodes but different addresses.
Finally several remote controls may be used by concatenating the
keymaps.

The device type may be identified using existing ioctls:
EVIOCGNAME, EVIOCGPHYS. Is this sufficient?

I'm not sure whether a 'get protocol types' ioctl is really useful.
For example, the full-featured DVB-S cards support RC5 and RCMM, but
most optical receivers shipped with these cards cannot receive RCMM.
There is no way to detect this in the driver.

Oliver


-- 
Info:
To unsubscribe send a mail to ecartis@linuxtv.org with "unsubscribe linux-dvb" as subject.