the "invalid argument count" message is because you have some extra stuff
on the command line.

This does not help me debug the problem. The arguments are:
--device=/dev/remote --driver=zotac

What's "extra" about this? I get the same error if I just use the --device=/dev/remote part.

drivers should be dynamically loaded

I agree! Also, I'm not sure kernel drivers are the solution for me -- USB is totally usable through libusb.
In fact, it seems like the shortest distance between me and working-remote-in-XBMC is to write a short libusb reader that reads input events from the receiver, maps them to XBMC events, and forwards them over the XBMC control socket.

The fact that this is the case is terrible marketing for lircd.

Sincerely,

jw






Sincerely,

Jon Watte


--
"I find that the harder I work, the more luck I seem to have." -- Thomas Jefferson


On Thu, Mar 6, 2014 at 12:18 AM, Alec Leamas <leamas.alec@gmail.com> wrote:
On 3/6/14, Jon Watte <jwatte@gmail.com> wrote:
> I'm running XBMC on a Raspberry Pi:
>
> Linux raspberrypi 3.6.11+ #538 PREEMPT Fri Aug 30 20:42:08 BST 2013 armv6l
> GNU/Linux
>
> I have plugged in a USB receiver that came with a Zotac Z-box AD10
> computer, and am using a remote control that came with it, branded "Zotac"
> (but the receiver is really a Philips):
>
> Bus 001 Device 004: ID 0471:20cc Philips (or NXP)
>
> Using the default XBMC setup, this works poorly; a few of the buttons work
> (OK, arrows, enter and escape) but most of them do not.
>
> My goal is to get all the remote keys to be recognized in the XBMC
> application (I can live without the four color keys if need be.)
>
> I first tried the lirc that came with raspbian. Unfortunately, it didn't
> improve the situation. Googling around, it seems that the Philips USB IR
> receiver is only supported by a fork of Lirc called FernetMenta-lirc, using
> a driver called "zotac."
> So, I downloaded and built and installed that version, after uninstalling
> the stock lirc, and configured the lircd.conf and hardware.conf as
> suggested in the various articles that talk about this fork.
>
> Unfortunately, lircd doesn't start when I /etc/init.d/lirc start.
> The reason initially was that neither "DEVICE" nor "DRIVER" were set up by
> /etc/hardware.conf, so the init script didn't even get to start the binary.
> It just exited with failure without printing anything.
> Thus, I added those two lines:
> DEVICE=/dev/remote
> DRIVER=zotac
> /dev/remote is set up by a udev rule to point to this device. "zotac" is
> the driver I selected in the setup.sh script when configuring and building
> the installation from source.
>
> Now, lircd still doesn't start. The executable says "lircd: invalid
> argument count"
> The arguments that the init script passes to it are:
> --driver=zotac --device=/dev/remote
>
>
> I have two questions:
>
> 1) How can I achieve my goal, of having XBMC recognizing most/all buttons
> of this remote?
Well, the "invalid argument count" message is because you have some extra stuff
on the command line. The
> 2) Why is this so hard? I mean, really? There's no technical reason it
> couldn't just be done right, and Just Work (tm.)

While I think lirc could be *much* more easy to use, the "just works"
solution is to add a driver such as zotac to the kernel. LIrc is
basically trading a lot of flexibility for some more complexity. It
will never be the "just works" solution the kernel drivers are.

As for your problems, I guess one side of it is the lack of
documentation. I have a patch pending at
http://leamas.fedorapeople.org/lirc/html/configuration-guide.html.
There are other sources as well, google is your friend.

To be frank, I think you should try to run lircd on its own before
trying the somewhat complex debian setup, which adds another layer to
the onion. Since you are building lirc your self, don't forget to add
--enable-debug to configure and use use the debugging options.

IMHO, if things was as they should, drivers should be dynamically
loaded and you should be able to just drop a .so file in a lirc
installation to use it But that's another story.

--alec.