lirc_serial loads but does not work (Gutsy 7.10 + Hardy 8.04)

The case is much more complicated than I thought. Today I had to install an Ubuntu Server Version. Cause it is not much work I tried out the lirc package - and it worked with the same serial IR-receiver (which failed on the epia board).
This evening I tried it out with the workstation-version on same modell, other machine and its also working.

So it is a combination of Epia MII 12000 with Gutsy (Feisty works), seems to be a very special problem on this kind of hardware. VIA again - without words......

Thanks for your work !

Klaus

I also have this problem. My hardware is a Dell Inspiron D610 - the built-in IrDA port.

It always worked just fine in Feisty, but I've had no luck at all in Gutsy. I've also tried a fresh install of Hardy Alpha 3, and while the setup is now even easier (it handles setserial for you), I still can't get any reception from the port.

See the thread here: http://ubuntuforums.org/showthread.php?t=662991 for my woes.

I would also add that under Feisty (it worked then) I was running a 2.6.22 kernel from Gutsy (for my DVB card). This leads me to believe that it's not a kernel version issue - although it could be the lirc modules.

I was also using the current versions of the Gutsy packages, and obviously I'm running the latest Hardy development packages currently.

I've had the same problem.

Very repeatable: Install packages for lirc on fresh install of gutsy, create config files, no output. Remove packages, download SVN, compile, reuse same config files (and same kernel, etc) and success.

It seems a bug was introduced into 0.8.2 and continues to exist in 0.8.3pre1 (current package for hardy). In SVN this problem has been resolved. LIRC has very limited functionality and an upgrade for hardy is strongly recommended.

Andrew,
Can you find the particular patch that resolves things? It's unfortunately a bit of a 'to-do' to update these kinds of things.

Mario,

I don't know where to find the patch. I just know that by updating to latest
SVN the problem is resolved. This effects many users especially considering
the rising popularity of MythBuntu, etc.

How else can I help with this? I understand this package is particularly
difficult as I tried to compile it myself and failed.

Thanks for the quick response!

On 3/19/08, Mario Limonciello <email address hidden> wrote:
>
> Andrew,
> Can you find the particular patch that resolves things? It's
> unfortunately a bit of a 'to-do' to update these kinds of things.
>
>
> --
> lirc_serial loads but does not work (Gutsy 7.10 + Hardy 8.04)
> https://bugs.launchpad.net/bugs/182530
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
Andrew Barbaccia
MonolithMC Sales & Support
(631) 865 - 1025

Andrew,
The best way to help would be to look at lirc cvs and identify which
change in its history is the most likely solution.

On the other hand, if this is entirely broken for all people, I
suppose we can just update this one module to cvs head provided it
doesn't depend on any new functionality outside of its single source
file.

Mario Limonciello
<email address hidden>
Sent from my iPod Touch

On Mar 19, 2008, at 22:02, Andrew Barbaccia <email address hidden>
wrote:

> Mario,
>
> I don't know where to find the patch. I just know that by updating
> to latest
> SVN the problem is resolved. This effects many users especially
> considering
> the rising popularity of MythBuntu, etc.
>
> How else can I help with this? I understand this package is
> particularly
> difficult as I tried to compile it myself and failed.
>
> Thanks for the quick response!
>
> On 3/19/08, Mario Limonciello <email address hidden> wrote:
>>
>> Andrew,
>> Can you find the particular patch that resolves things? It's
>> unfortunately a bit of a 'to-do' to update these kinds of things.
>>
>>
>> --
>> lirc_serial loads but does not work (Gutsy 7.10 + Hardy 8.04)
>> https://bugs.launchpad.net/bugs/182530
>> You received this bug notification because you are a direct
>> subscriber
>> of the bug.
>>
>
>
> --
> Andrew Barbaccia
> MonolithMC Sales & Support
> (631) 865 - 1025
>
> --
> lirc_serial loads but does not work (Gutsy 7.10 + Hardy 8.04)
> https://bugs.launchpad.net/bugs/182530
> You received this bug notification because you are a member of MythTV
> Ubuntu Maintainers, which is subscribed to lirc in ubuntu.

<top-posting>
lirc_serial works for me.
</top-posting>

Mario Limonciello wrote:
> Andrew,
> The best way to help would be to look at lirc cvs and identify which
> change in its history is the most likely solution.
>
> On the other hand, if this is entirely broken for all people, I
> suppose we can just update this one module to cvs head provided it
> doesn't depend on any new functionality outside of its single source
> file.
>
> Mario Limonciello
> <email address hidden>
> Sent from my iPod Touch
>
> On Mar 19, 2008, at 22:02, Andrew Barbaccia <email address hidden>
> wrote:
>
>
>> Mario,
>>
>> I don't know where to find the patch. I just know that by updating
>> to latest
>> SVN the problem is resolved. This effects many users especially
>> considering
>> the rising popularity of MythBuntu, etc.
>>
>> How else can I help with this? I understand this package is
>> particularly
>> difficult as I tried to compile it myself and failed.
>>
>> Thanks for the quick response!
>>
>> On 3/19/08, Mario Limonciello <email address hidden> wrote:
>>
>>> Andrew,
>>> Can you find the particular patch that resolves things? It's
>>> unfortunately a bit of a 'to-do' to update these kinds of things.
>>>
>>>
>>> --
>>> lirc_serial loads but does not work (Gutsy 7.10 + Hardy 8.04)
>>> https://bugs.launchpad.net/bugs/182530
>>> You received this bug notification because you are a direct
>>> subscriber
>>> of the bug.
>>>
>>>
>> --
>> Andrew Barbaccia
>> MonolithMC Sales & Support
>> (631) 865 - 1025
>>
>> --
>> lirc_serial loads but does not work (Gutsy 7.10 + Hardy 8.04)
>> https://bugs.launchpad.net/bugs/182530
>> You received this bug notification because you are a member of MythTV
>> Ubuntu Maintainers, which is subscribed to lirc in ubuntu.
>>
>
>

