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

[Fredrik Tolf]

On Thursday 24 April 2003 21:50, Alban Bedel wrote:
> 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 ?

Oh, sorry. Maybe I should have explained that...
Essentially, lirccd connects to the lirc daemon and the thought is 
that it should be the only program to parse the messages from it; all 
client programs should connect to lirccd instead. Lirccd sends out 
commands to the client processes according to its config file. The 
advantage is mainly that it synchronizes all client programs, since 
it alone maintains the current "state". In the default lirc scheme, 
each client maintains its own state, and if they are started at 
different times, which they mostly are, they easily reach different 
states, which is bad.
Of course, lirccd has many advantages beyond that, but that was my 
initial purpose for writing it, though.

>
> > > 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.

Oki doki. That solution was precisely what I had in mind (don't ask me 
why I didn't do that from the beginning... it must have been really 
late). Btw., it hit me that this patch is for MPlayer 0.90. Do you 
want a patch for the latest CVS version instead?

Best regards,
Fredrik Tolf