On Tue, Aug 16, 2022 at 11:42:20AM +0200, Noralf Trønnes wrote: > > > Den 16.08.2022 10.26, skrev Maxime Ripard: > > Hi, > > > > On Mon, Aug 08, 2022 at 02:44:56PM +0200, Noralf Trønnes wrote: > >> Den 29.07.2022 18.34, skrev Maxime Ripard: > >>> 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 <maxime@xxxxxxxxxx> > >>> > >> > >> Please also update Documentation/gpu/kms-properties.csv > >> > >> Requirements for adding a new property is found in > >> Documentation/gpu/drm-kms.rst > > > > I 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
Attachment:
signature.asc
Description: PGP signature