laga,

are you testing actually sending packets using lirc_serial and not just
loading the module? From the software POV things seem fine, but the actual
hardware output is not what is anticipated. Additionally, this is true for
lirc_pvr150 irblaster module.

i'm curious to what is different.

Are you not supposed to top post?

On 3/20/08, laga <email address hidden> wrote:
>
> <top-posting>
> lirc_serial works for me.
> </top-posting>
>
>
> Mario Limonciello wrote:
> > Andrew,
> > The best way to help would be to look at lirc cvs and identify which
> > change in its history is the most likely solution.
> >
> > On the other hand, if this is entirely broken for all people, I
> > suppose we can just update this one module to cvs head provided it
> > doesn't depend on any new functionality outside of its single source
> > file.
> >
> > Mario Limonciello
> > <email address hidden>
> > Sent from my iPod Touch
> >
> > On Mar 19, 2008, at 22:02, Andrew Barbaccia <email address hidden>
> > wrote:
> >
> >
> >> Mario,
> >>
> >> I don't know where to find the patch. I just know that by updating
> >> to latest
> >> SVN the problem is resolved. This effects many users especially
> >> considering
> >> the rising popularity of MythBuntu, etc.
> >>
> >> How else can I help with this? I understand this package is
> >> particularly
> >> difficult as I tried to compile it myself and failed.
> >>
> >> Thanks for the quick response!
> >>
> >> On 3/19/08, Mario Limonciello <email address hidden> wrote:
> >>
> >>> Andrew,
> >>> Can you find the particular patch that resolves things? It's
> >>> unfortunately a bit of a 'to-do' to update these kinds of things.
> >>>
> >>>
> >>> --
> >>> lirc_serial loads but does not work (Gutsy 7.10 + Hardy 8.04)
> >>> https://bugs.launchpad.net/bugs/182530
> >>> You received this bug notification because you are a direct
> >>> subscriber
> >>> of the bug.
> >>>
> >>>
> >> --
> >> Andrew Barbaccia
> >> MonolithMC Sales & Support
> >> (631) 865 - 1025
> >>
> >> --
> >> lirc_serial loads but does not work (Gutsy 7.10 + Hardy 8.04)
> >> https://bugs.launchpad.net/bugs/182530
> >> You received this bug notification because you are a member of MythTV
> >> Ubuntu Maintainers, which is subscribed to lirc in ubuntu.
> >>
> >
> >
>
> --
> lirc_serial loads but does not work (Gutsy 7.10 + Hardy 8.04)
> https://bugs.launchpad.net/bugs/182530
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
Andrew Barbaccia
MonolithMC Sales & Support
(631) 865 - 1025

Andrew,

are you talking about _sending_ IR signals? If so, then I must have missed something.. I didn't read the whole thread before replying this morning. But yes, *receiving* IR signals using lirc_serial works for me.

I'm not sure if top-posting or bottom-posting is preferred on launchpad, I'm just not used to seeing top-posting :)

Okay, good. Because I was starting to get worried here...

Sending signals with lirc 0.8.3pre1 seems to be broken. I did another test
this morning using the lirc_pvr150 device. Again, with the same result.
Software reports success yet packets being transmitted are malformed and not
producing the correct response. Testing on SVN would change my cable box
with the same configuration file.

I tried to browse CVS or find changelogs but was not successful. I believe a
recompile of this should be considered for hardy since it was also broken in
gutsy and no patch was submitted. Without transmission, using the lirc
package for IR Blasters is not an option.

On 3/20/08, laga <email address hidden> wrote:
>
> Andrew,
>
> are you talking about _sending_ IR signals? If so, then I must have
> missed something.. I didn't read the whole thread before replying this
> morning. But yes, *receiving* IR signals using lirc_serial works for me.
>
> I'm not sure if top-posting or bottom-posting is preferred on launchpad,
> I'm just not used to seeing top-posting :)
>
>
> --
>
> lirc_serial loads but does not work (Gutsy 7.10 + Hardy 8.04)
> https://bugs.launchpad.net/bugs/182530
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
Andrew Barbaccia
MonolithMC Sales & Support
(631) 865 - 1025

Andrew,
If pvr150 doesn't work too, this sounds like it may be an entirely
different concern...

