rdkemw 6645 ds setting vendor support by santoshcomcast · Pull Request #169 · rdkcentral/rdk-halif-device_settings

santoshcomcast · 2025-08-22T13:06:14Z

No description provided.

Reason for change: This ensures that platform-dependent configurations are centralized across different HW platforms. Test Procedure:NA Risks: High Signed-off-by:gsanto722 <grandhi_santoshkumar@comcast.com>

santoshcomcast · 2025-08-25T06:07:27Z

Addressed review comments of below PR and created new from develop.
#166

ddevadas53276

Looks ok

srinivasgtl

I have made a few comments and some comments may need to be handled at different places too.

srinivasgtl · 2025-09-01T15:56:49Z

+ * compressions, stereo modes, and connected video output ports.
+ *
+ * @var dsAudioPortId_t typeid
+ * Type of video port (e.g. HDMI, SCART, etc.).


Can we set the structure dsAudioPortType_t clearly instead of just giving as example)

Updated. Please check new code changes.

srinivasgtl · 2025-09-01T15:58:56Z

+ * Type of video port (e.g. HDMI, SCART, etc.).
+ *
+ * @var const char *name
+ * Name of the audio port type.


What is the naming that we follow here? Just to avoid different names by different platforms, still referring the same port type.

srinivasgtl · 2025-09-01T16:01:40Z

+ * Number of supported audio encodings.
+ *
+ * @var audioFeatures_t::supportedEncodings
+ * Array of supported audio encodings. The size of the array is defined by dsAUDIO_ENC_MAX.


Are we using the structure dsAudioEncoding_t here? if yes, then we need to reflect this in the spec.

srinivasgtl · 2025-09-01T17:05:37Z

+    dsAudioStereoMode_t   supportedStereoModes[dsAUDIO_STEREO_MAX];
+    size_t                numConnectedVOPs;
+    dsVideoPortPortId_t   connectedVOPs[dsVIDEOPORT_TYPE_MAX];
+}dsAudioFeatures_t;


how does this datatype differ from dsAudioTypeConfig_t except for the ConnectedVOPs. Do we really need this? We can discuss more on the requirement.

This dsVideoPortFeature_t struct is combine of dsAudioTypeConfig_t and dsAudioPortConfig_t struct since both struct has few common element members.

srinivasgtl · 2025-09-01T17:11:39Z

+    dsAudioStereoMode_t   supportedStereoModes[dsAUDIO_STEREO_MAX];
+    size_t                numConnectedVOPs;
+    dsVideoPortPortId_t   connectedVOPs[dsVIDEOPORT_TYPE_MAX];
+}dsAudioFeatures_t;


How are the other capabilities like MS12 variants support, ARC/eARC support, different stereo modes supports etc are derived from this audio capability structure?

There are separate capabilites APIs are available and can use same to get capabilities.
Ex:
dsError_t dsGetAudioCapabilities(intptr_t handle, int *capabilities);

srinivasgtl · 2025-09-01T17:33:56Z

+ * @brief Retrieves the list of supported audio output port types and the number of audio ports available.
+ *
+ * @param[out] kSupportedPortTypes Pointer to an array where the supported audio port types will be stored.
+ *                                 The caller must ensure the array is properly allocated to hold the data.


To make this more precise, why can't we use a two call format. First call should o with kSupportedportTypes as NULL so that we only get the number of Audio ports supporte and later call with a properly allocated array to read the SupportedPortTypes.

It is better idea. Will discusses about feasibility.

srinivasgtl · 2025-09-01T17:44:36Z

+ * Specifies the restricted resolution for the video port (-1 if none).
+ *
+ * @var int8_t defaultResIndex
+ * Index of the default resolution in the resolutions array.


Can you point to the resolution array here?

Update the data type and details for variable.

const char * defaultResIndex; // the default resolution stirng

srinivasgtl · 2025-09-01T17:47:12Z

+	int8_t                  defaultResIndex;         // Index of the default resolution
+	size_t                  numconnectedAOPs;        // Number of connected audio output ports
+	uint8_t                 connectedAOP[dsAUDIOPORT_TYPE_MAX]; // Array of connected audio output ports
+} dsVideoPortFeatures_t;


how do we represent different Video formats supported, different video content type supported etc as part of capabilities?

this dsVideoPortFeatures_t struct using for configuration load in MW side.

As per my understanding, the video capabilities and select resolution APIs are using for video content.
dsColorDepthCapabilities(), dsSetResolution().
Correct me, If I am wrong.

srinivasgtl · 2025-09-01T17:50:57Z

+ * @return dsError_t Returns a status code indicating success or the type of error encountered.
+ *
+ *                   Possible values include:
+ *                   - dsErrorNone: Operation succeeded.


Can we follow the same method of defining the error code as done in the other APIs. Eg: Like from line 181 to 185 dsAudioPortTerm API.

srinivasgtl · 2025-09-01T17:59:52Z

+ * @note The caller is responsible for allocating memory for the indicatorColors
+ *       array before calling this function.
+ */
+dsError_t dsFPGetSupportedLEDIndicatorColours (dsFPDColorConfig_t *indicatorColors, int* indicatorCount);


Supported colors are already part of dsFPDIndicatorConfig_t (dsFPDColorConfig_t * supportedColors; // Supported Colors of the FPD LEDs ). Do we need to have a separate API for this?

Signed-off-by: grandhi_santoshkumar <grandhi_santoshkumar@comcast.com>

Ulrond

Need to review the why of this API changes.

Ulrond · 2026-06-05T10:57:00Z

Triage note (#169, ~290 days old, last activity ~275 days ago):

Title "rdkemw 6645 ds setting vendor support" is opaque from the outside. Status: BEHIND main; no referenced GitHub issue visible in the title.

Suggested next step: author confirmation of scope and current intent. The age + lack of recent activity suggests this should either be closed or driven; sitting in the queue indefinitely doesn't serve either outcome.

RDKEMW-6645: Implement new GET APIs that provide all vendor

747e28a

Reason for change: This ensures that platform-dependent configurations are centralized across different HW platforms. Test Procedure:NA Risks: High Signed-off-by:gsanto722 <grandhi_santoshkumar@comcast.com>

santoshcomcast changed the base branch from main to develop August 22, 2025 13:33

santoshcomcast mentioned this pull request Aug 25, 2025

CPESP-7136: DS audio setting for capability #166

Closed

santoshcomcast linked an issue Aug 25, 2025 that may be closed by this pull request

Feature: Vendor support to provide the device capabilities API's #170

Open

ddevadas53276 requested review from Ulrond, outdooruseonly and srinivasgtl August 26, 2025 08:54

ddevadas53276 reviewed Aug 26, 2025

View reviewed changes

srinivasgtl reviewed Sep 1, 2025

View reviewed changes

CPESP-7136: DS setting for capability

a69ebaa

Signed-off-by: grandhi_santoshkumar <grandhi_santoshkumar@comcast.com>

Ulrond requested changes Sep 3, 2025

View reviewed changes

Uh oh!

Conversation

santoshcomcast commented Aug 22, 2025

Uh oh!

santoshcomcast commented Aug 25, 2025

Uh oh!

ddevadas53276 left a comment

Choose a reason for hiding this comment

Uh oh!

srinivasgtl left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Ulrond left a comment

Choose a reason for hiding this comment

Uh oh!

Ulrond commented Jun 5, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants