[vlc-devel] [RFC] Key press handling

[Rémi Denis-Courmont]

	Hello,

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.

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

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.

On Windows, --vout-event does not even seem to be implemented. Also, there is 
no independent video window provider at all. Someone would need to separate 
the key event handling code from the video outputs first... I am not able to 
work on this (no time, no skills, no motivation).

On MacOS, everything is different ways and this discussion does not apply 
(unfortunately perhaps).

-- 
Rémi Denis-Courmont
http://www.remlab.net/