Mario Limonciello
<email address hidden>
Sent from my iPod Touch

On Mar 20, 2008, at 8:22, Andrew Barbaccia <email address hidden>
wrote:

> Okay, good. Because I was starting to get worried here...
>
> Sending signals with lirc 0.8.3pre1 seems to be broken. I did
> another test
> this morning using the lirc_pvr150 device. Again, with the same
> result.
> Software reports success yet packets being transmitted are malformed
> and not
> producing the correct response. Testing on SVN would change my cable
> box
> with the same configuration file.
>
> I tried to browse CVS or find changelogs but was not successful. I
> believe a
> recompile of this should be considered for hardy since it was also
> broken in
> gutsy and no patch was submitted. Without transmission, using the lirc
> package for IR Blasters is not an option.
>
> On 3/20/08, laga <email address hidden> wrote:
>>
>> Andrew,
>>
>> are you talking about _sending_ IR signals? If so, then I must have
>> missed something.. I didn't read the whole thread before replying
>> this
>> morning. But yes, *receiving* IR signals using lirc_serial works
>> for me.
>>
>> I'm not sure if top-posting or bottom-posting is preferred on
>> launchpad,
>> I'm just not used to seeing top-posting :)
>>
>>
>> --
>>
>> lirc_serial loads but does not work (Gutsy 7.10 + Hardy 8.04)
>> https://bugs.launchpad.net/bugs/182530
>> You received this bug notification because you are a direct
>> subscriber
>> of the bug.
>>
>
>
> --
> Andrew Barbaccia
> MonolithMC Sales & Support
> (631) 865 - 1025
>
> --
> lirc_serial loads but does not work (Gutsy 7.10 + Hardy 8.04)
> https://bugs.launchpad.net/bugs/182530
> You received this bug notification because you are a member of MythTV
> Ubuntu Maintainers, which is subscribed to lirc in ubuntu.

I believe it is a bug in lircd or a related library, not the lirc_serial
module. It's existent on all the transmission hardware i have tested and
have access to (pvr150, serial).

To ensure that it is in the lirc source and not just a packaging problem, I
recompiled 0.8.3pre1 in the same manner as I did with CVS with the same
results:

0.8.3pre1 -- no output
CVS -- success

On 3/20/08, Mario Limonciello <email address hidden> wrote:
>
> Andrew,
> If pvr150 doesn't work too, this sounds like it may be an entirely
> different concern...
>
>
> Mario Limonciello
> <email address hidden>
> Sent from my iPod Touch
>
>
> On Mar 20, 2008, at 8:22, Andrew Barbaccia <email address hidden>
> wrote:
>
>
> > Okay, good. Because I was starting to get worried here...
> >
> > Sending signals with lirc 0.8.3pre1 seems to be broken. I did
> > another test
> > this morning using the lirc_pvr150 device. Again, with the same
> > result.
> > Software reports success yet packets being transmitted are malformed
> > and not
> > producing the correct response. Testing on SVN would change my cable
> > box
> > with the same configuration file.
> >
> > I tried to browse CVS or find changelogs but was not successful. I
> > believe a
> > recompile of this should be considered for hardy since it was also
> > broken in
> > gutsy and no patch was submitted. Without transmission, using the lirc
> > package for IR Blasters is not an option.
> >
> > On 3/20/08, laga <email address hidden> wrote:
> >>
> >> Andrew,
> >>
> >> are you talking about _sending_ IR signals? If so, then I must have
> >> missed something.. I didn't read the whole thread before replying
> >> this
> >> morning. But yes, *receiving* IR signals using lirc_serial works
> >> for me.
> >>
> >> I'm not sure if top-posting or bottom-posting is preferred on
> >> launchpad,
> >> I'm just not used to seeing top-posting :)
> >>
> >>
> >> --
> >>
> >> lirc_serial loads but does not work (Gutsy 7.10 + Hardy 8.04)
> >> https://bugs.launchpad.net/bugs/182530
> >> You received this bug notification because you are a direct
> >> subscriber
> >> of the bug.
> >>
> >
> >
> > --
> > Andrew Barbaccia
> > MonolithMC Sales & Support
> > (631) 865 - 1025
> >
>
> > --
>
> > lirc_serial loads but does not work (Gutsy 7.10 + Hardy 8.04)
> > https://bugs.launchpad.net/bugs/182530
>
> > You received this bug notification because you are a member of MythTV
> > Ubuntu Maintainers, which is subscribed to lirc in ubuntu.
>
> --
>
> lirc_serial loads but does not work (Gutsy 7.10 + Hardy 8.04)
> https://bugs.launchpad.net/bugs/182530
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
Andrew Barbaccia
MonolithMC Sales & Support
(631) 865 - 1025

For me it is receiving signals from my remote control that does not work. Both lirc_sir and lirc_serial do not work with my hardware.

I'd prefer not to have to compile and install the CVS version, but at least this gives me hope that the bug has been fixed in the lirc package.

Pete,

That could be a configuration problem because laga reported lirc_serial as
working for receivers earlier in this exact bug.

