Il 26/02/26 11:26, AngeloGioacchino Del Regno ha scritto:

Il 26/02/26 07:24, CK Hu (胡俊光) ha scritto:

quoted

On Fri, 2026-02-06 at 08:28 -0500, Nícolas F. R. A. Prado wrote:

quoted

On Fri, 2026-02-06 at 11:09 +0200, Pekka Paalanen wrote:

quoted

On Fri, 2 Jan 2026 13:40:21 -0500
Harry Wentland [off-list ref] wrote:

quoted

On 2026-01-01 07:37, Shengyu Qu wrote:

quoted

在 2025/12/30 02:53, Shengyu Qu 写道:

quoted

在 2025/12/24 3:44, NÃ colas F. R. A. Prado 写道:

quoted

quoted

quoted

quoted

Given the lack of support for writeback connectors on the
MediaTek KMS driver, combined with limited hardware
documentation, I haven't been able to verify the correctness
of
each curve, only that they were visually sane (gamma curves
made
the image on the display brighter, while inverse gamma made
it
darker).

Hmmm I don't think this is acceptable. sRGB/scRGB has two
transfer
functions mentioned in original specification[1]. To keep color
accuracy, we need someone from mediatek confirm whether this is
piece- wise or pure power 2.2 transfer function, this is
already
done in original amdgpu color pipeline series, sRGB means
piece-wise while also dedicated power 2.2 function exists.

Not sure what you mean with this not being acceptable. This is
about
enabling HW support for this functionality. Not every HW has
writeback for testing. At some point you'll have to trust the
driver
devs if you're going to use functionality of the driver. We're not
always going to get everything perfect, but if that's really such a
worry you can always use shaders to do precisely what you want.

Hi Harry,

yes, but I understood that in this case, the hardware documentation
available is so vague that it's impossible to say what it will
actually
do. There are no formulas given or referenced in the documentation,
are
there, Nícolas?

No formulas at all, the only documentation I had available for the
curves was the register definition, which simply lists the possible
values: SCRGB, BT709, BT2020, HLG.

Hi, Nicolas:

In [1], it shows OVL could output data to WDMA which could write data into DRAM.
Its control is similar to RDMA. RDMA read data from DRAM and WDMA write data into 
DRAM.
Do you have interest to implement WDMA?

I wrote a WDMA driver a long ago, but I couldn't get it to work (though, I admit I
didn't try hard to actually get it working).... if you want to take a look to check
if anything obvious is missing, the driver is here:

https://gitlab.collabora.com/mediatek/aiot/linux/-/blob/mediatek-dev/drivers/gpu/ 
drm/mediatek/mtk_disp_wdma.c?ref_type=heads

The driver I wrote was supposed to work on MT8781 Helio G99 (for a personal project

Eh, sorry for the double email, I was meaning MT6789 Helio G99 - just to be
extremely clear, though that wasn't much important (given that the WDMA IP is
anyway practically the same between the two..).

as in upstreaming of the Xiaomi Poco M5 smartphone) and on MT8195 as a PoC.
I did test both platforms and this driver didn't work on both... not sure if that
was because I misconfigured the MMSYS routing (on both) or if there's any actual
issue with the driver I wrote.

Again, didn't invest much time on this, anyway, so some obvious issue might be
present.

Cheers,
Angelo

quoted

This is just a suggestion.
I could accept we believe what document say first and wait for someone to verify it.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/ 
drivers/soc/mediatek/mt8195-mmsys.h?h=v7.0-rc1#n8

Regards,
CK

quoted