I’ve been hit by spam reports yesterday and today, but mods can revive them.
1 Like
I didn’t even had the chance to try it before the comment was hidden. Wtf?
Here’s the instructions:
In Sailfish Browser, about:config:
gfx.color_management.mode → 1
Download a Display P3 profile from Display P3 | Three Component Color Encoding Registry
gfx.color_management.display_profile → full path to the .icc file
Close and reopen the browser
Test at SVG test image — before step 1 the Adobe’98, Custom ICC and Gamma 1.0 columns are visibly wrong; after, all bands are smooth. After step 3 everything renders noticeably less saturated, i.e. correctly for the panel.
7 Likes
just checked. just changing the value to 1 in about:config was enough to make them look basically identical! So there is already system-level correction!
Edit: no both images are rRGB now. Thanks for the correction
Changing to mode = 1 makes both sRGB so they look identical, but since the panel is wider gamut it overshoots and makes colours more saturated. That’s why applying the P3 .icc is needed. But they both work only within the browser, and won’t affect anything elsewhere in the system.
2 Likes
My best (untested and unconpiled) bet for system-level fix would be
1. libhybris — compat/hwc2/hwc2_compatibility_layer.cpp
hwc2_error_t hwc2_compat_display_set_color_mode(hwc2_compat_display_t* display,
int32_t mode, int32_t renderIntent)
{
hal::Error error = display->self->setColorMode(
static_cast<hal::ColorMode>(mode),
static_cast<hal::RenderIntent>(renderIntent));
return static_cast<hwc2_error_t>(error);
}
hwc2_error_t hwc2_compat_display_get_color_modes(hwc2_compat_display_t* display,
int32_t* outModes,
uint32_t* inOutNumModes)
{
std::vector<hal::ColorMode> modes;
hal::Error error = display->self->getColorModes(&modes);
if (error != hal::Error::NONE)
return static_cast<hwc2_error_t>(error);
uint32_t count = static_cast<uint32_t>(modes.size());
if (outModes) {
uint32_t copy = count < *inOutNumModes ? count : *inOutNumModes;
for (uint32_t i = 0; i < copy; i++)
outModes[i] = static_cast<int32_t>(modes[i]);
}
*inOutNumModes = count;
return static_cast<hwc2_error_t>(hal::Error::NONE);
}
Called with outModes = NULL first to get the count, then again with a buffer.
2. hwc2_compatibility_layer.h — inside the extern “C” block:
hwc2_error_t hwc2_compat_display_set_color_mode(hwc2_compat_display_t* display,
int32_t mode, int32_t renderIntent);
hwc2_error_t hwc2_compat_display_get_color_modes(hwc2_compat_display_t* display,
int32_t* outModes,
uint32_t* inOutNumModes);
3. The glibc stub — two lines alongside the existing macros:
HYBRIS_IMPLEMENT_FUNCTION3(hwc2, hwc2_error_t, hwc2_compat_display_set_color_mode,
hwc2_compat_display_t*, int32_t, int32_t);
HYBRIS_IMPLEMENT_FUNCTION3(hwc2, hwc2_error_t, hwc2_compat_display_get_color_modes,
hwc2_compat_display_t*, int32_t*, uint32_t*);
Steps 1-3 are purely additive. Nothing changes until step 4 calls them.
4. qt5-qpa-hwcomposer-plugin — hwcomposer_backend_v20.cpp
static void selectSrgbColorMode(hwc2_compat_display_t *display)
{
// AOSP ColorMode / RenderIntent enum values
const int32_t COLOR_MODE_SRGB = 7;
const int32_t RENDER_INTENT_COLORIMETRIC = 0;
uint32_t numModes = 0;
if (hwc2_compat_display_get_color_modes(display, NULL, &numModes) != HWC2_ERROR_NONE
|| numModes == 0)
return; // not supported here, carry on regardless
std::vector<int32_t> modes(numModes);
if (hwc2_compat_display_get_color_modes(display, modes.data(), &numModes) != HWC2_ERROR_NONE)
return;
for (uint32_t i = 0; i < numModes; i++) {
if (modes[i] == COLOR_MODE_SRGB) {
hwc2_compat_display_set_color_mode(display, COLOR_MODE_SRGB,
RENDER_INTENT_COLORIMETRIC);
return;
}
}
}
Called in the constructor after HWC_PLUGIN_ASSERT_NOT_NULL(hwc2_primary_display), and again in sleepDisplay() after the power-on call in case the mode doesn’t survive a power cycle.
Note it skips silently if the display doesn’t report SRGB, and ignores failures rather than aborting. Some devices expose the call without a working vendor backend behind it.
One thing that confirms the approach: AOSP’s ColorMode enum has NATIVE = 0, SRGB = 7, DISPLAY_P3 = 9 — exactly the ModeIDs in MediaTek’s cust_pq.xml. So those aren’t vendor numbers, the config is using the standard enum. Which is why the code should query rather than hardcode: the same patch then works on any device whose composer reports SRGB.
15 Likes
The result is striking, to say the least. Brilliant POC. 
3 Likes
@pvuorela just a ping, here is at least quite good guess how problem could be tackled in upstream. A little up is great investigation done by @ptu
One more thing to manage expectations.
The system-wide solution above sets everything to sRGB, displaying all elements designed in sRGB correctly, but not actually enabling P3 gamut. So the result would look less vivid since the colours would no longer be stretched too wide.
To actually enable P3, you would need the applications to declare P3 when they create their surface, and Lipstick to handle a screen with mixed sRGB and P3 surfaces.
Setting up the proper sRGB colour space first would be the right place to start nevertheless.
For reference, here’s how its done on KWin.
9 Likes
Just updated to 5.3.0.10, looks like this issue has been fixed.
3 Likes
Just to make sure.
You are talking about color being slightly off, or you had blacks shown as green/yellow and in general having this hue overall?
Both (Oh, need 20 characters
1 Like
Just updated to 5.3.0.10
really???
1 Like
Sami Pienimäki said in the video inside the Greetings from Kaupinoja hackday blog post, that Jolla is aiming 5.3 to get into CBeta in October. I don’t know if @0312birdzhang is in CBeta, or if it is possible to set your release version to 5.3 with ssu at this point, but let’s hope all the supported devices gets official 5.3 release before end of the year.
I’m not in CBeta, just use ssu magic 
1 Like
Best news since December 8th.
Thanks!
Sounds amazing, can’t wait to test this!
I just updated and reds and greens still look oversaturated 
1 Like
Do you still experience the tint?
I want to throw a friendly reminder here that they are very likely separate issued and thus require their own fixes.
no, i never had the tint issue, so i was really hopeful for the color space fix
1 Like