On 3/20/08, Pete Woods <email address hidden> wrote:
>
> For me it is receiving signals from my remote control that does not
> work. Both lirc_sir and lirc_serial do not work with my hardware.
>
> I'd prefer not to have to compile and install the CVS version, but at
> least this gives me hope that the bug has been fixed in the lirc
> package.
>
>
> --
>
> lirc_serial loads but does not work (Gutsy 7.10 + Hardy 8.04)
> https://bugs.launchpad.net/bugs/182530
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
Andrew Barbaccia
MonolithMC Sales & Support
(631) 865 - 1025

Unfortunately it's not my configuration that's wrong. The exact same configuration works fine on Feisty, but fails under Gutsy and Hardy. I have exactly the same issues as the original poster and have tried a large number of different configurations.

Pete Woods wrote:
> For me it is receiving signals from my remote control that does not
> work. Both lirc_sir and lirc_serial do not work with my hardware.
>
> I'd prefer not to have to compile and install the CVS version, but at
> least this gives me hope that the bug has been fixed in the lirc
> package.
>
>

Pete,
what version of LIRC are you using? I know that lirc_serial (supposedly)
didn't work correctly in Ubuntu Gutsy, but the current one in Hardy
works fine for me (0.8.3~pre1-0ubuntu6).

Oops, I missed your last reply.. what does dmesg say about your receiver?

In hardy, mine says this:

[ 68.314418] lirc_dev: IR Remote Control driver registered, at major 61
[ 68.829633] lirc_serial: auto-detected active low receiver
[ 68.829639] lirc_dev: lirc_register_plugin: sample_rate: 0

Well I'm back on Gutsy now on the current ubuntu lirc release, as XBMC works properly on it. When I was on Hardy lirc didn't work either, I'm guessing that I was on the latest version 0.8.3pre1.

On all different versions the module reports it loads correctly, and dmesg shows the same as yours. There's more info in the thread I linked.

Here is some more information about what is going on. I am running lirc-0.8.2-0ubuntu8. I have used the graphical tool to configure the hardware.conf file. I have told it I have a built-in IR port (I selected SIR driver). I have copied the MCE remote lircd.conf file into /etc/lirc/lircd.conf

This is the SiR driver loading:

[ 1164.188000] lirc_dev: IR Remote Control driver registered, at major 61
[ 1164.212000] lirc_dev: lirc_register_plugin: sample_rate: 0
[ 1164.212000] lirc_sir: I/O port 0x03e8, IRQ 4.
[ 1164.212000] lirc_sir: Installed.

This is the output in /var/log/daemon.log during when I run the xmode2 program:

Mar 22 11:41:08 CD-ISV06M1288 lircd-0.8.2[25771]: lircd(userspace) ready
Mar 22 11:41:51 CD-ISV06M1288 lircd-0.8.2[25771]: accepted new client on /dev/lircd
Mar 22 11:41:59 CD-ISV06M1288 lircd-0.8.2[25771]: removed client

If I run the xmode2 program (gksudo 'xmode2 -d /dev/lirc0') pointing the remote at the IrDA port and pressing buttons produces nothing.

