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