[vlc-devel] [PATCH 2/3] input: return a status from input_ControlPush

Thomas Guillem thomas at gllm.fr
Tue Aug 27 09:50:51 CEST 2019



On Mon, Aug 26, 2019, at 18:02, Rémi Denis-Courmont wrote:
> Le maanantaina 26. elokuuta 2019, 18.28.26 EEST Thomas Guillem a écrit :
> > On Mon, Aug 26, 2019, at 17:14, Rémi Denis-Courmont wrote:
> > > Hello,
> > > 
> > > Most if not all controls can be reduced to constant size state because
> > > they either cancel previous controls or accumulate. There are no reasons
> > > why queueing them should be allowed to fail.
> > > 
> > > What control actually can fail to be requested?
> > 
> > Seeking from the macOS slider. It also need to be fixed in the UI in order
> > to not spam seek requests.
> 
> No. Queueing a seek request cannot fail. Seeking can always be reduced to a 
> constant size finite state, and AFAIR, Laurent already fixed that (in 
> circumvoluted manner) a decade ago.
> (That is not to say that seeking itself cannot fail, but that's asynchronous, 
> so it cannot be a return value.)

I went back to VLC 3 and 2 and seek controls can fail because of a full FIFO in both case.

The first fix I have in mind is to always reserve one control for all seek requests (move it from the array to a single variable that is overwritten for each (different) seek requests). But then, there is a the problem of when processing the seek control compared to other controls.

> We should really not bother UIs with errors that the core can avoid and which 
> UIs have no reasonable ways to handle.

Fair enough, I should not change the player public return values.

But I could still need this commit, there are some errors that can be handled inside the player: sending events or not and displaying a status via osd according to the control return value.

> 
> > But there are some controls that can't be reduced, like INPUT_CONTROL_NAV_*. 
> 
> Yeah, but typically UIs don't expect keyboard events to be discarded. They 
> should really be rate-limited by blocking IMO.
> 
> -- 
> 雷米‧德尼-库尔蒙
> http://www.remlab.net/
> 
> 
> 
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel


More information about the vlc-devel mailing list