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

[brezhoneg1]

> 
> Laurent found a regression (my fault) in 1.1, whereby the video may
lag.
> The
> problem is, hotkeys used to be processed asynchronously. With the
removal
> of
> the mostly useless hotkey thread, they are now processed
synchronously.
> This
> should be a non-issue with the XCB outputs. With XCB-window resp.
XCB+Qt4-
> window, hotkeys are received by the window resp interface thread. This
is
> however a problem with the legacy Xlib outputs and possibly others.


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

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.



> 
> Video ouputs should probably handle key presses at all. We have had
> several
> requests for LibVLC embedded video to _not_ process keys, so that the
> overlying application could do it the way it wants. Also, this breaks
Qt4-
> specific shortcuts. For instance, Ctrl+E works if the focus is on the
> interface but not the embedded video.

I Agree. 


> 
> I would fix the Xlib outputs; removing code is not very difficult...
> However
> that breaks hotkeys in fullscreen mode. I think we need to transfer
> fullscreen
> handling from the video (old) output & (new) display to the video
window
> modules. Then, key can be processed by the window provider. However, I
do
> not
> know how to implement fullscreen mode within the Qt4 window provider
> either
> (not that I made any research).


I agree. Fullscreen mode should be moved from the vout thread and mostly
managed at the interface level (or window provider level).

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.

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

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.



> 
> Then, we need to decide what to do with key presses from LibVLC, with
the
> "drawable" window provider plugin. One option is to remove hotkeys
> handling
> entirely, but I guess it would screw the Mozilla plugin up. Another
option
> is
> to take care of them -depending on --vout-event setting- from the
drawable
> plugin. In that case, it will try to refactor it with the xcb_window
> plugin,
> as much code would be shared.


I would say the second option is better (supporting hotkeys at the
windows provider level optionally)

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 ?


Regards
Erwan10