[vlc-devel] RE : [RFC] Key press handling
brezhoneg1 at yahoo.fr
Mon Aug 10 22:33:13 CEST 2009
> Laurent found a regression (my fault) in 1.1, whereby the video may
> problem is, hotkeys used to be processed asynchronously. With the
> the mostly useless hotkey thread, they are now processed
> should be a non-issue with the XCB outputs. With XCB-window resp.
> window, hotkeys are received by the window resp interface thread. This
> however a problem with the legacy Xlib outputs and possibly others.
I think there is another problem with hotkeys being processed
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
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
> requests for LibVLC embedded video to _not_ process keys, so that the
> overlying application could do it the way it wants. Also, this breaks
> specific shortcuts. For instance, Ctrl+E works if the focus is on the
> interface but not the embedded video.
> I would fix the Xlib outputs; removing code is not very difficult...
> that breaks hotkeys in fullscreen mode. I think we need to transfer
> handling from the video (old) output & (new) display to the video
> modules. Then, key can be processed by the window provider. However, I
> know how to implement fullscreen mode within the Qt4 window provider
> (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
> Then, we need to decide what to do with key presses from LibVLC, with
> "drawable" window provider plugin. One option is to remove hotkeys
> entirely, but I guess it would screw the Mozilla plugin up. Another
> to take care of them -depending on --vout-event setting- from the
> plugin. In that case, it will try to refactor it with the xcb_window
> 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 ?
More information about the vlc-devel