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? , a shared object? perhaps it can be all of the above!) 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  Another mini rant - people who use domain names as application names. Fucking idiots. OpenOffice.org I'm looking at you.  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