On Thu, 2010-06-17 at 11:11 -0400, Jarod Wilson wrote: > On Thu, Jun 17, 2010 at 8:14 AM, Andy Walls <awalls@xxxxxxxxxxxxxxxx> wrote: > >> A fully functional tree carrying both of David's patches and the > >> entire stack of other patches I've submitted today, based on top of > >> the linuxtv staging/rc branch, can be found here: > >> > >> http://git.wilsonet.com/linux-2.6-ir-wip.git/?a=shortlog;h=refs/heads/patches > >> > >> Also includes the lirc patches that I believe are ready to be > >> submitted for actual consideration (note that they're dependent on > >> David's two patches). > > > > > > I'll try and play with this this weekend along with some cx23885 > > cleanup. > > Excellent. A few things to note... Jarrod, I was unable to get this task completed in the time I had available this weekend. A power supply failure, unexpected hard drive replacement, and my inability to build/install a kernel from a git tree that would actually boot my Fedora 12 installation didn't help. (My productivity has tanked since v4l-dvb went to GIT for CM, and the last time I built a real kernel without rpmbuild was for RedHat 9. I'm still working out processes for doing basic things, sorry.) I'll have time on Thursday night to try again. > Many of the lirc_dev ioctls are > currently commented out, and haven't in any way been wired up to tx > callbacks, Yes, I saw, that's OK. It should be easy enough to hack something in for testing and prototyping. > I've only enabled the minimum necessary for mceusb. The > ioctls are all using __u32 params, which, if you're on x86_64, will > require a patched lirc userspace build to make the ioctl types match. > I'm using this patch atm: > > http://wilsonet.com/jarod/lirc_misc/lirc-0.8.6-make-ioctls-u32.patch > > (In the future, lirc userspace should obviously just build against > <media/lirc.h>). I've got all x86_64 bit machines here, so thank you for the tips. Regards, Andy -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
