UAPI Re: [PATCH 1/3] drm: Add DRM_MODE_TV_MODE_MONOCHROME

[Simon Ser]

On Monday, February 26th, 2024 at 18:23, Dave Stevenson <dave.stevenson at raspberrypi.com> wrote:

> You want the commit text for a patch adding a new enum to state that
> the whole property isn't expected to be used through the UAPI? OK, I
> can roll a v2 if that is your desire.

By definition, anything new exposed by the kernel via KMS is new uAPI,
even if it's not expected to be used by most compositors.

> > You should expect that all KMS clients will work towards programming
> > all exposed KMS properties into known values. That's the only way to
> > achieve repeatable KMS behaviour, because there is no KMS reset ioctl.
> > 
> > There are no two tiers of KMS properties AFAIK. You have to be the DRM
> > master to change anything. So, people cannot force any settings from
> > outside of a KMS client, they have to go through the KMS client, like
> > xrandr goes through Xorg (and only Xorg).
> > 
> > I do fully expect Weston to gain support for this property, if anyone
> > cares of its value. That goes for all Wayland compositors.
> 
> I don't know about Weston, but Wayfire / wlroots / sway have currently
> chosen to ignore all interlaced display modes [1].
> [2] is the wlroots devs basically calling interlaced output a dead end.

Note, part of this thread is missing on GitLab:
https://github.com/swaywm/wlroots/issues/3038

Also note that none of that is set in stone if someone comes with a
solid enough use-case.

> That makes the debate for controlling the colour encoding on a
> composite video rather redundant as they're almost always interlaced.
> 
> [1] https://github.com/swaywm/sway/issues/3167
> [2] https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3038
> 
> > You're correct in that a KMS client would probably not know to control
> > the value of this property automatically but it needs to come from
> > configuration. That would be each KMS client's configuration. I don't
> > understand how a script could achieve that.
> > 
> > However, if you feel it is important to have KMS properties that
> > display servers must not touch, then they should be documented as such.
> > I do not know if that would actually lift the new-UAPI requirements,
> > that is for the DRM maintainers to decide and document. Is there such a
> > thing already?
> > 
> > What are those "similar to xrandr" mechanisms? I don't think I've heard
> > of any,
> 
> Boot to the console and run
> modetest -w <connector id>:"tv_mode":"NTSC"
> 
> There is no reset mechanism for all properties, so that setting
> persists after modetest quits.

That is a hack. This hack is no guarantee to continue to work in the
future. KMS is not intended to be abused this way.

There is a single component in charge of managing the KMS properties:
the compositor. Any attempt to bypass it only works by chance, if it
works at all and doesn't result in fireworks.

> > and I've also completely missed any kernel command line
> > arguments manipulating KMS properties.
> 
> "tv_mode" on the command line is handled in
> drm_mode_parse_cmdline_options() [3], as are rotate, reflect_x,
> reflect_y, margin_[left|right|top|bottom], and panel_orientation all
> to set the relevant KMS properties.
> 
> Having "video=Composite-1:PAL,tv_mode=Mono" on the kernel command line
> will set up connector Composite-1 with the standard 720x576 50Hz
> interlaced timings, and DRM_MODE_TV_MODE_MONOCHROME selected on the
> tv_mode property. Swap in different tv_mode descriptions as required
> (eg PAL,tv_mode=SECAM), although some make little sense.
> 
> That's the main route I'm looking at for configuring this property,
> for situations such as having a black and white TV connected. You
> don't get the opportunity to interrogate a composite display over what
> it supports, so it has to be configured manually somewhere in the
> system. If your monitor doesn't support the system default, then you
> can't see a GUI in order to change the option, and there is no
> guaranteed supported configuration so the command line is about the
> only option.
> 
> The use cases for runtime switching of the "tv_mode" are exceedingly
> rare, so IMHO the property doesn't need exposing through the UAPI.
> However it was added to the UAPI about 8 years ago for vc4 and sunxi,
> and is also now used by other drivers, so can't be reverted. Does that
> mean it can now never be changed without jumping through the hoop of
> creating some userspace user?

I don't know what the rules were 8 years ago, but the current uAPI rules
are what they are, and a new enum entry is new uAPI.