On Mon, 26 Feb 2024 15:10:45 +0100 Maxime Ripard <mripard@xxxxxxxxxx> wrote: > Hi Pekka, > > On Wed, Feb 21, 2024 at 11:07:51AM +0200, Pekka Paalanen wrote: > > On Fri, 16 Feb 2024 18:48:55 +0000 > > Dave Stevenson <dave.stevenson@xxxxxxxxxxxxxxx> wrote: > > > > > From: Nick Hollinghurst <nick.hollinghurst@xxxxxxxxxxxxxxx> > > > > > > Add this as a value for enum_drm_connector_tv_mode, represented > > > by the string "Mono", to generate video with no colour encoding > > > or bursts. Define it to have no pedestal (since only NTSC-M calls > > > for a pedestal). > > > > > > Change default mode creation to acommodate the new tv_mode value > > > which comprises both 525-line and 625-line formats. > > > > > > Signed-off-by: Nick Hollinghurst <nick.hollinghurst@xxxxxxxxxxxxxxx> > > > Signed-off-by: Dave Stevenson <dave.stevenson@xxxxxxxxxxxxxxx> > > > > since no-one else commented yet, I'd like to remind of the new UAPI > > requirements: > > https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#open-source-userspace-requirements > > > > AFAIU, adding a new value to an existing enum still counts as new UAPI. > > > > Maybe there is no need for the full treatment here, or maybe there is, > > I'm not sure. I think you should make some statement about how the new > > UAPI requirements have been addressed. > > That property was meant to provide legacy display handling, so I don't > expect any reasonably recent codebase like Weston to suppport it, ever > :) > > That being said, from the beginning, that property was meant to be > handled as a "mode-setting" property, and thus handled by either the > kernel command-line, xrandr, or any similar mechanism. > > I would expect that new enum variant to be handled under the same terms: > it'll probably only show up in distro scripts or configuration files, > and never in any actual code base. > > Is it what you were expecting, or did you mean something else? Maybe? Let's have it in the commit message and see if DRM maintainers agree. 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. 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, and I've also completely missed any kernel command line arguments manipulating KMS properties. Thanks, pq
Attachment:
pgpBZccBi8KD9.pgp
Description: OpenPGP digital signature
