Nouveau - Sep 2022 - [PATCH v2 09/41] drm/connector: Add TV standard property

Hi Maxime,

W dniu 7.09.2022 o 14:10, Maxime Ripard pisze:
> Hi,
>
> On Fri, Sep 02, 2022 at 12:00:33AM +0200, Mateusz Kwiatkowski wrote:
>> W dniu 29.08.2022 o 15:11, Maxime Ripard pisze:
>>> 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.
>>
>> This is not a bitmask property anymore, you've just changed it to
an enum.
>> The commit message is now misleading.
>>
>>> +static const struct drm_prop_enum_list drm_tv_mode_enum_list[] = {
>>> +??? { DRM_MODE_TV_MODE_NTSC_443, "NTSC-443" },
>>> +??? { DRM_MODE_TV_MODE_NTSC_J, "NTSC-J" },
>>> +??? { DRM_MODE_TV_MODE_NTSC_M, "NTSC-M" },
>>> +??? { DRM_MODE_TV_MODE_PAL_60, "PAL-60" },
>>> +??? { DRM_MODE_TV_MODE_PAL_B, "PAL-B" },
>>> +??? { DRM_MODE_TV_MODE_PAL_D, "PAL-D" },
>>> +??? { DRM_MODE_TV_MODE_PAL_G, "PAL-G" },
>>> +??? { DRM_MODE_TV_MODE_PAL_H, "PAL-H" },
>>> +??? { DRM_MODE_TV_MODE_PAL_I, "PAL-I" },
>>> +??? { DRM_MODE_TV_MODE_PAL_M, "PAL-M" },
>>> +??? { DRM_MODE_TV_MODE_PAL_N, "PAL-N" },
>>> +??? { DRM_MODE_TV_MODE_PAL_NC, "PAL-Nc" },
>>> +??? { DRM_MODE_TV_MODE_SECAM_60, "SECAM-60" },
>>> +??? { DRM_MODE_TV_MODE_SECAM_B, "SECAM-B" },
>>> +??? { DRM_MODE_TV_MODE_SECAM_D, "SECAM-D" },
>>> +??? { DRM_MODE_TV_MODE_SECAM_G, "SECAM-G" },
>>> +??? { DRM_MODE_TV_MODE_SECAM_K, "SECAM-K" },
>>> +??? { DRM_MODE_TV_MODE_SECAM_K1, "SECAM-K1" },
>>> +??? { DRM_MODE_TV_MODE_SECAM_L, "SECAM-L" },
>>> +};
>>
>> I did not comment on it the last time, but this list looks a little bit
random.
>>
>> Compared to the standards defined by V4L2, you also define SECAM-60 (a
good
>> thing to define, because why not), but don't define PAL-B1, PAL-D1,
PAL-K,
>> SECAM-H, SECAM-LC (whatever that is - probably just another name for
SECAM-L,
>> see my comment about PAL-Nc below), or NTSC-M-KR (a Korean variant of
NTSC).
>>
>> Like I mentioned previously, I'm personally not a fan of including
all those
>> CCIR/ITU system variants, as they don't mean any difference to the
output unless
>> there is an RF modulator involved. But I get it that they have already
been used
>> and regressing probably wouldn't be a very good idea. But in that
case keeping
>> it consistent with the set of values used by V4L2 would be wise, I
think.
>
> Ack. What would be the list of standards we'd absolutely need? NSTC-M,
> NTSC-J, PAL-60, PAL-B, PAL-M, SECAM-60 and SECAM-B?
The "essential list" IMO is NTSC, NTSC-J, NTSC-443, PAL, PAL-M, PAL-N
and SECAM.
Note that:

- I intentionally propose "NTSC", "PAL" and
"SECAM" without an ITU system
? designation. If we only consider composite signals, there's no difference
? between e.g. PAL-B, PAL-D and PAL-I, so it's better to label it as a
generic
? mode, IMO.

? * PAL-M and PAL-N are different, because those unique color encodings were
??? only ever used with Systems M and N, respectively.

? * NTSC-J is also different, because "System J" doesn't exist
anywhere in ITU
??? documents. Japan technically uses System M with a non-standard black level.
??? But "NTSC-J" stuck as a universally recognized name for that
variant.

- I intentionally did not list PAL-60 or SECAM-60. TBH... PAL-60 is just
? regular PAL paired with 480i60 modeline. Most if not all displays that
? accept PAL-60 input will just label it as "PAL". If we are not
introducing
? strict modeline validation, then maybe separating PAL and PAL-60 isn't
really
? necessary? Same goes for SECAM vs. SECAM-60.
?
? ...and same goes for NTSC vs. NTSC-50 a.k.a NTSC-N, which is a very exotic
? mode, but known to exist at least in the Atari ST world, see also:
? https://en.wikipedia.org/wiki/NTSC#NTSC-N/NTSC50

