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

[WPE 2.38] matchMedia("(dynamic-range: high)") always returns matches=false #1430

Open
amol-virnodkar-infosys opened this issue Nov 25, 2024 · 5 comments
Assignees
Labels

Comments

@amol-virnodkar-infosys
Copy link

amol-virnodkar-infosys commented Nov 25, 2024

In WPE 2.38, media query dynamic-range is supported. But on Sagemcom VA the matches property is always returns false with connected to LG OLED TV(Model number: OLED55C3PSA) which supports HDR. Please see below screenshot. The matches property should return true when the Sagemcom VA is connected to HDR supported TV.

SGMCOM_HDR

As per https://www.w3.org/TR/mediaqueries-5/#dynamic-range, the matched should say True in such case.

In WPE 2.32 and WPE 2.38, below are the return results.

  • For WPE 2.22: matchMedia("(dynamic-range: high)") returns {matches: false, media: "not all", ..}
  • For WPE 2.38: matchMedia("(dynamic-range: high)") returns {matches: false, media: "(dynamic-range: high)", ..}

Test Steps:
Ensure that the Sagemcom VA is connected to HDR supported TV

  1. Open Apple TV application(https://atve.tv.apple.com/94819831-5404-4438-810e-afb648d6a826/tvw_0e7f0489b969451a9f79941a0d18fad1/) with the WebKitBrowser using the UIController.
  2. Open Web Inspector and on the console tab, execute the below media query matchMedia("(dynamic-range: high)") & it returns {matches: false, media: "(dynamic-range: high)", ..}
    as shown in the above screenshot. The expected results that should be returned is matches:true for this case.
@amol-virnodkar-infosys amol-virnodkar-infosys changed the title [WPE 2.38] matchMedia("(dynamic-range: high)") always returns matches=False [WPE 2.38] matchMedia("(dynamic-range: high)") always returns matches=false Nov 25, 2024
@eocanha eocanha self-assigned this Nov 28, 2024
@eocanha
Copy link
Member

eocanha commented Nov 28, 2024

I don't have a physical HDR screen here to reproduce the issue exactly, but I've been debugging where the response to that matchMedia() query comes from and I've realized that in wpe-2.38 the answer is hardcoded to false here (I've added printfs that show that's the function being called).

Now I need to figure out a way to properly implement that HDR detection support, if possible.

@amol-virnodkar-infosys
Copy link
Author

amol-virnodkar-infosys commented Nov 29, 2024

Even I added debug logs in function: static bool dynamicRangeEvaluate() in the file: WebCore/css/MediaQueryEvaluator.cpp where the matchMedia() media query is evaluated. dynamicRangeEvaluate() function is returning false as internally call to screenSupportsHighDynamicRange(frame.mainFrame().view()); is returning false.

In the function: dynamicRangeEvaluate()
dynamicRangeEvaluate : screenSupportsHighDynamicRange, supportsHighDynamicRange: 0
dynamicRangeEvaluate: case CSSValueHigh, returning supportsHighDynamicRange: 0

In the WebCore/platform/PlatformScreen.h file, screenSupportsHighDynamicRange() function is returning the value as false for other platforms except MAC and iOS. The implementation of screenSupportsHighDynamicRange() is missing for other platforms except MAC and iOS.

#if PLATFORM(MAC) || PLATFORM(IOS_FAMILY)
WEBCORE_EXPORT bool screenSupportsHighDynamicRange(Widget* = nullptr);
#else
constexpr bool screenSupportsHighDynamicRange(Widget* = nullptr) { return false; }
#endif

IMO, we need to implement PAL APIs for RDK similar to MAC and iOS and we can use below DisplaySettings APIs to know if the HDR is supported by the TV & STB or we can use IARM calls to get the HDR capabilities.

curl -d '{"method": "org.rdk.DisplaySettings.1.getTvHDRSupport"}' http://127.0.0.1:9998/jsonrpc
curl -d '{"method": "org.rdk.DisplaySettings.1.getSettopHDRSupport"}' http://127.0.0.1:9998/jsonrpc

@amol-virnodkar-infosys
Copy link
Author

amol-virnodkar-infosys commented Nov 29, 2024

For testing purpose, further I changed the implementation of screenSupportsHighDynamicRange() which returns true for other platforms as below and the matchMedia("(dynamic-range: high)") returned matches: true and it worked as expected. Even I could see that AppleTV+ application was able to fetch HDR media segments and the playback used HDR.

#if PLATFORM(MAC) || PLATFORM(IOS_FAMILY)
WEBCORE_EXPORT bool screenSupportsHighDynamicRange(Widget* = nullptr);
#else
constexpr bool screenSupportsHighDynamicRange(Widget* = nullptr) { return true; }
#endif

@eocanha
Copy link
Member

eocanha commented Nov 29, 2024

What I had found until now on the Nexus box I have here is that there's a /proc/brcm/bhdm_edid device driver file that gives interesting info such as:

...
HDMI 1.3 Features
   Deep Color Support
      16bit: No;   12bit: Yes;   10bit: Yes;  Y444: Yes
...

but yes, your suggested strategy of asking the RDK services about it looks more general and multiplatform, indeed.

My field of expertise is centered in the multimedia side of the WPE WebKit browser, so I'm not very acquainted with all the RDK stuff around it or with how to invoke their services. Your curl call isn't working in the box I have here (maybe different port? maybe the development buildroot setup that I have here doesn't match 100% with a production RDK environment?).

I managed to make a call like this successful (metro2 is my box), although I didn't get any response from the server, meaning that curl never finishes nor prints any response:

curl -d '{"method": "WebKitBrowser.1.url", "params":"https://rdkcentral.com/"}' http://metro2/jsonrpc

However, this call gives the same result (never finishes, no response) and, obviously, there are no visible effects on the screen (no webpage to load in the browser this time):

curl -d '{ "method": "org.rdk.DisplaySettings.getTvHDRSupport" }' http://metro2/jsonrpc

A similar outcome happens if I use a command line WebSocket client, such as uwsc. I do get responses with improperly formatted (?) commands, tho:

$ uwsc http://metro2/jsonrpc
Websocket connected, you can send text messages of maximum 256 characters.
To exit uwsc, type !q<enter>
> {"method": "WebKitBrowser.1.url", "params":"https://www.igalia.com/"}
Send '{"method": "WebKitBrowser.1.url", "params":"https://www.igalia.com/"}'
> { "method": "org.rdk.DisplaySettings.getTvHDRSupport" }
Send '{ "method": "org.rdk.DisplaySettings.getTvHDRSupport" }'
> { "jsonrpc": "2.0", "id": 42, "method": "org.rdk.DisplaySettings.getTvHDRSupport" }
Send '{ "jsonrpc": "2.0", "id": 42, "method": "org.rdk.DisplaySettings.getTvHDRSupport" }'
Server message: '{"jsonrpc":"2.0","id":42,"error":{"code":2,"message":"ERROR_UNAVAILABLE"}}'

@modeveci Do you have some reliable example I can look to about how I can query the getTvHDRSupport and getSettopHDRSupport both from command line and from inside WebKit?

@amol-virnodkar-infosys
Copy link
Author

amol-virnodkar-infosys commented Jan 8, 2025

While testing our work-around solution, we found below edge cases which needs to be considered while implementing solution for this issue

  1. Hot plug scenario (where the user will change the HDR TV to a non-HDR TV randomly & vice versa) & then query matchMedia("(dynamic-range: high)") using the web inspector. After this check if matchMedia("(dynamic-range: high)") is returning appropriate return value based on the TV connected.
  2. Power on the STB without HDMI cable connected, after 3 mins connect HDMI cable & then query matchMedia("(dynamic-range: high)") using the web inspector. Then check if matchMedia("(dynamic-range: high)") is returning appropriate return value based on the TV connected.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

No branches or pull requests

3 participants