Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: HDMI support on Ripple #264

Open
wants to merge 30 commits into
base: main
Choose a base branch
from

Conversation

chakradhar29
Copy link

What

Adds HDMI support on Ripple

Why

HDMI support on Ripple

How

Integrates with AVInput thunder api running on RDK devices

Test

Sends requests through firebolt hdmi module

Checklist

  • I have self-reviewed this PR
  • I have added tests that prove the feature works or the fix is effective

@CLAassistant
Copy link

CLAassistant commented Oct 4, 2023

CLA assistant check
Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.
0 out of 2 committers have signed the CLA.

❌ chakradhar29
❌ kevinshahfws
You have signed the CLA already but the status is still pending? Let us recheck it.

@chakradhar29 chakradhar29 changed the title feat(RPPL-1151): HDMI support on Ripple feat: HDMI support on Ripple Oct 5, 2023
@satlead satlead added the do not merge Use for PRs which are experimental and testing purposes. label Oct 6, 2023

#[rpc(server)]
pub trait Hdmi {
#[method(name = "hdmi.setActiveInput")]
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

HDMIInput.select

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated it.

#[derive(Debug, Serialize, Deserialize, Clone)]
#[serde(rename_all = "camelCase")]
pub struct StartHdmiInputRequest {
pub id: String,
Copy link
Collaborator

@satlead satlead Oct 6, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Enumeration for Start and Stop

pub operation: HDMIOperation

Add a new enum

#[derive(Debug, Serialize, Deserialize, Clone)]
#[serde(rename_all = "camelCase")]
pub enum HdmiOperation {
Start,
Stop
}

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added enum.

let response = state
.get_thunder_client()
.call(DeviceCallRequest {
method: ThunderPlugin::AVInput.method("startInput"),
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Use HdmiOperation to change the method to stopInput

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added.

.await
.is_err()
{
error!("Error while registration");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we still return an OK response even if we hit this block?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is similar to how on_hdcp_changed listener is implemented

Can you elaborate on how I should change it?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Might need some input from @satlead on this one. However, from my point of view here the code reads:

  1. Send DeviceEventRequest to the extension that will handle it
  2. If we get an error then log it
  3. Tell the caller that everything worked ok

What I would expect is this:

  1. Send DeviceEventRequest to the extension that will handle it
  2. If we get an error then log it and tell the caller it didn't work
  3. If we didn't get an error then tell the caller that everything worked ok

So if this is the same in HDCP then I would think that might need looking at as well (in a different PR of course).

I think that a more appropriate implementation would be:

Suggested change
error!("Error while registration");
error!("Error while registration");
return Err(Error::Custom("Failed to subscribe to HdmiConnectionChanged event".to_owned()));

Note: you will want to add a use statement for Error e.g. use jsonrpsee::core::Error;.

@satlead please could you confirm I am on the right track with this one?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Got it. thank you :)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like there is a util function rpc_error that can be used to glean it up a bit:

return Err(Error::Custom("Failed to subscribe to HdmiConnectionChanged event".to_owned()));

Becomes:

return Err(rpc_error("Failed to subscribe to HdmiConnectionChanged event"));

Sorry, I didn't know about this fn until just now.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe it's rpc_err. Used it, thanks.

Comment on lines 71 to 101
if let HdmiOperation::Start = request.operation {
if let Ok(response) = self
.state
.get_client()
.send_extn_request(HdmiRequest::StartHdmiInput(request))
.await
{
if let ExtnPayload::Response(ExtnResponse::Value(value)) = response.payload {
if let Ok(res) = serde_json::from_value::<HdmiSelectOperationResponse>(value) {
return Ok(res);
}
}
}

Err(rpc_err("FB error response TBD"))
} else {
if let Ok(response) = self
.state
.get_client()
.send_extn_request(HdmiRequest::StopHdmiInput(request))
.await
{
if let ExtnPayload::Response(ExtnResponse::Value(value)) = response.payload {
if let Ok(res) = serde_json::from_value::<HdmiSelectOperationResponse>(value) {
return Ok(res);
}
}
}

Err(rpc_err("FB error response TBD"))
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The if/else block branches look the same to me. Is that right?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes needs some cleanup by passing the operation to the Device handler

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Comment on lines 15 to 19
pub enum AVInputAdjective {
Hdmi,
Ota,
Composite,
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is this defined in an HDMI module? When implementing Composite for example I would not expect to find the adjective for it defined here in HDMI.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah AVInput probably needs a super .rs file for OTA and composite

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Moved AVInputAdjective to a super .rs file.

}
}

async fn get_available_inputs(state: ThunderState, req: ExtnMessage) -> bool {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All of the handlers look basically the same. Is there a way we can reduce the repeated code?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Certainly Start and Stop can be just one value in the operation which is what was suggested. Get available inputs body is slightly different so there would be something additional.

Think we can move the Thunder call alone to a separate function to reduce the boilerplate

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Refactored it in latest code.

@chakradhar29 chakradhar29 marked this pull request as ready for review October 10, 2023 19:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
do not merge Use for PRs which are experimental and testing purposes.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants