Re: [PATCH v1 05/35] drm/connector: Add TV standard property
From: Maxime Ripard <hidden>
Date: 2022-08-16 11:21:00
Also in:
dri-devel, linux-amlogic, linux-sunxi, lkml
On Tue, Aug 16, 2022 at 11:42:20AM +0200, Noralf Trønnes wrote:
Den 16.08.2022 10.26, skrev Maxime Ripard:quoted
Hi, On Mon, Aug 08, 2022 at 02:44:56PM +0200, Noralf Trønnes wrote:quoted
Den 29.07.2022 18.34, skrev Maxime Ripard:quoted
The TV mode property has been around for a while now to select and get the current TV mode output on an analog TV connector. Despite that property name being generic, its content isn't and has been driver-specific which makes it hard to build any generic behaviour on top of it, both in kernel and user-space. Let's create a new bitmask tv norm property, that can contain any of the analog TV standards currently supported by kernel drivers. Each driver can then pass in a bitmask of the modes it supports. We'll then be able to phase out the older tv mode property. Signed-off-by: Maxime Ripard <redacted>Please also update Documentation/gpu/kms-properties.csv Requirements for adding a new property is found in Documentation/gpu/drm-kms.rstI knew this was going to be raised at some point, so I'm glad it's that early :) I really don't know what to do there. If we stick by our usual rules, then we can't have any of that work merged. However, I think the status quo is not really satisfactory either. Indeed, we have a property, that doesn't follow those requirements either, with a driver-specific content, and that stands in the way of fixes and further improvements at both the core framework and driver levels. So having that new property still seems like a net improvement at the driver, framework and uAPI levels, even if it's not entirely following the requirements we have in place. Even more so since, realistically, those kind of interfaces will never get any new development on the user-space side of things, it's considered by everyone as legacy. This also is something we need to support at some point if we want to completely deprecate the fbdev drivers and provide decent alternatives in KMS. So yeah, strictly speaking, we would not qualify for our requirements there. I still think we have a strong case for an exception though.Which requirements would that be? The only one I can see is the documentation and maybe an IGT test.
This is the one I had in mind https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#open-source-userspace-requirements I overlooked yours obviously, so I'll update my patches to fix it. Maxime