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

[Vojtech Pavlik <vojtech@suse.cz>]

On Mon, Oct 13, 2003 at 05:41:12AM +0200, Oliver Endriss wrote:

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

I'm not really keen on passing ioctl()s to drivers, but if there is no
other way around, then well ...

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

Well, it is currently possible to read a keymap from a keyboard via the
event interface. It doesn't efficiently handle sparse keycode tables,
though, like the remote seems to be using (address + code).

> Another feature which is really missing in the event device stuff is a
> interface to read *raw* keycodes from the device.

Indeed. That's because the abstraction is placed in the level of defined
keycodes. Since the raw codes are device specific, they should be
contained in the drivers as much as possible. However, I do see that
keymap editors will need the access to these.

At the moment it's possible to load some kind of 1:1 mapping keytable
and then look at the keycodes, and then look at what keycodes are
coming. This again doesn't handle sparse tables very well (number of
scancodes >> number of keycodes).

I'm considering to add a new 'raw' event type for this.

> 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

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR


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