Steve Lhomme authored 7 years ago and Hugo Beauzée-Luyssen committed 7 years ago

It's not available on all GCCs

Fix regression from
057e5729,
40c96414f343d2fd939cf3053d9dc80930891c7e,
c900e39c

Signed-off-by: Hugo Beauzée-Luyssen <hugo@beauzee.fr>

Steve Lhomme authored 7 years ago and Hugo Beauzée-Luyssen committed 7 years ago

Signed-off-by: Hugo Beauzée-Luyssen <hugo@beauzee.fr>

refs #18650

Steve Lhomme authored 7 years ago and Marvin Scholz committed 7 years ago

Signed-off-by: Marvin Scholz <epirat07@gmail.com>

Since d9e1ff01 this is no longer passed,
vd->source is used instead.

Since d9e1ff01 this is no longer passed,
vd->source is used instead.

Steve Lhomme authored 7 years ago and Jean-Baptiste Kempf committed 7 years ago

It's always vd->source.

Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

Steve Lhomme authored 7 years ago and Jean-Baptiste Kempf committed 7 years ago

Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

Steve Lhomme authored 7 years ago and Jean-Baptiste Kempf committed 7 years ago

Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

Rémi Denis-Courmont authored 7 years ago and Jean-Baptiste Kempf committed 7 years ago

The name was meant to indicate that the plugin hid the pointer
autonomously. But it was ostensibly confused as implying that the
plugin had a mouse hiding control (basically the exact opposite).
In fact, it really meant that the mouse hiding control would NOT be
used.

This tries to provide a slightly less confusing name, and accordingly
inverts the meaning. This is also realigns with the convention that
false should be the default setting (which was broken in the grand
grand parent of this changeset).

Rémi Denis-Courmont authored 7 years ago and Jean-Baptiste Kempf committed 7 years ago

This vout never had mouse hiding, AFAICT.

Rémi Denis-Courmont authored 7 years ago and Jean-Baptiste Kempf committed 7 years ago

Depending on the value of info.has_hide_mouse, the control is never
called. No point in providing a dummy implementation then.

Rémi Denis-Courmont authored 7 years ago and Jean-Baptiste Kempf committed 7 years ago

Most video output displays either defer mouse hiding to the window
provider plugin, or do not handle the mouse events at all.
So that ought to be the default.

Also kepe the default in those display plugins that don´t handle
cursor hiding (notably X11 ones).

Rémi Denis-Courmont authored 7 years ago and Jean-Baptiste Kempf committed 7 years ago

Cursor management should eventually be moved from display to the window.
(The video output core still needs to take care of the window to video
translation, and the mouse event filtering, as it already does.)
And cursor hiding should be left entirely within the window plugins.

But in the mean time, compute the correct timestamps regardless of the
cursor hiding support in display plugin, so that it also works if the
cursor is hidden by the window plugin.

Nicolas Chauvet authored 7 years ago and Jean-Baptiste Kempf committed 7 years ago

Current dailymotion html uses "var __PLAYER_CONFIG__" instead of
"var config" to store data such as username, qualities and etc.
Others fields are unchanged.

Signed-off-by: Nicolas Chauvet <kwizart@gmail.com>
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

Victorien Le Couviour--Tuffet authored 7 years ago and Jean-Baptiste Kempf committed 7 years ago

Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

Victorien Le Couviour--Tuffet authored 7 years ago and Jean-Baptiste Kempf committed 7 years ago

Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

Victorien Le Couviour--Tuffet authored 7 years ago and Jean-Baptiste Kempf committed 7 years ago

The computations must not be done on the buffer size but on the video one.
Otherwise, we might end up with the sum of all output sizes bigger than the
video itself, which results in a green strip at the bottom of the lowest
outputs, and potentially incorrect display for all of them (with bad width).

Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

Zhao Zhili authored 7 years ago and Rémi Denis-Courmont committed 7 years ago

Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>

Previously SDL and SDL Image was disabled with the --disable-sdl flag,
with that flag gone, SDL Image needs to be disabled explicitly instead.

Because we can.

Like display plugins before, window plugins need to be handled
differently if they emit double click events than not.

The window/display already have events/controls for this, and nothing
else cared, cares and probably will ever care.

Live window state, this was moved from display to window eight years
ago (minus one week). When the fullscreen state changes, the window
plugin emits a resize event, which triggers any necessary updates in
the display. The display does not need to know about fullscreen state
as such. But it is retained on HWND platforms due to legacy code, just
like window state before.

The SDL video output has been forcefully disabled on MacOS X for 12
years. It has also been disabled in Windows builds for over 6 years.
Finally, it has been broken on X11 due to lack of windowing
integration, for several years, cannot be fixed without changes to
the SDL API, and is completely useless.

The DirectFB project has been dead for several years, and is ostensibly
not used. If you really need direct access to the Linux frame buffer,
there is still the raw LinuxFB module for the time being.

This was moved from display to window eight years ago.

...rather than the last saved height. In practice, this does not make
much if any difference though, as:
- the saved height should equal the actual height in windowed mode,
- the code path has no effects in fullscreen mode.

Assert that it does not happen, like with all or almost all other
non-resetting video outputs.

Zhao Zhili authored 7 years ago and Rémi Denis-Courmont committed 7 years ago

Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>

Steve Lhomme authored 7 years ago and Rémi Denis-Courmont committed 7 years ago

It's always found in vd->source.

Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>