Sean McGovern authored 2 years ago and Steve Lhomme committed 2 years ago

The Linux fbdev subsystem has been deprecated for more than a decade as there are better options available now.

When we go in the `(next != NULL)` section, we have a new picture to render.
We need to wait until its "refresh" date to start the rendering.
It doesn't matter if there was a picture shown before that one.

The code is almost the same as before where dropped_current_frame was almost
always true. The only time it was false was:
* first picture and next is not NULL (first pic & next NULL is impossible here)
* not first picture and next is NULL

So the new code only changes the case where it is the "first picture and next
is not NULL". But in that case, first was true and therefore the test was
not passing, just like now.

It is logically equivalent to the code before. But now it's clear that when we
don't have a next picture we request a redisplay (of displayed.current).

We don't release the picture because there's dropped_current_frame. We have to
release it because we're replacing the value and we were holding the picture
in there.

Pierre Lamot authored 2 years ago and Rémi Denis-Courmont committed 2 years ago

We don't need 14 different durations

Values are aligned on Kirigami definitions

Pierre Lamot authored 2 years ago and Rémi Denis-Courmont committed 2 years ago

we don't need two levels of bindings for constant. if developers need to test
different values, they can adjust them manually

The X and Y values are pixel coordinates in the potentially subsampled
plane resolution. This must be converted to an octet offset as the type
of the pixel plane pointer is pointer-to-uint8_t.

So the X value must be multiplied by the sample size. The current code
was instead rounding the value down to a multiple of the sample size.

Bug reported by Philipp Marek on IRC.

The display module does not actually depend on libdrm in any way.
It can be compiled with just the Linux kernel headers, so do just that.

KMS is a subset of kernel interface. What is tested there is the
presence of libdrm development files.

Steve Lhomme authored 2 years ago and François Cartegnie committed 2 years ago

For now we use the default values it would use otherwise.

DXGI WARNING: IDXGIFactory::CreateSwapChain/IDXGISwapChain::ResizeBuffers: The buffer height inferred from the output window is zero. Taking 8 as a reasonable default instead [ MISCELLANEOUS WARNING #2: ]

Steve Lhomme authored 2 years ago and François Cartegnie committed 2 years ago

We could avoid sending 0, or we could avoid the rendering if it's 0.
But being a "simple" sample app, let's use the easiest way.

Benjamin Arnaud authored 2 years ago and Steve Lhomme committed 2 years ago

fix #26980

It's implied when the xxx_CFLAGS is not set.

When the sequence header changes we need to know it has changed so the output
values can be reset.

In particular the visible size was not reset since it was set initially by the
demuxer. The first sequence header received is still not used to overwrite the
visible size after this patch.

The extra data were not reset even though they contain the sequence header.

Because there changes were not detected the new output format is never
forwarded.

Fixes #26811

A change in a sequence header means the stream has changed.

This will avoid a mismatch of the UUID type.

The other COM objects don't have their IID in mingw-w64 so we can't handle them
well with WRL.

The code implicitly assumes that EGL version is 1.4 or later, which is
required for client extensions. Rather than crash, fail safe in the
unlikely event that the EGL client run-time is older.

Client extensions and function pointers are independent of the display
and will never change during run-time, so cache them once and for all.

Only release the window if it was actually referenced.