<Marijn[m]>
I'll summarize it either way because I don't we wandered every possible avenue yet that isn't "let me send a patch series with 10-bpc support"
<Marijn[m]>
Fekz115: first up you're right that the constants for 10-bpc are available in the kernel; they're not only used by Qcom hardware (it's all shared!)
<Marijn[m]>
We were trying to first resolve some topology-related issues on his hardware before diving into this issue. We also found that the DSC stream is still 8 bits per pixel, so the total data sent to the panel should be the same. Adrian found a hint about using an 8-bpc mode in his firmware, but didn't find a panel command to change his panel to this. I don't think that might be necessary as the bits_per_component parameter is encoded in the DSI
<Marijn[m]>
DSC Picture Parameter Set, which your panel driver should send to the panel.
<Marijn[m]>
If it does send that PPS, you might try just setting bpc to 8 and hope that it might just work (or at the very least show colorful corruption, indicating parts are turned on and working at least)
<Marijn[m]>
Adrian: did you also try setting bpc to 8 after applying the 1:1:1 topology commit?
<Adrian[m]>
Marijn[m]: I am using bpc=8 with 1:1:1 topology
<Adrian[m]>
Otherwise it would error due to your patch that was sent here earlier
<Fekz115>
Sorry guys, didn't want to annoy you
<Marijn[m]>
Adrian: we might try removing all the safeguards and set 10, but I'm sure some code will have to be updated. Likewise, I think the 10-bit DSI format should be added?
<Marijn[m]>
It's been a while since I last looked into this, since Sony only provides fake 8-bit panels with FRC
<Adrian[m]>
Marijn[m]: I will try removing that forced error and see what 1:1:1 topology with bpc=10 results in. Currently I don't even see jank so I'm not even sure if my configuration is otherwise correct :/
<Marijn[m]>
I had hoped you'd at least see corruption on the screen. Are the errors in dmesg exclusively timeouts, or also a few -22s?
<Adrian[m]>
I don't see any panel errors until I write a value to that backlight node or until ~5 minutes after boot when the panel seems to think it wants to turn off
<Marijn[m]>
Last time you were seeing 30fps, so the tear command is definitely not working or the panel is not responding (30 fps is what MDP generates)
<Marijn[m]>
But the panel is also not rejecting initial setup commands, only the poweroff or poking at brightness
<Marijn[m]>
What I've done sometimes is send a brightness command directly before or after power_on() and that worked
<Adrian[m]>
wouldn't that just force it to error early?
<Adrian[m]>
<Adrian[m]> "I will try removing that..." <- 1:1:1 with bpc=10 seems to be the same as bpc=8. modtest still reports 30Hz
<Adrian[m]>
s/modtest/modetest/
<Marijn[m]>
<Adrian[m]> "wouldn't that just force it to..." <- The other dsi commands are sent correctly, or so it seems
<Marijn[m]>
So it might be that the panel stops responding after some time/command?
<Marijn[m]>
<Adrian[m]> "1:1:1 with bpc=10 seems to be..." <- 30hz comes from sync_cfg_height, if we disable that we'll see the real (lack of) panel vblanls
<Marijn[m]>
* In reply to @gelbpunkt:matrix.org
<Marijn[m]>
1:1:1 with bpc=10 seems to be the same as bpc=8. modetest still reports 30Hz
<Marijn[m]>
30hz comes from sync_cfg_height, if we disable that we'll see the real (lack of) panel vblanks