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

[Rémi Denis-Courmont]

Le mardi 11 août 2009 21:33:15 Laurent Aimar, vous avez écrit :
>  For the same reasons, I would prefer to keep the keys event going through
> the vout, it would allow some nice features in case we have Picture In
> Picture or thing like that.

The reason why this will never work properly were already outlined. Interfaces 
with window providers, as well as several external applications, need to 
handle keys themselves. This is not some matter of principle. It's a real 
problem. If someone ever bother to scope key presses to videos instead of VLC 
instance, (s)he can always extend your new video/window event callback system. 
In that regard, it is irrelevant whether the key presses are received from the 
system by the display or the window. Also, regardless of display vs window, 
this will break globalhotkeys, RC, and Qt4 at the very least - they all 
generate key press events /out of the blue/ :(

Anyway, window provider need to handle key presses in any case, if only 
because they can have the focus. By moving key press to window, we kill many 
birds with a single stone: the hotkey thread, duplicate source code, 
quintiplicated binary code (GLX+XvMC+Xv+X11), non-functional Qt4 shortcuts, 
broken key press handling when goign to fullscreen mode in a LibVLC app...

> > 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 :(
>
>  A vout can live outside an input so I am not sure that the right place is
> at the input level.
>
>  I don't think that the hotkeys thread was a bad thing, it was simple and
> working except for a few corner cases.
>  So I would like to have a list of problems with the old hotkeys interface
> ? (That way we can search for a clean/better solution).

My only problems with the hotkeys interface is wastefulness. It does mostly 
nothing, and is only needed because of video outputs - other key triggers 
don't care about the latency.

Even if we end up restoring the hotkey thread, switching to asynchronous 
hotkeys processing with fire-and-forget threads or who-knows-what, I would 
rather have remove key handling from the displays for several other reasons. 
Sorry if my earlier mail made my rationale confusing.

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