From: Simon Wistow
Date: 11:51 on 12 Jan 2005
Subject: lirc
This could easily be "Linux" or even "Every other operating system". But
I shall specialise - no point wasting all that good bile in one go.
So at work I'm tasked with building a set-top box. It must do full
screen DVD quality play back. I'm using Linux as the host OS on a VIA
Epia MII motherboard and a Unichrome CLE266 MPEG decoder.
I have, finally, got MPEG decoding working fast using the chip. TBH I'm
not all that fussed that it took me this long because MPEG decoding is
HARD, especially when you actually have to start worrying abotu
clockspeed of the mobo wrt to, say, PAL and NTSC. And interlacing.
Thinking that I've done the easy bit I skip merrily on to the next task
which is getting the remote control working. This, thinks I, should be
easy.
Except our chosen remote control, a Streamzap, is not support officially
by LIRC, the Linux Infra Red Control app. But there are patches.
Which don't apply cleanly. *sigh*
So I manually frig them just in time to find someone else has already
done it. And better.
The mode2 sniffer claims that there are signlas going in. The lirc
daemon however claims that it can't decode the remote control.
Try another remote control, in case this one is broken. Doesn't fix it.
Check the intaweb. Various people have had similar problems. All have
been ignored.
Mail the author of the patch. Silence.
Mail the lirc mailing list. Resounding absence of replies.
Find another patch which takes another approach - the /dev/input layer
Basically the remote control pretends to be a keyboard. Install.
And lo! If I fire up an editor and then start hitting buttons on the
remote and keys appear on the screen. Huzzah! Except that most of the
special keys, the important keys, like play. And pause. Don't produce
key codes.
However the lirc input driver should be able to cope with this.
Except it doesn't. It gets preciseley nada input. Not even the old
"Can't decode remote". Arse.
I don't know what to hate more - the parlous state of Linux drivers, the
kernel maintainers plans to change major APIs midway through a
supposedly stable branch or the weird fraction of drivers (is it a
daemon? a kernel driver? a user mode app? an X.org driver? [0], a
shared object? perhaps it can be all of the above!)[1]
Or do you know what else really fucks me off - I couldn't have done this
in anyother OS. Certainly not and keep it at a sensible price point but
very likely not have been able to do it at all. Linux may suck but it
was the best I could hope for.
And for that I really fucking hate, well, everything.
Simon
[0] Another mini rant - people who use domain names as application
names. Fucking idiots. OpenOffice.org I'm looking at you.
[1] I know why the division occurs - I understand and even agree with
principle of not having the graphics drivers &cetera; in the kernel
space. It's still a fucking arse though.
From: peter (Peter da Silva) Date: 15:05 on 26 Jan 2005 Subject: Re: lirc > And lo! If I fire up an editor and then start hitting buttons on the > remote and keys appear on the screen. Huzzah! Except that most of the > special keys, the important keys, like play. And pause. Don't produce > key codes. What's worse, they show up at a different USB end-point (System Control). And they're dependent on the manufacturer and in some cases model of the keyboard. > However the lirc input driver should be able to cope with this. Only if the keyboard they're emulating simulates the same "System Control" inputs it's expecting. I guess the keyboard firmware that produces this unsatisfactory state of affairs is on-topic. > Or do you know what else really fucks me off - I couldn't have done this > in anyother OS. Mac Mini. Except you'd probably have the same keyboard issues. I know I do. Bastards.
Generated at 10:27 on 16 Apr 2008 by mariachi