From: Andrei G. <and...@gm...> - 2014-03-23 03:10:31
|
Hello, I've built an IR receiver that is seen as serial port by computer (/dev/tty<something> device in Linux). It sends LIRC_MODE_MODE2 commands through the serial port. Is there an easy way to make it work with lirc? Can you point me to documentation on how to add support for new receiver devices? Thanks, Andrei. |
From: Andrei G. <and...@gm...> - 2014-05-20 15:57:21
|
Hello, I've built an IR receiver that is seen as serial port by computer (/dev/tty<something> device in Linux). It sends LIRC_MODE_MODE2 commands through the virtual serial port. Is there an easy way to make it work with lirc? Can you point me to documentation on how to add support for new receiver devices? Thanks, Andrei. |
From: Alec L. <lea...@gm...> - 2014-05-20 18:13:57
|
On 2014-03-23 04:10, Andrei Grigorev wrote: > Hello, > > I've built an IR receiver that is seen as serial port by computer > (/dev/tty<something> device in Linux). It sends LIRC_MODE_MODE2 > commands through the serial port. Is there an easy way to make it work > with lirc? Can you point me to documentation on how to add support for > new receiver devices? > Well, if you have a kernel driver sending data through a /dev/tty? device you should really be able to use lirc 'as-is'. I haven't done anything like this myself, but I think the first step should be to use the mode2 tool which reads lirc data from a given device and displays it. It has a manpage, but I'm afraid that's it. Once this works you have a perfectly normal lirc setup. You could e. g., use the new Configuration Guide in the manual (available in the 0.9.1pre3 release) to setup the rest. --alec |
From: Alec L. <lea...@gm...> - 2014-05-21 07:51:36
|
On 2014-05-21 04:10, Andrei Grigorev wrote: > > On Tue, May 20, 2014 at 9:19 AM, Alec Leamas <lea...@gm... > <mailto:lea...@gm...>> wrote: > > On 2014-03-23 04:10, Andrei Grigorev wrote: > > Hello, > > I've built an IR receiver that is seen as serial port by > computer (/dev/tty<something> device in Linux). It sends > LIRC_MODE_MODE2 commands through the serial port. Is there an > easy way to make it work with lirc? Can you point me to > documentation on how to add support for new receiver devices? > > Well, if you have a kernel driver sending data through a /dev/tty? > device you should really be able to use lirc 'as-is'. I haven't > done anything like this myself, but I think the first step should > be to use the mode2 tool which reads lirc data from a given device > and displays it. It has a manpage, but I'm afraid that's it. > > > A little more details: it's a USB device it uses generic USB ACM > driver and seen in the system as /dev/ttyACM0. > If I do something like > cat /dev/ttyACM0 >~/data.bin > then press some buttons on remote, then check the contents of the > data.bin file I see something like this: > > 0000000000: FF FF FF 00 5B 23 00 01 │ 47 11 00 00 75 02 00 01 > 0000000010: 47 06 00 00 74 02 00 01 │ F9 01 00 00 72 02 00 01 > 0000000020: 49 06 00 00 8D 02 00 01 │ E0 01 00 00 72 02 00 01 > 0000000030: FB 01 00 00 74 02 00 01 │ F9 01 00 00 8D 02 00 01 > > Now, if I run mode2 I am getting this: > > # mode2 -d /dev/ttyACM0 > mode2: could not get hardware features > mode2: this device driver does not support the LIRC ioctl interface > mode2: major number of /dev/ttyACM0 is 166 > mode2: make sure /dev/ttyACM0 is a LIRC device and use a current > version of the driver > > How exactly am I supposed to run mode2 to have it read from device as > expected? > By not giving any --driver option to mode2 you are using the lirc 'default' userspace driver. This driver expects the device to be a regular kernel device implementing the standard lirc ioctl commands. What you see here is that your device does not meet these expectations of the default driver. The exact answer how to handle this is beyond my lirc certification :) That said, the way I see it there are two routes: The first would be to implement the missing ioctl commands in your kernel driver. This way your device would be generally useful both for lirc and for other sw such as the kernel decoding. The main definitions of these are in the file lirc.h which belongs to the kernel source (this is a bug[1]) and is bundled by the lirc distribution under include/. Unfortunately, there is not really any documentation I',m aware of on this; you would have to look into the kernel source to find examples. The other route would be to write an lirc userspace driver which can cope with your non-standard device. Again, here is not much documentation and you would have to look into the lirc source to find usable examples. Once this works you could use 'mode2 --device /dev/ttyACM0 --driver <your new driver>' . In any case you probably want to rebuild lirc with debug enabled and turn on the debug printouts using --debug Cheers! --alec [1] https://bugzilla.kernel.org/show_bug.cgi?id=75751 |
From: Alec L. <lea...@gm...> - 2014-06-08 18:58:53
|
On 06/08/2014 08:43 PM, Andrei Grigorev wrote: [cut] > > Can't even clone: > > $ git clone -b lirc-0_9_1-pre1-branch git://git.code.sf.net/p/lirc/git > <http://git.code.sf.net/p/lirc/git> lirc-git > Cloning into 'lirc-git'... > fatal: Remote branch lirc-0_9_1-pre1-branch not found in upstream origin > Sorry, that was both a typo and another error (I'm building too many versions of this by now). Fresh log: 1003 git clone -b lirc-0_9_1pre1-branch git://git.code.sf.net/p/lirc/git lirc-git 1004 cd lirc-git 1005 ./autogen.sh 1006 ./configure --enable-debug --with-syslog --with-driver=userspace 1007 make |
From: Alec L. <lea...@gm...> - 2014-06-08 19:25:49
|
On 06/08/2014 09:05 PM, Andrei Grigorev wrote: > > On Sun, Jun 8, 2014 at 11:58 AM, Alec Leamas <lea...@gm... > <mailto:lea...@gm...>> wrote: > > Sorry, that was both a typo and another error (I'm building too > many versions of this by now). Fresh log: > > 1003 git clone -b lirc-0_9_1pre1-branch > git://git.code.sf.net/p/lirc/git > <http://git.code.sf.net/p/lirc/git> lirc-git > 1004 cd lirc-git > 1005 ./autogen.sh > 1006 ./configure --enable-debug --with-syslog > --with-driver=userspace > 1007 make > > > Thanks, but I still get the same error after running autogen.sh: > > # ./autogen.sh > libtoolize: putting auxiliary files in `.'. > libtoolize: copying file `./ltmain.sh' > libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'. > libtoolize: copying file `m4/libtool.m4' > libtoolize: copying file `m4/ltoptions.m4' > libtoolize: copying file `m4/ltsugar.m4' > libtoolize: copying file `m4/ltversion.m4' > libtoolize: copying file `m4/lt~obsolete.m4' > configure.ac:56 <http://configure.ac:56>: error: possibly undefined > macro: AC_DEFINE > If this token and others are legitimate, please use > m4_pattern_allow. > See the Autoconf documentation. > autoreconf: /usr/bin/autoconf failed with exit status: 1 > > Am I missing some dependencies? > > Thanks, > Andrei. Hm... havn't seen this one before. google tells me that it might be related to a missing pkg-config package (in particular, /usr/share/aclocal/pkg.m4). Is this any help? --alec |
From: Alec L. <lea...@gm...> - 2014-06-09 04:11:56
|
On 06/08/2014 09:59 PM, Andrei Grigorev wrote: > > [cut] > > > > Yes, you are right! Thank you, now configure fails with this: > > configure: error: *** you need to have the Linux kernel source installed > for this drive > > and I do have kernel sources installed. > > Anyway, configure --with-driver=userspace builds, it should be enough > for me at the moment. > There is also the with-kerneldir configure option that handles the situation when the kernel sources can't be located But using --with-driver=userspace is really the recommended method with this release. cheers! --alec |