Prince Gupta authored 3 years ago and Jean-Baptiste Kempf committed 3 years ago

fixes drag'ndrop in PlaylistView

Prince Gupta authored 3 years ago and Jean-Baptiste Kempf committed 3 years ago

place it such that it won't interfere with "focus" rect of
PlaylistDelegate

Prince Gupta authored 3 years ago and Jean-Baptiste Kempf committed 3 years ago

fixes binding loop on implicit height

This is no longer useful.

This is no longer needed, and prevents adding support for RandR output
selection.

This removes the window configuration parameter from
vout_window_Enable(). The initial configuration is now set when the
window is created, and updated with the regular functions:
vout_window_SetSize(), vout_window_SetFullScreen() and
vout_window_UnsetFullScreen().

This reconciles the window configuration with the full-screen output
selection: if the window provider supports output selection, it can
simply ignore the full-screen flag in the configuration.

In practice, this makes no differences in the GL and splitter cases,
which were creating and enabling the window together. In the vout
case, this actually enables some small simplifications.

This change does not affect the module interface: the window
configuration is still passed via the enable() callback. However window
provider can choose to ignore all parameters other than the decoration
flag. Dimensions is already provided by the resize callback, and
full-screen status via set_fullscreen and unset_fullscreen callbacks.

It should be possible to remove the dimensions and full-screen flag
from the window configuration completely, but that is left for further
work, as it would affect many different modules.

This restores the configuration parameter to vout_window_New(). This is
at least necessary to initialise the decoration flag which is otherwise
constant.

This change tracks changes requested to the window that affect the
configuration, namely requested dimensions and non-specific full-screen
mode. This will be used in further changes.

This is needed afterwards. No functional changes.

No functional changes.

No functional changes.

No function changes.

No functional changes.

As of the previous change, we always have an original format except at
the very beginning before the first attempt to start a display.

This allows the window size to be updated when the display gets started
in a vout that has an already enabled window. This also avoids taking
the display lock whenever compute the window size.

This essentially reverts commit 3784e706.

The window can be enabled even though the video output. In that case,
EnableWindowLocked() tries to adjust the window size with the common
vout_UpdateWindowSizeLocked() function. This relies on sys->original
internally, unlike the case whereby the window is disabled.
Consequently sys->original must already reflect the new format. This
change moves the update of sys->original backward to meet the
requirement.

The flip side is of course that the format gets updated even if
enabling the (disabled) window fails. Luckily this has no significance
as there is no active display using either the old (stopped) or new
(failed) formats.

Note that the bug fixed here is hidden by another bug. In practice,
the window size update is skipped entirely by the code from 3784e706
as there is no display (and before 3784e706, this would be
undefined behaviour).

As per earlier mailing list discussion, the display configuration is
supposed to be retrieved when (re)starting the video output. It should
not matter whether the window was disabled or still enabled.

This retains the original video format after the display is closed. The
main motivation for this is that the window needs a format to determine
its size, and to translate mouse coordinates, both of which can happen
after the display has been stopped.

Even though the format will be stale, this resolves several data races
in a simpler and saner way than checking if the display exists (which
requires the display lock).

It is inconditionally freed when the vout is destroyed - even if the
vout was not successfully started even once - so it had better not
contain garbage.

Admittedly it is in practice implicitly zeroed by vlc_custom_create()
so this is really more of a clean-up than a real fix.

Romain Vimont authored 3 years ago and Romain Vimont committed 3 years ago

The deadline computation was shared between the vout thread function and
DisplayPicture(), both by hacking the return value (VLC_EGENERIC meaning
"wait") and using an output parameter, to handle 3 possible cases:
 - VLC_SUCCESS: do not wait
 - VLC_EGENERIC and deadline set: wait for deadline
 - VLC_EGENERIC and deadline not set: wait but no deadline is known

In case of VLC_EGENERIC, the vout thread function computed the max
between the returned value and 100ms.

Simplify by computing the expected deadline from DisplayPicture()
directly.

This code is already handled in vout_Request().

Fixes #26394

Refs #26394

This is not a failure. This is a perfectly normal and expected
situation. If PCM also fails, we will then print an error message.

The display cannot be started if the window is not enabled first.
If enabling the window failed, we can infer that the display was not
started, so there is no point trying to stop it.

Lyndon Brown authored 3 years ago and Jean-Baptiste Kempf committed 3 years ago

caused a big block of warnings.

Lyndon Brown authored 5 years ago and Hugo Beauzée-Luyssen committed 3 years ago

see e967f81f.

Lyndon Brown authored 5 years ago and Hugo Beauzée-Luyssen committed 3 years ago

see e967f81f.

note, this does **not** affect cat-based module selection items
(of which there are just three in use by the core), since that
mechanism uses subcats not cats.