Yet more info (hope this isn't getting too much)

'ls -l /dev/lir*' produces:
crw-rw---- 1 root root 61, 0 2008-03-22 11:34 /dev/lirc0
srw-rw-rw- 1 root root 0 2008-03-22 11:41 /dev/lircd

Running gksudo 'xmode2 -d /dev/lircd' as opposed to gksudo 'xmode2 -d /dev/lirc0' produces:
xmode2: No such device or address
xmode2: error opening /dev/lircd

COM1 (IRQ 4) is definitely the right port for it to be looking at.

Something I just noticed. 0x03e8 is not the io parameter that I'm specifying in /etc/modprobe.d/lirc

I'm specifying 0x03f8. If I load the module manually with irq=4 io=0x03f8 then the thing works! Is there some step I'm not performing after setting the modprobe.d option?

Pete,

Again, I think this is something to do with your configuration settings
rather than the lirc package itself.

This bug is trying to address the lack of transmission support in the
current lirc package.

On Sun, Mar 23, 2008 at 12:32 PM, Andrew Barbaccia <email address hidden>
wrote:

>
>
> Regards,
> Andrew J Barbaccia
>
> On Mar 23, 2008, at 12:12 PM, Pete Woods <launchpad.net@pete-
> woods.com> wrote:
>
> > Something I just noticed. 0x03e8 is not the io parameter that I'm
> > specifying in /etc/modprobe.d/lirc
> >
> > I'm specifying 0x03f8. If I load the module manually with irq=4
> > io=0x03f8 then the thing works! Is there some step I'm not performing
> > after setting the modprobe.d option?
> >
> > --
> > lirc_serial loads but does not work (Gutsy 7.10 + Hardy 8.04)
> > https://bugs.launchpad.net/bugs/182530
> > You received this bug notification because you are a direct subscriber
> > of the bug.
>

--
Andrew Barbaccia
MonolithMC Sales & Support
(631) 865 - 1025

I'm starting to think this is more of a configuration problem with the
package than it is with the actual software code itself.

I cannot test the response of my cable box because I am not home (and was
way to lazy this morning to try and setup a webcam server, etc).

I have the blaster pointed at my remote receiver (they run at the same Hz).
I ran mode2 to capture the signals and tested sending from the serial
module. I pasted the output as a chart into this email, i can attach it if
the formatting is bad.

I'm not sure what to make of this and want to test the response directly to
the cable box when I return home because that will give me more
comprehensible output (I'm just guessing which each of these pulses
translates to).

This is all pointing back to the options that the package was compiled with.
We'll have to dig further into this tonight. Let me know your thoughts.

  lirc packages compiled source space 16777215 space 16777215 pulse 128 pulse
128 space 871862 space 10112 pulse 128 pulse 128 space 6784 space
3456 pulse
128 pulse 128 space 14976 space 2514024 pulse 128 pulse 384 space 1664 space
1967593 pulse 128 pulse 128 space 1664 space 21888 pulse 128 pulse
128 space
1664 space 3809816 pulse 128 pulse 384 space 30080 space 3200 pulse
128 pulse
128 space 2742245 space 3200 pulse 128 pulse 128 space 3200 space
3200 pulse
384 pulse 128 space 3200 space 3200 pulse 384 pulse 128 space 3200 space
896 pulse 128 pulse 128 space 4992 space 640 pulse 128 pulse 384 space
13440 space 640 pulse 128 pulse 128 space 21888 space 2432 pulse 128 pulse
128 space 2940641 space 640 pulse 128 pulse 384 space 6528 space 2432 pulse
384 pulse 128 space 3200 space 1664 pulse 384 pulse 128 space 640 space
1664 pulse 128 pulse 128 space 2432 space 11648 pulse 128 pulse 128 space
882037 space 4001943 pulse 128 pulse 128 space 2407849 space 6784 pulse
384 pulse 128 space 6528 space 3672924 pulse 128 pulse 384 space 18304 space
6528 pulse 128 pulse 128 space 14976 space 3200 pulse 128 pulse 128 space
13440 space 8320 pulse 128 pulse 128 space 8320 space 4992 pulse 128 pulse
128 space 969396 space 38528 pulse 128 pulse 128 space 2687852
 pulse 128
 space 135864
 pulse 128
 space 3200
 pulse 384
 space 3200
 pulse 384
 space 3200
 pulse 128
 space 896
 pulse 128
 space 2432
 pulse 128
 space 640
 pulse 128
 space 896
 pulse 128
 space 3200
 pulse 128
 space 3200
 pulse 128
 space 4992
 pulse 128
 space 13440
 pulse 128
 space 6528
 pulse 128

On Sun, Mar 23, 2008 at 2:07 PM, Andrew Barbaccia <email address hidden>
wrote:

> Pete,
>
> Again, I think this is something to do with your configuration settings
> rather than the lirc package itself.
>
> This bug is trying to address the lack of transmission support in the
> current lirc package.
>
>
> On Sun, Mar 23, 2008 at 12:32 PM, Andrew Barbaccia <email address hidden>
> wrote:
>
> >
> >
> > Regards,
> > Andrew J Barbaccia
> >
> > On Mar 23, 2008, at 12:12 PM, Pete Woods <launchpad.net@pete-
> > woods.com> wrote:
> >
> > > Something I just noticed. 0x03e8 is not the io parameter that I'm
> > > specifying in /etc/modprobe.d/lirc
> > >
> > > I'm speci...

Progress.

So I compiled from source on this box like I normally had in the past and
the lirc_serial device was not working as planned. Doing a little checkup I
found that it was still loading the old lirc_serial modules...very odd. I
thought they would be replaced. I moved the folder and ran a depmod and then
make install. Success.

So the patches we tested before I assume did not actually replace the
modules that were loading. I have removed all modules from the system and am
going to patch the 0.8.3pre1 packages and build them again. Hopefully later
tonight.

On Mon, Mar 24, 2008 at 12:02 PM, Andrew Barbaccia <email address hidden>
wrote:

> I'm starting to think this is more of a configuration problem with the
> package than it is with the actual software code itself.
>
> I cannot test the response of my cable box because I am not home (and was
> way to lazy this morning to try and setup a webcam server, etc).
>
> I have the blaster pointed at my remote receiver (they run at the same
> Hz). I ran mode2 to capture the signals and tested sending from the serial
> module. I pasted the output as a chart into this email, i can attach it if
> the formatting is bad.
>
> I'm not sure what to make of this and want to test the response directly
> to the cable box when I return home because that will give me more
> comprehensible output (I'm just guessing which each of these pulses
> translates to).
>
> This is all pointing back to the options that the package was compiled
> with. We'll have to dig further into this tonight. Let me know your
> thoughts.
>
> lirc packages compiled source space 16777215 space 16777215 pulse 128 pulse
> 128 space 871862 space 10112 pulse 128 pulse 128 space 6784 space 3456 pulse
> 128 pulse 128 space 14976 space 2514024 pulse 128 pulse 384 space 1664 space
> 1967593 pulse 128 pulse 128 space 1664 space 21888 pulse 128 pulse 128 space
> 1664 space 3809816 pulse 128 pulse 384 space 30080 space 3200 pulse 128 pulse
> 128 space 2742245 space 3200 pulse 128 pulse 128 space 3200 space 3200 pulse
> 384 pulse 128 space 3200 space 3200 pulse 384 pulse 128 space 3200 space
> 896 pulse 128 pulse 128 space 4992 space 640 pulse 128 pulse 384 space
> 13440 space 640 pulse 128 pulse 128 space 21888 space 2432 pulse 128 pulse
> 128 space 2940641 space 640 pulse 128 pulse 384 space 6528 space 2432 pulse
> 384 pulse 128 space 3200 space 1664 pulse 384 pulse 128 space 640 space
> 1664 pulse 128 pulse 128 space 2432 space 11648 pulse 128 pulse 128 space
> 882037 space 4001943 pulse 128 pulse 128 space 2407849 space 6784 pulse
> 384 pulse 128 space 6528 space 3672924 pulse 128 pulse 384 space 18304 space
> 6528 pulse 128 pulse 128 space 14976 space 3200 pulse 128 pulse 128 space
> 13440 space 8320 pulse 128 pulse 128 space 8320 space 4992 pulse 128 pulse
> 128 space 969396 space 38528 pulse 128 pulse 128 space 2687852
> pulse 128
> space 135864
> pulse 128
> space 3200
> pulse 384
> space 3200
> pulse 384
> space 3200
> pulse 128
> space 896
> pulse 128
> space 2432
> pulse 128
> space 640
> pulse 128
> space 896
> pulse 128
> space 3200
> pulse 128
> space 320...

So it's not in the modules, it is, it's not, it is. I hate when things go in circles like this :) Hopefully we'll get to the bottom of this soon.

So here's my plan of action. Let me know your thoughts:

nstall lirc0.8.3pre1 from source and test sending via lirc_serial
this will determine if it is the package or the source that is broken. if it
works, then we need to find the differences in the build options to get it
building correctly. if it fails, we need to find the patch between pre1 and
cvs that corrects the problem and apply.
Test patches on pre1 SOURCE (not package) until we narrow down which patch
makes the fix
Once the patch is determined then we can go ahead and fix the current
package and push it to hardy.

On Mon, Mar 24, 2008 at 8:32 PM, Mario Limonciello <email address hidden>
wrote:

> So it's not in the modules, it is, it's not, it is. I hate when things
> go in circles like this :) Hopefully we'll get to the bottom of this
> soon.
>
> --
> lirc_serial loads but does not work (Gutsy 7.10 + Hardy 8.04)
> https://bugs.launchpad.net/bugs/182530
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
Andrew Barbaccia
MonolithMC Sales & Support
(631) 865 - 1025

Andrew,

Sounds like a sensible plan of action, but I see a point for failure. There
is a handful of 2.6.24 patches that came after 0.8.3~pre1.

Maybe the better idea is to apt-get source lirc, and then dpatch apply-all.
Run the standard build process (configure/make not debuild) to make sure
nothing in the build system that we have on top is breaking it.

On Tue, Mar 25, 2008 at 12:37 PM, Andrew Barbaccia <email address hidden>
wrote:

> So here's my plan of action. Let me know your thoughts:
>
> nstall lirc0.8.3pre1 from source and test sending via lirc_serial
> this will determine if it is the package or the source that is broken. if
> it
> works, then we need to find the differences in the build options to get it
> building correctly. if it fails, we need to find the patch between pre1
> and
> cvs that corrects the problem and apply.
> Test patches on pre1 SOURCE (not package) until we narrow down which patch
> makes the fix
> Once the patch is determined then we can go ahead and fix the current
> package and push it to hardy.
>
> On Mon, Mar 24, 2008 at 8:32 PM, Mario Limonciello <email address hidden>
> wrote:
>
> > So it's not in the modules, it is, it's not, it is. I hate when things
> > go in circles like this :) Hopefully we'll get to the bottom of this
> > soon.
> >
> > --
> > lirc_serial loads but does not work (Gutsy 7.10 + Hardy 8.04)
> > https://bugs.launchpad.net/bugs/182530
> > You received this bug notification because you are a direct subscriber
> > of the bug.
> >
>
>
> --
> Andrew Barbaccia
> MonolithMC Sales & Support
> (631) 865 - 1025
>
> --
> lirc_serial loads but does not work (Gutsy 7.10 + Hardy 8.04)
> https://bugs.launchpad.net/bugs/182530
> You received this bug notification because you are a member of MythTV
> Ubuntu Maintainers, which is subscribed to lirc in ubuntu.
>

--
Mario Limonciello
<email address hidden>

err. that's actually what i am in the process of doing right now. building
lirc0.8.3pre1 seems to be more difficult than cvs (since it is not using
automake?)

Also, trying to install the lirc-modules-source from your repository does
not complete. I'm left with this error:

You must run a dkms build for kernel 2.6.24-12-generic (i686) first.
Done.

Any advice?

On Tue, Mar 25, 2008 at 2:53 PM, Mario Limonciello <email address hidden>
wrote:

