I observed same strange behaviour already last year on my »Video Output« talk.
The return value indicates an unkown error, but the subsequent usage seemingly works...
On my Laptop, I don not see this error; it might be due to the very old graphics card on my PC...
Add failure check when opening next URing slot for a submission;
this ''can'' fail when the ring is fully populated -- which in theory
should never happen in our setup, yet can always, in practice...
Since I want to segregate the code according to the domain,
several methods must be provided to the video display to conduct
a properly synchronised handover of video pixel data; by using
`Glib::Dispatcher` as base class, all aspects of feed synchronisation
can be packaged into a single connection interface, without having
to share implementation details between the video display and player.
This implies a basic decision regarding the buffer and state data to use,
and how this can be defined, parameterised and passed between threads.
I decided to place separation of domains first and to prefer
using a functional callback over using a shared data structure.
leaning heavily on the similar structure used for last year's
FrOSCon talk regarding video output (by Benny Lyons and myself).
However, this time we'll use a process state object (the player)
and, furthermore, there is some cross-wiring of components involved...
