Re: [PATCH v1 05/35] drm/connector: Add TV standard property

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




Den 16.08.2022 10.26, skrev Maxime Ripard:
> Hi,
> 
> On Mon, Aug 08, 2022 at 02:44:56PM +0200, Noralf Trønnes wrote:
>> Den 29.07.2022 18.34, skrev Maxime Ripard:
>>> 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.
>>>
>>> We'll then be able to phase out the older tv mode property.
>>>
>>> Signed-off-by: Maxime Ripard <maxime@xxxxxxxxxx>
>>>
>>
>> Please also update Documentation/gpu/kms-properties.csv
>>
>> Requirements for adding a new property is found in
>> Documentation/gpu/drm-kms.rst
> 
> I knew this was going to be raised at some point, so I'm glad it's that
> early :)
> 
> I really don't know what to do there. If we stick by our usual rules,
> then we can't have any of that work merged.
> 
> However, I think the status quo is not really satisfactory either.
> Indeed, we have a property, that doesn't follow those requirements
> either, with a driver-specific content, and that stands in the way of
> fixes and further improvements at both the core framework and driver
> levels.
> 
> So having that new property still seems like a net improvement at the
> driver, framework and uAPI levels, even if it's not entirely following
> the requirements we have in place.
> 
> Even more so since, realistically, those kind of interfaces will never
> get any new development on the user-space side of things, it's
> considered by everyone as legacy.
> 
> This also is something we need to support at some point if we want to
> completely deprecate the fbdev drivers and provide decent alternatives
> in KMS.
> 
> So yeah, strictly speaking, we would not qualify for our requirements
> there. I still think we have a strong case for an exception though.
> 

Which requirements would that be? The only one I can see is the
documentation and maybe an IGT test.

Noralf.

