<br><div class="gmail_quote">On Mon, Feb 15, 2010 at 12:30 PM, Jarod Wilson <span dir="ltr">&lt;<a href="mailto:jarod@wilsonet.com">jarod@wilsonet.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">On Fri, Feb 12, 2010 at 5:42 PM, Jarod Wilson &lt;<a href="mailto:jarod@wilsonet.com">jarod@wilsonet.com</a>&gt; wrote:<br>
&gt; On Thu, Feb 11, 2010 at 11:29 PM, Rajesh Balan &lt;<a href="mailto:rajesh@cs.cmu.edu">rajesh@cs.cmu.edu</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; the mceusb driver works perfectly on 2.6.32. the lirc_serial is the one that<br>
&gt;&gt; has issues.<br>
&gt;&gt;<br>
&gt;&gt; the version in the lirc cvs source compiles and loads, but from kernel<br>
&gt;&gt; version 2.6.29 or so onwards, it has issues triggering my IR blaster -- the<br>
&gt;&gt; triggering is very intermittent. I reported this to the lirc maintainer<br>
&gt;&gt; (Jarod) and he suggested using his git version of the lirc_serial driver<br>
&gt;&gt; instead. that version works flawlessly with 2.6.30. but it triggers a kernel<br>
&gt;&gt; OOPs with the 2.6.32 kernel.<br>
&gt;<br>
&gt; The oops should be fixed now. The remaining lirc_serial issue is a<br>
&gt; type mismatch between userspace and kernelspace. I&#39;ll try to get it<br>
&gt; fixed this weekend.<br>
<br>
</div>This build *should* fix the ioctl type mismatch problem:<br>
<div class="im"><br>
<a href="http://kojipkgs.fedoraproject.org/packages/lirc/0.8.6/3.fc13/" target="_blank">http://kojipkgs.fedoraproject.org/packages/lirc/0.8.6/3.fc13/</a><br>
<br>
</div>...which isn&#39;t actually lirc_serial-specific, it would hit almost any<br>
driver on a 32-bit install. 64-bit installs were immune, which is why<br>
I didn&#39;t see any issues in my own testing. Oops.<br>
<div><div></div><br></div></blockquote></div><br>Jarod, <br><br>do you have a svn/git/similar tree this was sourced from?  I&#39;d like to give this a try but I&#39;m ubuntu-based.  I guess I could use alien on the source .rpm but pulling straight from the source repository seems like the smarter way to go.<br>
<br>Thanks,<br><br>--Jack<br>