> Andrew,
>
> Sounds like a sensible plan of action, but I see a point for failure.
> There
> is a handful of 2.6.24 patches that came after 0.8.3~pre1.
>
> Maybe the better idea is to apt-get source lirc, and then dpatch
> apply-all.
> Run the standard build process (configure/make not debuild) to make sure
> nothing in the build system that we have on top is breaking it.
>
> On Tue, Mar 25, 2008 at 12:37 PM, Andrew Barbaccia <email address hidden>
> wrote:
>
> > So here's my plan of action. Let me know your thoughts:
> >
> > nstall lirc0.8.3pre1 from source and test sending via lirc_serial
> > this will determine if it is the package or the source that is broken.
> if
> > it
> > works, then we need to find the differences in the build options to get
> it
> > building correctly. if it fails, we need to find the patch between pre1
> > and
> > cvs that corrects the problem and apply.
> > Test patches on pre1 SOURCE (not package) until we narrow down which
> patch
> > makes the fix
> > Once the patch is determined then we can go ahead and fix the current
> > package and push it to hardy.
> >
> > On Mon, Mar 24, 2008 at 8:32 PM, Mario Limonciello <email address hidden>
> > wrote:
> >
> > > So it's not in the modules, it is, it's not, it is. I hate when
> things
> > > go in circles like this :) Hopefully we'll get to the bottom of this
> > > soon.
> > >
> > > --
> > > lirc_serial loads but does not work (Gutsy 7.10 + Hardy 8.04)
> > > https://bugs.launchpad.net/bugs/182530
> > > You received this bug notification because you are a direct subscriber
> > > of the bug.
> > >
> >
> >
> > --
> > Andrew Barbaccia
> > MonolithMC Sales & Support
> > (631) 865 - 1025
> >
> > --
> > lirc_serial loads but does not work (Gutsy 7.10 + Hardy 8.04)
> > https://bugs.launchpad.net/bugs/182530
> > You received this bug notification because you are a member of MythTV
> > Ubuntu Maintainers, which is subscribed to lirc in ubuntu.
> >
>
>
> --
> Mario Limonciello
> <email address hidden>
>
> --
> lirc_serial loads but does not work (Gutsy 7.10 + Hardy 8.04)
> https://bugs.launchpad.net/bugs/182530
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
Andrew Barbaccia
MonolithMC Sales & Support
(631) 865 - 1025

Andrew,

This is likely a side effect of switching versions between different repos.
Please purge (apt-get remove --purge $PACKAGE) all instances of
lirc-modules-source before installing a new one.

On Tue, Mar 25, 2008 at 2:03 PM, Andrew Barbaccia <email address hidden>
wrote:

> err. that's actually what i am in the process of doing right now. building
> lirc0.8.3pre1 seems to be more difficult than cvs (since it is not using
> automake?)
>
> Also, trying to install the lirc-modules-source from your repository does
> not complete. I'm left with this error:
>
> You must run a dkms build for kernel 2.6.24-12-generic (i686) first.
> Done.
>
> Any advice?
>
> On Tue, Mar 25, 2008 at 2:53 PM, Mario Limonciello <email address hidden>
> wrote:
>
> > Andrew,
> >
> > Sounds like a sensible plan of action, but I see a point for failure.
> > There
> > is a handful of 2.6.24 patches that came after 0.8.3~pre1.
> >
> > Maybe the better idea is to apt-get source lirc, and then dpatch
> > apply-all.
> > Run the standard build process (configure/make not debuild) to make sure
> > nothing in the build system that we have on top is breaking it.
> >
> > On Tue, Mar 25, 2008 at 12:37 PM, Andrew Barbaccia <
> <email address hidden>>
> > wrote:
> >
> > > So here's my plan of action. Let me know your thoughts:
> > >
> > > nstall lirc0.8.3pre1 from source and test sending via lirc_serial
> > > this will determine if it is the package or the source that is broken.
> > if
> > > it
> > > works, then we need to find the differences in the build options to
> get
> > it
> > > building correctly. if it fails, we need to find the patch between
> pre1
> > > and
> > > cvs that corrects the problem and apply.
> > > Test patches on pre1 SOURCE (not package) until we narrow down which
> > patch
> > > makes the fix
> > > Once the patch is determined then we can go ahead and fix the current
> > > package and push it to hardy.
> > >
> > > On Mon, Mar 24, 2008 at 8:32 PM, Mario Limonciello <<email address hidden>
> >
> > > wrote:
> > >
> > > > So it's not in the modules, it is, it's not, it is. I hate when
> > things
> > > > go in circles like this :) Hopefully we'll get to the bottom of
> this
> > > > soon.
> > > >
> > > > --
> > > > lirc_serial loads but does not work (Gutsy 7.10 + Hardy 8.04)
> > > > https://bugs.launchpad.net/bugs/182530
> > > > You received this bug notification because you are a direct
> subscriber
> > > > of the bug.
> > > >
> > >
> > >
> > > --
> > > Andrew Barbaccia
> > > MonolithMC Sales & Support
> > > (631) 865 - 1025
> > >
> > > --
> > > lirc_serial loads but does not work (Gutsy 7.10 + Hardy 8.04)
> > > https://bugs.launchpad.net/bugs/182530
> > > You received this bug notification because you are a member of MythTV
> > > Ubuntu Maintainers, which is subscribed to lirc in ubuntu.
> > >
> >
> >
> > --
> > Mario Limonciello
> > <email address hidden>
> >
> > --
> > lirc_serial loads but does not work (Gutsy 7.10 + Hardy 8.04)
> > https://bugs.launchpad.net/bugs/182530
> > You received this bug notification because you are a direct subscriber
> > of the bug.
> >
>
>
> --
> Andrew Barbaccia
> MonolithMC Sales & Support
> (631) 865 - 1025
>
> --
> lirc_serial loa...

