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:

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.

This is not a bitmask property anymore, you've just changed it to an enum.
The commit message is now misleading.

quoted

+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?

quoted

+/**
+ * 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?

Thanks!
Maxime