[MPlayer-dev-eng] [PATCH] Lirccd support

[Alban Bedel]

Hi Fredrik Tolf,

on Thu, 24 Apr 2003 21:36:57 +0200 you wrote:

> On Thursday 24 April 2003 18:48, Alban Bedel wrote:
> > Hi Fredrik Tolf,
> >
> > on Tue, 22 Apr 2003 01:14:31 +0200 you wrote:
> > > Hi all!
> > >
> > > I don't know how many know about LIRC, but it is supported in
> > > MPlayer, after all, so I guess some of you should.
> > > Anyway, I ended up writing a middle layer daemon for LIRC, and
> > > being rather satisfied with the result, I wrote a MPlayer patch
> > > to support it. Is there any chance of getting it into the tree?
> >
> > Looking at the patch i have a few questions.
> > Shouldn't mplayer try lircc first and then try lirc if lircc isn't
> > avaible or failed ? Bcs afaict with your patch both will be opened.
> > Or is that intentional ?
> 
> I was thinking about that, but it hit me that it probably won't 
> matter, since if one uses lircc, he would probably not use the old 
> lirc scheme at the same time, so I though it wouldn't hurt to merge 
> them.
> But maybe one should just be forced to manually enable lirc by using 
> mplayer -lirc in that case? Since it's your software, I guess I'd 
> better let you judge what you like the best.
Dunno how lircc work, but i suppose that you need lirc. So by default
mplayer would first open lirc then lircc wich doesn't make that much
sense. Or did i missed smthg ?

> > Where is lircc_fd declared ? If it's in the lircc header and that's
> > a global var it's really ugly !!!
> 
> Yeah, you're right, it is really ugly; I don't know why i didn't 
> notice that myself. Especially since a much more elegant solution is 
> quite obious
> Would you like me to change it before inclusion? (It's not really a 
> popular API yet, so it wouldn't hurt too much, if you see what I 
> mean)

Yes, pls. Just making the init function return the fd (or <0 on error)
would way better.
	Albeu