Commit Graph

6 Commits

Author SHA1 Message Date
Anton Kindestam 9dfcc496a5 drm_prime: fallback to drmModeAddFB2
Fallback to drmModeAddFB2 if drmModeAddFB2WithModifiers fails. I've
observed it failing on a pinebook pro running manjaro. We also got "0"
as modifiers from FFmpeg anyway, which might or might not have
something to do with this.

Instead of trying to find the source of the problem, just add this
fallback.
2020-05-08 21:26:25 +02:00
Anton Kindestam 6c04eb0508 drm_prime: get the modifier for all planes
Untested (I don't have a platform that requires modifiers to work
here). Might break something, or might fix something. At least this
looks more intuitive to me.
2020-05-08 21:26:25 +02:00
Anton Kindestam c0bc8bf5d3 drm_prime: print out errno in error message
It is interesting to know why drmModeAddFB2WithModifiers failed.
2020-05-08 21:26:25 +02:00
Sven Kroeger fc8c1fcfb2 drm_prime: double free bug
This commit fixes a bug where handle for a framebuffer gets double
freed.
It seems to happen that the same prime fd gets two framebuffers.
As the prime fd is the same the resulting prime handle is also the
same.
This means one handle but 2 framebuffers and can lead to the following
chain:

1. The first framebuffer gets deleted the handle gets also freed via
the ioctl.

2. In startup phase not all 4 dumb buffers for overlay drawing
are set up. It can happen that the last dumb buffer gets the
handle we freed above.

3. The second framebuffer gets freed and the handle will be
freed again resulting that the 4's dumb buffer handle is not
backed by a buffer.

4. Drm prime continues to assign handles to its prime fds an
will lead to have this handle which was just freed to
reassign again but to an prime buffer.

5.Now the overlay should be drawn into dumb buffer 4 which
still has the same handle but is backed by the wrong buffer.
This leads to two different behaviors:

- MPV crashes as the drm prime buffers size als calculated
by the decoder output format. The overlay output format
differs and it takes more space. SO the size check
in kernel fails.

- MPV is continuing play. This happens when the decoders
allocates a bigger buffer than needed for the overlay.
For example overlay is Full HD and decoder output is 4k.
This leads to the behavior das the overlay wil be drawn
into the wrong buffer as its a drm prime buffer and results
in a flicker every fourth step.
2020-03-05 18:12:57 +01:00
Sven Kroeger 8b24510388 drm_prime: forward modifiers from FFMPEG to drm API
* Change drmModeAddFB2 to drmModeAddFB2WithModifiers
* Set modifiers flag in API call
* fetch and set modifiers according to kernel constraints
2020-03-03 19:54:15 +01:00
Lionel CHAZALLON cfcee4cfe7 Add DRM_PRIME Format Handling and Display for RockChip MPP decoders
This commit allows to use the AV_PIX_FMT_DRM_PRIME newly introduced
format in ffmpeg that allows decoders to provide an AVDRMFrameDescriptor
struct.

That struct holds dmabuf fds and information allowing zerocopy rendering
using KMS / DRM Atomic.

This has been tested on RockChip ROCK64 device.
2017-10-23 21:07:24 +02:00