Menu
▾
▴
#234 MacOS: libftdi support
Noticed from configure output that Lirc looks for libftdi (>1.0). Version 1.3 is available in MacPorts so I installed it. Ran into a couple of issues building which I hacked around as follows:
$ diff -u include/media/lirc.h.orig include/media/lirc.h
--- include/media/lirc.h.orig 2016-10-22 13:09:42.000000000 -0400
+++ include/media/lirc.h 2016-10-22 13:10:05.000000000 -0400
@@ -6,8 +6,8 @@
#ifndef _LINUX_LIRC_H
#define _LINUX_LIRC_H
-#include <linux/types.h>
-#include <linux/ioctl.h>
+#include <sys/types.h>
+#include <sys/ioctl.h>
#define PULSE_BIT 0x01000000
#define PULSE_MASK 0x00FFFFFF
$ diff -u plugins/ftdix.c.orig plugins/ftdix.c
--- plugins/ftdix.c.orig 2016-10-22 13:18:40.000000000 -0400
+++ plugins/ftdix.c 2016-10-22 13:44:14.000000000 -0400
@@ -51,7 +51,7 @@
#include <ftdi.h>
-#define LIRC_FTDIX_SET_SCHEDULER 1
+/* #define LIRC_FTDIX_SET_SCHEDULER 1 */
#ifdef LIRC_FTDIX_SET_SCHEDULER
#include <sched.h>
#include <linux/sched.h>
I would think the second is something that should be checked by configure?
No idea, of course, if the now-enabled drivers will actually function in OS X! As they say: "If it builds, ship it!"
Lirc: 0.9.4c
OS X: 10.10.5
XCode: 7.2
libftdi: 1.3.0
I have made a patch for the lirc.h parts, this is a clean upstream update. However, I think enabling of the scheduler code is probably best left as-is. This decision is not just that the proper header exists, it's more like a --enable switch to configure.
Adding such a switch is of course possible. But the general idea is to decrease to dependencies between the plugins and the lirc core. It is perfectlly possibly to build the plugins out-of-tree, and we should keep it that way. So, I suggest that you just keep the downstream patch disabling the scheduler code, it's clean and simple.
Keeping the downstream patch is fine with me. Wish we had someone to test functionality!
Fixed the lirc.h issues in [ca3237] (master) and [f86da9] (release-0_9_4). Thanks for reporting!
Related
Commit: [ca3237]