Combining PAL and PAL-60 into a single setting would complicate the vc4 driver
a little bit, though, as the registers need to be set up differently for those.

My feelings about the PAL-60 issue are not that strong, though. Merging PAL
and PAL-60 in this context is just a loose suggestion, I won't even try to
argue if you disagree.
>>> +/**
>>> + * drm_mode_create_tv_properties - create TV specific connector
properties
>>> + * @dev: DRM device
>>> + * @supported_tv_modes: Bitmask of TV modes supported (See
DRM_MODE_TV_MODE_*)
>>> +
>>> + * Called by a driver's TV initialization routine, this
function creates
>>> + * the TV specific connector properties for a given device.?
Caller is
>>> + * responsible for allocating a list of format names and passing
them to
>>> + * this routine.
>>> + *
>>> + * Returns:
>>> + * 0 on success or a negative error code on failure.
>>> + */
>>> +int drm_mode_create_tv_properties(struct drm_device *dev,
>>> +????????????????? unsigned int supported_tv_modes)
>>
>> supported_tv_modes is supposed to be a bitmask of
BIT(DRM_MODE_TV_MODE_*)
>> (or (1<<DRM_MODE_TV_MODE_*)) rather than DRM_MODE_TV_MODE_*
directly, but this
>> is not said explicitly anywhere in this doc comment.
>
> The argument doc mentions that it's a "Bitmask of TV modes
supported
> (See DRM_MODE_TV_MODE_*)", how would you improve it?
Maybe something like "Bitwise OR of BIT(DRM_MODE_TV_MODE_*) values"?
Or maybe
just add a little usage example?
> Thanks!
> Maxime
Best regards,
Mateusz Kwiatkowski

