I thought I would start a discussion on this since I have looked into it and it seems to be a faeture slated for upcoming development.
There are currently a few devices that have implemented the code to receive infrared codes (Learn IR) and then send the appropriate codes out.
The configuartion for these devices and indeed comments in the code indicate that these 'codes' would usually be in the Pronto format. Most (all?) devices to date have implemented conversion routines between their native APIs and the pronto format to achieve this.
Looking at LIRC it intentially abstracts away from the actual devices using drivers and configuration files allowing a set of named know codes that are supported. These are then utilised for both receiving and sending. In turn, the LIRC APIs for receive and send are in terms of the named codes, removing the need to know raw codes or sequences.
To fit LIRC into what we are doing currently with other infrared devices we have a couple of choices. We can stick with conversion to/from Pronto formats and find a way to do this with LIRC. This is difficult and will almost certainly involve a customised version of LIRC. There are people who have done some of the hard work here which may help with the development process.
The other option is to just store the named code that LIRC reports on receiving a signal and use this for sending when needed. This fits nicely with the LIRC API, won't require a customised version and still fits in with the linuxMCE devices. It does stop different devices interoperating however, for instance you will not be able to learn a code with USB_UIRT and send in with LIRC. The development for this mechanism is much simpler however. But this also probably means that the configuration file needs to be maintained seperately and prior to the linuxMCE learning process.
Does this all make sense, and does anyone have any comments on what path should be pursued.
Regards
Darren
