Prior to next release TODO

[jdunn14]

We're actually quite close but here are the things that should be looked at before the final release:

Tasks:

• upgrade libusb on windows to libusb1.0: in progress
• build the existing firmware with latest PSoC and see if we get something happier with OSX That didn't work... see comment below.
• rpmlint
• a real pass through the wiki and docs
• make a pass through the TODOs fixed or removed most. leaving a few for another time

Issues to examine and possibly fix:

• #15, See if replacing the DLL works It does.

• 13, will be fixed after upgrading libusb on windows

• #1, make a final decision, but likely not in this release. not today
• #4, most of the framework is in place, but more useful for us during programming than for customers no today
• #9, cursory look and see how hard it would be to fix fixed in my repo
• #31, once leamas has a chance to look at it

[jdunn14]

I've tried upgrading libusb on windows and the build appears to be working, but I'm hitting a couple problems. Specifically, when I use --driver to specify usbdrv.dll it still loads usbpre1drv.dll if the libusb-1.0.dll file is missing. This will be fixed by installing that dll, but the search code should not be kicking in when the driver is called out on the command line.

Next issue will probably be signing and installing the libusb-1.0.dll.

[jdunn14]

I installed the latest PSoC designer, updated the USB module in usb_ir_loader from 1.6 to 1.9, programmed a device with the loader, booted into OS X, and it behaves the same. Further, the new code is large enough to run into the arbitrary 0xC00 boundary between the loader and body. Since we see no benefit and this collision could cause us some problems I'd say we leave well enough alone. I will take a look at anywhere the code refers to "toggle" and see if there's anything clearly off, but this is looking increasingly like we should support OS X only on newer hardware.

[jdunn14]

I figured out how to do a one-off install of libusb-1.0 on Windows and it's not reliable. It's unclear what the issue is, but it appears to be dropping responses fairly often, but not in a predictable pattern like the OS X firmware issue, but I will recheck with different hardware to see if it's related. If we cannot resolve the issue we'll likely stick with pre1 on windows since it appears to be reliable.

[leamas]

Also skimmed the spec file, noted that the systemd snippets was missing. See https://fedoraproject.org/wiki/Packaging:Scriptlets#Systemd. These are fedora-specific, you might need to handle this, but the functionality is probably required.

Closed #31 as fixed

EDIT: The spec uses %config you probably wants %config (noreplace), otherwise the user-edited config file will be replaced with thepackage defaults on updates.

[jdunn14]

Just another note that ./igdaemon --driver libusbdrv.so in the build/result folder fails to load the driver. Will need to look into that. Actually it works on Fedora, but not Ubuntu 17.04

[leamas]

This is just not how it works (missing/faulty README?). Instead:

• Drop the iguanair.so file in the plugin directory, probably /lib//*/lirc/plugins on debian. You will find the other plugins there.
• List the plugins using lirc-lsplugins. If you have dropped the iguanair.so file there, the driver will be listed with the name defined in the struct driver .name field.
• Use that name (iguanaIR?) as argument to the --driver option.

Note that there is a distinction between plugin (the so-file) and driver. Some plugins contains multiple drivers.

Looking at this, it might be better if lircd by default also looked in the some lib under /usr/local. But that's another issue.

[jdunn14]

That was probably confusing. I didnt mean to reply to your comment. I was just leaving a quick note for myself about igdaemon's loadable driver layer while I was working on something else. This bug has nothing to do with lirc at all. Please ignore the noise.