On Wed, Sep 07, 2022 at 09:52:09PM +0200, Mateusz Kwiatkowski
wrote:
> W dniu 7.09.2022 o 14:10, Maxime Ripard pisze:
> > Hi,
> >
> > On Fri, Sep 02, 2022 at 12:00:33AM +0200, Mateusz Kwiatkowski wrote:
> >> W dniu 29.08.2022 o 15:11, Maxime Ripard pisze:
> >>> 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.
> >>
> >> This is not a bitmask property anymore, you've just changed it
to an enum.
> >> The commit message is now misleading.
> >>
> >>> +static const struct drm_prop_enum_list
drm_tv_mode_enum_list[] = {
> >>> +??? { DRM_MODE_TV_MODE_NTSC_443, "NTSC-443" },
> >>> +??? { DRM_MODE_TV_MODE_NTSC_J, "NTSC-J" },
> >>> +??? { DRM_MODE_TV_MODE_NTSC_M, "NTSC-M" },
> >>> +??? { DRM_MODE_TV_MODE_PAL_60, "PAL-60" },
> >>> +??? { DRM_MODE_TV_MODE_PAL_B, "PAL-B" },
> >>> +??? { DRM_MODE_TV_MODE_PAL_D, "PAL-D" },
> >>> +??? { DRM_MODE_TV_MODE_PAL_G, "PAL-G" },
> >>> +??? { DRM_MODE_TV_MODE_PAL_H, "PAL-H" },
> >>> +??? { DRM_MODE_TV_MODE_PAL_I, "PAL-I" },
> >>> +??? { DRM_MODE_TV_MODE_PAL_M, "PAL-M" },
> >>> +??? { DRM_MODE_TV_MODE_PAL_N, "PAL-N" },
> >>> +??? { DRM_MODE_TV_MODE_PAL_NC, "PAL-Nc" },
> >>> +??? { DRM_MODE_TV_MODE_SECAM_60, "SECAM-60" },
> >>> +??? { DRM_MODE_TV_MODE_SECAM_B, "SECAM-B" },
> >>> +??? { DRM_MODE_TV_MODE_SECAM_D, "SECAM-D" },
> >>> +??? { DRM_MODE_TV_MODE_SECAM_G, "SECAM-G" },
> >>> +??? { DRM_MODE_TV_MODE_SECAM_K, "SECAM-K" },
> >>> +??? { DRM_MODE_TV_MODE_SECAM_K1, "SECAM-K1" },
> >>> +??? { DRM_MODE_TV_MODE_SECAM_L, "SECAM-L" },
> >>> +};
> >>
> >> I did not comment on it the last time, but this list looks a
little bit random.
> >>
> >> Compared to the standards defined by V4L2, you also define
SECAM-60 (a good
> >> thing to define, because why not), but don't define PAL-B1,
PAL-D1, PAL-K,
> >> SECAM-H, SECAM-LC (whatever that is - probably just another name
for SECAM-L,
> >> see my comment about PAL-Nc below), or NTSC-M-KR (a Korean variant
of NTSC).
> >>
> >> Like I mentioned previously, I'm personally not a fan of
including all those
> >> CCIR/ITU system variants, as they don't mean any difference to
the output unless
> >> there is an RF modulator involved. But I get it that they have
already been used
> >> and regressing probably wouldn't be a very good idea. But in
that case keeping
> >> it consistent with the set of values used by V4L2 would be wise, I
think.
> >
> > Ack. What would be the list of standards we'd absolutely need?
NSTC-M,
> > NTSC-J, PAL-60, PAL-B, PAL-M, SECAM-60 and SECAM-B?
> 
> The "essential list" IMO is NTSC, NTSC-J, NTSC-443, PAL, PAL-M,
PAL-N and SECAM.
> Note that:
> 
> - I intentionally propose "NTSC", "PAL" and
"SECAM" without an ITU system
> ? designation. If we only consider composite signals, there's no
difference
> ? between e.g. PAL-B, PAL-D and PAL-I, so it's better to label it as a
generic
> ? mode, IMO.
> 
> ? * PAL-M and PAL-N are different, because those unique color encodings
were
> ??? only ever used with Systems M and N, respectively.
> 
> ? * NTSC-J is also different, because "System J" doesn't
exist anywhere in ITU
> ??? documents. Japan technically uses System M with a non-standard black
level.
> ??? But "NTSC-J" stuck as a universally recognized name for that
variant.
> 
> - I intentionally did not list PAL-60 or SECAM-60. TBH... PAL-60 is just
> ? regular PAL paired with 480i60 modeline. Most if not all displays that
> ? accept PAL-60 input will just label it as "PAL". If we are not
introducing
> ? strict modeline validation, then maybe separating PAL and PAL-60
isn't really
> ? necessary? Same goes for SECAM vs. SECAM-60.
> ?
> ? ...and same goes for NTSC vs. NTSC-50 a.k.a NTSC-N, which is a very
exotic
> ? mode, but known to exist at least in the Atari ST world, see also:
> ? https://en.wikipedia.org/wiki/NTSC#NTSC-N/NTSC50
> 
> Combining PAL and PAL-60 into a single setting would complicate the vc4
driver
> a little bit, though, as the registers need to be set up differently for
those.
> 
> My feelings about the PAL-60 issue are not that strong, though. Merging PAL
> and PAL-60 in this context is just a loose suggestion, I won't even try
to
> argue if you disagree.
Ack
> >>> +/**
> >>> + * drm_mode_create_tv_properties - create TV specific
connector properties
> >>> + * @dev: DRM device
> >>> + * @supported_tv_modes: Bitmask of TV modes supported (See
DRM_MODE_TV_MODE_*)
> >>> +
> >>> + * Called by a driver's TV initialization routine, this
function creates
> >>> + * the TV specific connector properties for a given device.?
Caller is
> >>> + * responsible for allocating a list of format names and
passing them to
> >>> + * this routine.
> >>> + *
> >>> + * Returns:
> >>> + * 0 on success or a negative error code on failure.
> >>> + */
> >>> +int drm_mode_create_tv_properties(struct drm_device *dev,
> >>> +????????????????? unsigned int supported_tv_modes)
> >>
> >> supported_tv_modes is supposed to be a bitmask of
BIT(DRM_MODE_TV_MODE_*)
> >> (or (1<<DRM_MODE_TV_MODE_*)) rather than DRM_MODE_TV_MODE_*
directly, but this
> >> is not said explicitly anywhere in this doc comment.
> >
> > The argument doc mentions that it's a "Bitmask of TV modes
supported
> > (See DRM_MODE_TV_MODE_*)", how would you improve it?
> 
> Maybe something like "Bitwise OR of BIT(DRM_MODE_TV_MODE_*)
values"? Or maybe
> just add a little usage example?
This is the way we're usually documenting it in DRM:
https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/drm_plane.c#L357
https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/drm_crtc.c#L861
https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/drm_blend.c#L546

So I'd rather keep it consistent

Maxime
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/nouveau/attachments/20220909/37d44a8e/attachment-0001.sig>