[MPlayer-dev-eng] libvo changes

[Alban Bedel]

On Mon, 07 Apr 2008 18:13:46 +0300
Uoti Urpala <uoti.urpala at pp1.inet.fi> wrote:

> On Mon, 2008-04-07 at 17:13 +0200, Alban Bedel wrote:
> > Those changes are OK. However I'd like to point (for the n'th time)
> 
> I don't think it's been many times actually :)

Well several at least ;)

> > that libvo shouldn't directly depend on input. The real fix would be
> > to move such fd registration outside of libvo. libvo should export
> > any additional event fd it need and have mplayer register them with
> > the input system.
> 
> I think any such change would be orthogonal to what is done here (so
> not "real fix" to the same issues).

Yes, this is a different issue. But as we are on the "clean libvo"
topic, I thought it would be a good idea to raise this issue too.

> IMO just "exporting FDs" as in
> make the fd number visible in some struct could be problematic as
> it's not obvious exactly when MPlayer should check such values for
> (de)registration. So I think it's best to have it as a (de)
> registration function that is directly callable from the VO.

The problem is that their is currently no clean interface, so each vo is
doing it's own soup, that's really not good. I agree that just putting
a fd in a public field is not enough, but the problem still need to be
solved.

> To make libvo not directly depend on input would require either a
> wrapper function at higher level that is essentially a renamed
> mp_input_add_event_fd and just forwards the arguments, or passing a
> function pointer to the VOs in some init arguments. The wrapper
> function would just shift the dependency to another part of MPlayer,
> but things like mplayer_put_key already do that. Do you want all
> those replaced too?

mplayer_put_key is a poor interface, but at least it can be easily
provided by code that want to use libvo. The input API on the other
hand can't be expected to be provided by the user code, it's way too
complex.

But keep in mind that keypress are only one part, there are some other
kind of events (mouse click & motion, window closing, etc). Currently
those are handled by more or less clean hacks, but again a clean API
would be way better. And actually the current impossibility to get
complex events out of libvo is a limiting factor for some stuff (like
the osd menu, for a good "idle" mode it would need access to the expose
events).

IMHO mplayer_put_key should be replaced by something more robust that
allow any kind of event to be queued for the client code. The "core"
would then be responsible to dispatch the events to the proper subsystem
(input, dvdnav, osd menu, etc). That shouldn't be very hard to do, and
would greatly improve libvo.

	Albeu