>>> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_atomic_uapi.c
>>> index c06d0639d552..d7ff6c644c2f 100644
>>> --- a/drivers/gpu/drm/drm_atomic_uapi.c
>>> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
>>> @@ -700,6 +700,8 @@ static int drm_atomic_connector_set_property(struct drm_connector *connector,
>>>  		state->tv.margins.bottom = val;
>>>  	} else if (property == config->tv_mode_property) {
>>>  		state->tv.mode = val;
>>> +	} else if (property == config->tv_norm_property) {
>>> +		state->tv.norm = val;
>>>  	} else if (property == config->tv_brightness_property) {
>>>  		state->tv.brightness = val;
>>>  	} else if (property == config->tv_contrast_property) {
>>> @@ -810,6 +812,8 @@ drm_atomic_connector_get_property(struct drm_connector *connector,
>>>  		*val = state->tv.margins.bottom;
>>>  	} else if (property == config->tv_mode_property) {
>>>  		*val = state->tv.mode;
>>> +	} else if (property == config->tv_norm_property) {
>>> +		*val = state->tv.norm;
>>>  	} else if (property == config->tv_brightness_property) {
>>>  		*val = state->tv.brightness;
>>>  	} else if (property == config->tv_contrast_property) {
>>> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
>>> index e3142c8142b3..68a4e47f85a9 100644
>>> --- a/drivers/gpu/drm/drm_connector.c
>>> +++ b/drivers/gpu/drm/drm_connector.c
>>> @@ -1637,6 +1637,7 @@ EXPORT_SYMBOL(drm_mode_create_tv_margin_properties);
>>>  /**
>>>   * drm_mode_create_tv_properties - create TV specific connector properties
>>>   * @dev: DRM device
>>> + * @supported_tv_norms: Bitmask of TV norms supported (See DRM_MODE_TV_NORM_*)
>>>   * @num_modes: number of different TV formats (modes) supported
>>>   * @modes: array of pointers to strings containing name of each format
>>>   *
>>> @@ -1649,11 +1650,40 @@ EXPORT_SYMBOL(drm_mode_create_tv_margin_properties);
>>>   * 0 on success or a negative error code on failure.
>>>   */
>>>  int drm_mode_create_tv_properties(struct drm_device *dev,
>>> +				  unsigned int supported_tv_norms,
>>>  				  unsigned int num_modes,
>>>  				  const char * const modes[])
>>>  {
>>> +	static const struct drm_prop_enum_list tv_norm_values[] = {
>>> +		{ __builtin_ffs(DRM_MODE_TV_NORM_NTSC_443) - 1, "NTSC-443" },
>>> +		{ __builtin_ffs(DRM_MODE_TV_NORM_NTSC_J) - 1, "NTSC-J" },
>>> +		{ __builtin_ffs(DRM_MODE_TV_NORM_NTSC_M) - 1, "NTSC-M" },
>>> +		{ __builtin_ffs(DRM_MODE_TV_NORM_PAL_60) - 1, "PAL-60" },
>>> +		{ __builtin_ffs(DRM_MODE_TV_NORM_PAL_B) - 1, "PAL-B" },
>>> +		{ __builtin_ffs(DRM_MODE_TV_NORM_PAL_D) - 1, "PAL-D" },
>>> +		{ __builtin_ffs(DRM_MODE_TV_NORM_PAL_G) - 1, "PAL-G" },
>>> +		{ __builtin_ffs(DRM_MODE_TV_NORM_PAL_H) - 1, "PAL-H" },
>>> +		{ __builtin_ffs(DRM_MODE_TV_NORM_PAL_I) - 1, "PAL-I" },
>>> +		{ __builtin_ffs(DRM_MODE_TV_NORM_PAL_M) - 1, "PAL-M" },
>>> +		{ __builtin_ffs(DRM_MODE_TV_NORM_PAL_N) - 1, "PAL-N" },
>>> +		{ __builtin_ffs(DRM_MODE_TV_NORM_PAL_NC) - 1, "PAL-Nc" },
>>> +		{ __builtin_ffs(DRM_MODE_TV_NORM_SECAM_60) - 1, "SECAM-60" },
>>> +		{ __builtin_ffs(DRM_MODE_TV_NORM_SECAM_B) - 1, "SECAM-B" },
>>> +		{ __builtin_ffs(DRM_MODE_TV_NORM_SECAM_D) - 1, "SECAM-D" },
>>> +		{ __builtin_ffs(DRM_MODE_TV_NORM_SECAM_G) - 1, "SECAM-G" },
>>> +		{ __builtin_ffs(DRM_MODE_TV_NORM_SECAM_K) - 1, "SECAM-K" },
>>> +		{ __builtin_ffs(DRM_MODE_TV_NORM_SECAM_K1) - 1, "SECAM-K1" },
>>> +		{ __builtin_ffs(DRM_MODE_TV_NORM_SECAM_L) - 1, "SECAM-L" },
>>> +		{ __builtin_ffs(DRM_MODE_TV_NORM_HD480I) - 1, "hd480i" },
>>> +		{ __builtin_ffs(DRM_MODE_TV_NORM_HD480P) - 1, "hd480p" },
>>> +		{ __builtin_ffs(DRM_MODE_TV_NORM_HD576I) - 1, "hd576i" },
>>> +		{ __builtin_ffs(DRM_MODE_TV_NORM_HD576P) - 1, "hd576p" },
>>> +		{ __builtin_ffs(DRM_MODE_TV_NORM_HD720P) - 1, "hd720p" },
>>> +		{ __builtin_ffs(DRM_MODE_TV_NORM_HD1080I) - 1, "hd1080i" },
>>> +	};
>>>  	struct drm_property *tv_selector;
>>>  	struct drm_property *tv_subconnector;
>>> +	struct drm_property *tv_norm;
>>>  	unsigned int i;
>>>  
>>>  	if (dev->mode_config.tv_select_subconnector_property)
>>> @@ -1686,6 +1716,13 @@ int drm_mode_create_tv_properties(struct drm_device *dev,
>>>  	if (drm_mode_create_tv_margin_properties(dev))
>>>  		goto nomem;
>>>  
>>> +	tv_norm = drm_property_create_bitmask(dev, 0, "tv norm",
>>> +					   tv_norm_values, ARRAY_SIZE(tv_norm_values),
>>> +					   supported_tv_norms);
>>
>> I expected this to be an enum, why a bitmask? Userspace can set multiple
>> bits in a bitmask.
> 
> I went for a bitmask since it allowed to report the capabilities of a
> driver, but I just realised that you can do that with an enum too, like
> we do for color encodings.
> 
> I'll switch for an enum, thanks!
> Maxime



[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux