After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 797047 - kmssink: Deprecate force-modesetting in favour of "mode" property
kmssink: Deprecate force-modesetting in favour of "mode" property
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2018-08-29 18:57 UTC by Nicolas Dufresne (ndufresne)
Modified: 2018-11-03 14:30 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Nicolas Dufresne (ndufresne) 2018-08-29 18:57:22 UTC
I think force-modesetting isn't great has a property. As the time goes, we find that most people uses kmssink in a way one would use decklinkvideosink. It's basically the "new" way, even though still a bit limited, to handle a video output. In this regard, the typical use case is to fix the output mode using well known names, like 1080p60, 1080i60, etc. Basically, the API exposed by decklinkvideosink.

So my proposal is to replace "force-modesetting" with a mode property. We could have special values to indicate "current", for the currently configured mode (our default), "automatic", to try and match the video resolution with the output, or an alternative of type "best-match". And then, a list of modes.

The decklinkvideosink just hardcodes a fixed list of modes, we could do that, but then we'd need to improve it everything a DRM driver introduce a new mode. Maybe we could find a compromise, keep "mode" as a string and match it to one of the enumerated modes for the connector.
Comment 1 GStreamer system administrator 2018-11-03 14:30:37 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/776.