The problem is not with lirc but with the ubuntu package configuration.

debian/modules-source/lirc-modules-source.conf needs the following adjustments:

add -DLIRC_SERIAL_SOFTCARRIER
fix LIRC_SERIAL_PORT and LIRC_SERIAL_IRQ to use ttyS0

diff is attached.

Thanks mario and laga for the help in fixing this one.

I had to add softcarrier=1 to my lirc_serial module options to get my serial transmitter to work. Does this fix enable that by default, or do we need another debconf option?

Julian Edwards wrote:
> I had to add softcarrier=1 to my lirc_serial module options to get my
> serial transmitter to work. Does this fix enable that by default, or do
> we need another debconf option?
>
Julian,

In the next LUM upload, this will be by default.

Regards,

--
Mario Limonciello
<email address hidden>

This bug was fixed in the package linux-ubuntu-modules-2.6.24 - 2.6.24-14.18

---------------
linux-ubuntu-modules-2.6.24 (2.6.24-14.18) hardy; urgency=low

  [Amit Kucheria]

  * Intel WiMax stack and driver for i2400m
  * WiMAX firmware and headers

  [Colin Ian King]

  * snd_bt_sco kernel Oops at startup
    - LP: #202249

  [Mario Limonciello]

  * Switch to enable second headphone jack on Dell M09 Ignore: no This adds
    a switch that enables the second headphone jack, allowing 5.1 audio and
    also two sets of headphone at the same time.

  [Stefan Bader]

  * SAUCE: Add missing SSID for suspend quirk.
    - LP: #151111
  * SAUCE: Enable audio quirk for Aluminium iMac.
    - LP: #147087

  [Tim Gardner]

  * ifdef iwlwifi debug messages
    - LP: #190475
  * lirc_serial loads but does not work
    - LP: #182530
  * Enable front input jack on Inspiron 1420/1520

  [Upstream Kernel Changes]

  * Ubuntu: Marvell: 8688: Enable WPA/WPA2 support

 -- Tim Gardner <email address hidden> Fri, 28 Mar 2008 10:54:41 -0600

Rather then posting a new bug report, after reading through this one. I'm kinda sure their related I can definitly say lirc_seriel receiving breaks for me when upgrading from gusty-clean install working remote --> hardy current as of april 21-08 no remote I did it twice, and is fubar with a clean hardy install as well, giving double key presses.
I'll build from cvs tomorrow, and will post back

bzr #15

This bug was fixed in the package lirc - 0.8.3-0ubuntu1

---------------
lirc (0.8.3-0ubuntu1) intrepid; urgency=low

  * New upstream version.
  * Drop 05_fix_cmdir as it's now included in CVS.
  * Update 12_pvr150_transmit_support for configure
    script changes.
  * Update 13-warning-cleanup to change from whitespace
    changes from CVS.
  * Update 16_lirc-gpio for changes from CVS.
  * Update 23_pad2keys for changes from CVS.
  * Update 24_freecom_dvbt for changes from CVS.
  * Drop 25_upstream_2_6_24 as it's now included from CVS.
  * Drop 29_macmini_repeat as it's now included from CVS.
  * Update 30_medion_md1_remote for changes from CVS.
  * Update 33_asus_mycinema_remote for changes from CVS.
  * Update 23_pad2keys patch to properly work (LP: #153184)
  * Update 21_atiusb.dpatch because it's half upstream now (LP: #213549)
  * Add 23_remove_md8800 as the MD8800 remote is causing problems. (LP: #213549)
  * debian/modules-source/lirc-modules-source.conf:
    - Default the mode to be w/ soft carrier. (LP: #182530)
  * Update 31_hauppauge_hvr_1100 to use the right devinput driver instead. (LP: #206495)
  * Add 34_nebula_digitv.dpatch for supporting the Nebula Digitv remote (LP: #164867)
  * Add 35_general_devinput.dpatch for generic devinput devices. (LP: #235811)
  * Add 36_remove_extra_tekram.dpatch for removing extra option in lirc.hwdb.
    This option was causing lots of failures (LP: #211566)
  * debian/{modules-source/Makefile,rules}:
    - Allow the kernel version to be passed as an argument.
      prevents broken upgrades when the kernel ABI revs (LP: #218955)
  * debian/lirc-modules-source.prerm:
    - Check for both remove and upgrade.

 -- Mario Limonciello <email address hidden> Sat, 10 May 2008 16:07:40 -0500