[vlc-devel] RE : [RFC] Key press handling

[Rémi Denis-Courmont]

On Mon, 10 Aug 2009 22:33:13 +0200, "brezhoneg1" <brezhoneg1 at yahoo.fr>
wrote:
> I think there is another problem with hotkeys being processed
> synchronously.
> Var_Set commands used to be issued by the hotkeys thread. They are now
> directly issued by the vout thread while a lock is already held, which
> leads to a EDEADLCK error. (for instance, ScalingCallback or
> OnTopCallback.)

I think I checked that those locks were not taken by the core vout thread
when invoking pf_manage, which in turns invokes var_Set(). I might have
missed something though. Anyway, this will be moot if we take key event
handling out of the vout thread.

> Also, CropCallback, AspectCallback and FullscreenCallback did not care
> about locks in vlc1.0 (which was wrong, because they were mostly running
> in separate threads, called by hotkeys thread and modifying vout
> internal variables). For these callbacks, the new hotkeys works fine in
> vlc1.1.  Yet, these callbacks are also used elsewhere (libvlc for
> instance), and this lock issue still exists.

Yes - it used to be even worse. Laurent and I fixed a couple of those
issues in 1.0, but not all.

(...)
> More generally, fullscreen/windowed mode is a two-state mode. But, some
> more complex interfaces (especially with libvlc) could need a n-state
> mode, where video could toggle between n different handles.

In principle, yes, though I'd like to see some real use cases for
2<n-state!

> Anyway, at the vout level, it comes down to knowing which window handle
> to use at a given time. The window provider API could be able to change
> the handle at run time (not just at initialization).

I think this is not needed. The window provider can nest multiple windows
internally. That way, the innermost window handle can remain constant
throughout its the provider object's lifetime.

In fact, we used to have a re-parent control request for video outputs up
to 0.9. If I recall correctly, the video output could be created before the
interface was initialized in earlier versions, and could stay after the
interface was destroyed. I removed the control request completely because
it was not thread-safe, and of no real use in 1.0.

> Another argument, the fsc (fullscreen controller) is easier to set up
> when the fullscreen windows handle is available at the interface level
> (setParent). The way fsc is managed right now is kind of temperamental,
> because the vout thread is the only one to know the fullscreen window
> handle.

Good point.

> Also, what about mouse interaction. Up to now, hotkeys and mouse were
> managed in different places. Wouldn't it be better to process them in
> the same way ?

In principle, we should do the same for mouse interaction. However, the
video display needs to be involved to scale the screen coordinates into
video coordinates. Also, mouse events are emitted on the video
outpus/displays objects.
Overall, I do not see any immediate advantage, other than architecture
cleanliness. I am happy if someone cleans it up, but I don't think I will
bother with it myself anytime soon.

Note that key presses are emitted on the libvlc instance. This is wrong: I
guess they should be tied to an input. But it is not trivial to fix at all.
Not only video outputs but also interfaces are emitting key events. Some of
those events may occur when there is no input at all :(

-- 
Rémi Denis-Courmont