From: Enrique V. <ev...@it...> - 2001-11-08 12:16:17
|
ur-soft "ur...@gm..." wrote: > > when trying to show the pulse/space values with > > mode2 on my Agenda VR3 iget the following error message > > > > agenda# mode2 --device=/dev/lirc > > read() failed Christoph Bartelmus <col...@hi...> wrote: > The Agenda VR3 does not support receiving (it didn't last > time I have looked). I have just bought one of these Agenda's and have realized that the mode2 error message is not produced if mode2 is called as: agenda# mode2 --device=/dev/ircomm However, while mode2 seems to be waiting for something, in fact nothing happens when you beem IR commands to the Agenda... Any idea or comment? Enrique. |
From: <col...@hi...> - 2001-11-10 09:30:17
|
Hi! Enrique Vidal "ev...@it..." wrote: [...] > I have just bought one of these Agenda's and have realized that > the mode2 error message is not produced if mode2 is called as: > agenda# mode2 --device=/dev/ircomm > However, while mode2 seems to be waiting for something, in fact > nothing happens when you beem IR commands to the Agenda... > Any idea or comment? IrComm is a serial port emulation protocol inside the IrDA stack. This can't work. One would have to port the lirc_sir driver to the VR3 processor. As I don't know this architecture I can't tell if this is feasable at all. Christoph |
From: Enrique V. <ev...@it...> - 2001-11-26 20:58:56
|
Hello, I have found that lirc release 0.6.3 is not fully compatible with previous release. It is neither fully compatible with the current stable lirc-0.6.4. I have been successfully working with lirc-0.6.3pre3 until now. Recently I got an Agenda VR3 palm-top Linux device that comes with lirc-0.6.3 pre-installed. So I have directly tried it with the lircd.conf file of my esktop computer. While it does work properly with the signals of most remotes, there are a few, based on RC-5-a, for which lirc-0.6.3 fails to generate proper IR signals. I have also tried to install lirc-0.6.3 on my desktop computer and it shows identical troubles with the same RC-5-a IR codes. In both cases, the driver involved is lirc_serial.o Finally I have tried the current release lirc-0.6.4 on my desktop computer and it works fine with all the remotes. The reason why I insist in lirc-0.6.3 is that it is exactly this apparently faulty release the one which comes preinstalled in all the available flash root-disks for Agenda VR3 and it does not seem to be a trivial task to patch another release (say lirc-0.6.4) and build a corresponding root disk-with it. Any idea about these difficulties? Enrique. |
From: <col...@hi...> - 2001-12-01 16:45:54
|
Hi! Enrique Vidal "ev...@it..." wrote: [...] > Any idea about these difficulties? LIRC 0.6.3pre3, 0.6.3 and 0.6.4 produce identical signals for the RC-5-a config file. So this might be a timing problem. The only problem I remember about 0.6.3 was that it generated needless lines in the log file. Try linking /var/log/lircd to /dev/null. Christoph |
From: Enrique V. <ev...@it...> - 2001-12-02 17:33:25
Attachments:
lirc-0.6.3-mail.attch
|
26/11/01: Enrique Vidal dixit: > I have found that lirc release 0.6.3 is not fully compatible > with previous release. It is neither fully compatible with > the current stable lirc-0.6.4. [...] The reason why I insist > in lirc-0.6.3 is that it is exactly this apparently faulty > release the one which comes preinstalled in all the available > flash root-disks for Agenda VR3 01/12/01: Christoph Bartelmus dixit: > LIRC 0.6.3pre3, 0.6.3 and 0.6.4 produce identical signals for > the RC-5-a config file. So this might be a timing problem. > The only problem I remember about 0.6.3 was that it generated > needless lines in the log file. Try linking /var/log/lircd > to /dev/null. Christoph, thanks for your hint! Yes, you are right, this is in fact a timing problem. However, it is not at all related with needless log writing. I have compared the lircd_serial.c code for lirc-0.6.3-pre3 and lirc-0.6.3 and nother important difference happens to be directly related with timing (see DIFF details in the attachment): lirc-0.6.3-pre3: ---------------- #define LIRC_SERIAL_TRANSMITTER_LATENCY 1 lirc-0.6.3: ----------- #if defined(__i386__) #define LIRC_SERIAL_TRANSMITTER_LATENCY 2 #else #define LIRC_SERIAL_TRANSMITTER_LATENCY 1 #endif In the case of my workstation, this is clearly the cause of the incompatibility I had reported. I have patched the lirc-0.6.3 driver so that this LATENCY is unconditionally defined as "1" and the resulting driver becomes completely compatible with lirc-0.6.3-pre3 (and with lirc-0.6.4 too). As for lirc-0.6.4, while a shorter LATENCY is also assigned if __i386__ is defined, it seems that the new, more accurate timing method used in lirc-0.6.4 do actually lead to a correct timing! Once it is clear that timing IS the problem, I have reinstalled the "official" lirc-0.6.3 lircd_serial.o driver (with LATENCY defined as "2") and I have been playing with some of the lircd.conf parameters of RC-5 remotes. Finally, by setting "frequency 34750" (rather than the standard 38000), I got these RC-5 IR commands working properly with lirc-0.6.3 Unfortunately I am not able now to check if all these facts also apply to the patched lirc-0.6.3 version that comes preinstalled in Agenda VR3 distributions, but I'll post the results as soon as I have done it. Best, Enrique. |
From: <col...@hi...> - 2001-12-04 07:10:44
|
Hi! Enrique Vidal "ev...@it..." wrote: [...] > Unfortunately I am not able now to check if all these facts also > apply to the patched lirc-0.6.3 version that comes preinstalled > in Agenda VR3 distributions, but I'll post the results as soon > as I have done it. Your analysis is correct in all but one points. The Agenda does not use the lirc_serial driver. It comes with it's own driver that is included in the kernel sources. Christoph |
From: Enrique V. <ev...@it...> - 2001-12-04 10:48:31
|
04/12/01: Christoph Bartelmus dixit: > Enrique Vidal "ev...@it..." wrote: > [...] > > Unfortunately I am not able now to check if all these facts also > > apply to the patched lirc-0.6.3 version that comes preinstalled > > in Agenda VR3 distributions, but I'll post the results as soon > > as I have done it. > > Your analysis is correct in all but one points. The Agenda does not use > the lirc_serial driver. It comes with it's own driver that is included in > the kernel sources. Thanks for this important bit of information. By looking into the Agenda VR3 lirc-0.6.3 patches, I could not understand how the driver was patched in order to include it in the kernel (rather than as a module). It is less obscure now... Clearly, I was looking into the wrong sources. It is amazing, though, that this Agenda-specific kernel driver exhibits problems which are so similar as those of the lirc-serial module of the standard lirc-0.6.3 version! Best, Enrique. |
From: <col...@hi...> - 2001-12-12 13:55:56
|
Hi! Enrique Vidal "ev...@it..." wrote: [...] >> Your analysis is correct in all but one points. The Agenda does not >> use the lirc_serial driver. It comes with it's own driver that is >> included in the kernel sources. > Thanks for this important bit of information. By looking into > the Agenda VR3 lirc-0.6.3 patches, I could not understand how the > driver was patched in order to include it in the kernel (rather > than as a module). It is less obscure now... Clearly, I was > looking into the wrong sources. > It is amazing, though, that this Agenda-specific kernel > driver exhibits problems which are so similar as those of > the lirc-serial module of the standard lirc-0.6.3 version! lirc_vrgpio.c was based on lirc_serial.c and hence has inherited it's bugs. In the meantime Steve Davies has vastly improved the lirc_serial driver accuracy. lirc_vrgpio has still the problems of the old version plus one more: 1. lirc_vrgpio still uses LIRC_SERIAL_TRANSMITTER_LATENCY although there should be no latency with the GPIO register at all which leads to wrong carrier frequncies. 2. The old send_pulse() function did not take LIRC_SERIAL_TRANSMITTER_LATENCY into account and all pulses come out too long. 3. Due to integer arithmetic you'll almost never will get an exact carrier frequency. Steve's fixed point algorithm resolved this. Christoph |
From: Enrique V. <ev...@it...> - 2001-12-17 12:27:01
|
Hi Christoph, thanks for this additional info: 12/12/01: Christoph Bartelmus dixit: > lirc_vrgpio.c was based on lirc_serial.c and hence has inherited it's > bugs. In the meantime Steve Davies has vastly improved the lirc_serial > driver accuracy. lirc_vrgpio has still the problems of the old version > plus one more: > > 1. lirc_vrgpio still uses LIRC_SERIAL_TRANSMITTER_LATENCY although there > should be no latency with the GPIO register at all which leads to wrong > carrier frequncies. > 2. The old send_pulse() function did not take > LIRC_SERIAL_TRANSMITTER_LATENCY into account and all pulses come out too > long. > 3. Due to integer arithmetic you'll almost never will get an exact carrier > frequency. Steve's fixed point algorithm resolved this. Fortunately, despite these potential problems, Agenda's lirc-0.6.3 can do a good job by adequately adjusting some lircd.conf parameters. 02/12/01: Enrique Vidal dixit: > Once it is clear that timing IS the problem, I have reinstalled > the "official" [desktop] lirc-0.6.3 lircd_serial.o driver (with > LATENCY defined as "2") and I have been playing with some of > the lircd.conf parameters of RC-5 remotes. Finally, by setting > "frequency 34750" (rather than the standard 38000), I got > these RC-5 IR commands working properly with lirc-0.6.3 > > Unfortunately I am not able now to check if all these facts also > apply to the patched lirc-0.6.3 version that comes preinstalled > in Agenda VR3 distributions, but I'll post the results as soon > as I have done it. Finally I have been able to check all this with the patched lirc-0.6.3 version (lirc_vrgpio) that comes preinstalled in Agenda VR3: As expected, the same mods to lircd.conf parameters that make the standard lirc-0.6.3 work in my desktop computer also apply to the Agenda lirc-0.6.3 version. Now it is just this nice VR3 little device that fully cares for the (rather complex) control of all (the many) audio equipments that previously needed control from my desktop! Best, Enrique. |
From: Stephen D. <st...@da...> - 2001-12-17 13:08:40
|
On Mon, 17 Dec 2001, Enrique Vidal wrote: > 12/12/01: Christoph Bartelmus dixit: > > lirc_vrgpio.c was based on lirc_serial.c and hence has inherited it's > > bugs. In the meantime Steve Davies has vastly improved the lirc_serial > > driver accuracy. lirc_vrgpio has still the problems of the old version > > plus one more: > > > > 1. lirc_vrgpio still uses LIRC_SERIAL_TRANSMITTER_LATENCY although there > > should be no latency with the GPIO register at all which leads to wrong > > carrier frequncies. > > 2. The old send_pulse() function did not take > > LIRC_SERIAL_TRANSMITTER_LATENCY into account and all pulses come out too > > long. > > 3. Due to integer arithmetic you'll almost never will get an exact carrier > > frequency. Steve's fixed point algorithm resolved this. Hey - someone send me an Agenda VR and I'll port the lirc_serial changes to that driver too ;-) Otherwise - for someone with a VR, the changes in lirc_serial should be clear and applicable for the lirc_vrgpio code (except for the use of the RDTSC instruction - but that's optional anyway). Steve |
From: Enrique V. <ev...@it...> - 2001-12-17 17:49:12
|
17/12/01: Stephen Davies dixit: > Hey - someone send me an Agenda VR and I'll port the > lirc_serial changes to that driver too ;-) These are really good news! > Otherwise - for someone with a VR, the changes in lirc_serial > should be clear and applicable for the lirc_vrgpio code [...] Sure, I'll try as soon as I have time to set up the cross-compilation tool chain as well as all the tools to build the flasheable VR3 kernels and root disks ... Enrique. |