This avoids to lock the
display_lock on the main thread (blocking the whole UI thread) to check
sys->display and call
vout_display_TranslateMouseState() on every mouse event.
The mouse coordinates are generated when the
display_lock is unlocked (because it's a UI event), so there is already no guarantee that the coordinates are valid for the current display configuration, so doing it on the main thread did not bring benefits.
This is a limited independent change that could be merged before !324.
Note that this change alone is not sufficient to fix #25479 (closed), because on 360 video, mouse events then trigger
vout_ChangeViewpoint() few milliseconds later, which suffers from starvation before !324.
vout_ChangeViewpoint() should just post a control command (that could be reduced down to 1 even per loop) processed from the vout thread, the caller need not wait until it is actually applied. That way, it would not need to lock
display_lock at all.
VideoLAN code repository instance