On Wed, 14 Jul 2021 20:18:57 +0200 Werner Sembach wse@tuxedocomputers.com wrote:
Am 01.07.21 um 13:30 schrieb Werner Sembach:
Am 01.07.21 um 09:42 schrieb Pekka Paalanen:
On Wed, 30 Jun 2021 11:42:10 +0200 Werner Sembach wse@tuxedocomputers.com wrote:
Am 30.06.21 um 10:21 schrieb Pekka Paalanen:
On Tue, 29 Jun 2021 13:02:05 +0200 Werner Sembach wse@tuxedocomputers.com wrote:
Am 28.06.21 um 19:03 schrieb Werner Sembach: > Am 18.06.21 um 11:11 schrieb Werner Sembach: >> Add a new general drm property "active bpc" which can be used by graphic >> drivers to report the applied bit depth per pixel back to userspace. >> >> While "max bpc" can be used to change the color depth, there was no way to >> check which one actually got used. While in theory the driver chooses the >> best/highest color depth within the max bpc setting a user might not be >> fully aware what his hardware is or isn't capable off. This is meant as a >> quick way to double check the setup. >> >> In the future, automatic color calibration for screens might also depend on >> this information being available. >> >> Signed-off-by: Werner Sembach wse@tuxedocomputers.com >> --- >> drivers/gpu/drm/drm_connector.c | 51 +++++++++++++++++++++++++++++++++ >> include/drm/drm_connector.h | 8 ++++++ >> 2 files changed, 59 insertions(+)
New idea: Instead of the "active"-properties with various if cases in the kernel code, there could just be blob properties exposing the hdmi infoframes, hdmi general control packages, dp misc0 and misc1 and dp vsc sdp.
Combined they have all the color information and it is made sure that it's what is actually send to the monitor (I would consider sending something differed then what is told in the infoframes a bug).
They also have built in version numbers, if in the future they contain more information.
Only disadvantage: We leave parsing for human readable output to the userspace.
Alternatively keep the "active"-properties but fill them from the infoframes.
I'm not entirely sure where to do that on amd, because there the infoframes are directly created in the dc code shortly before writing them to the hardware registers and immediately forgotten afterwards. But you still have access to the connector struct from that code so the property could be updated directly there.
Hi,
I'm not fundamentally against that as long as we have a common userspace library to parse those blobs. In libdrm perhaps? Or a new library?
But I also don't know about the technical feasibility, is it a good idea.
OTOH, that could be the best thing for testing drivers vs. KMS UAPI when you don't have a hardware HDMI/DP grabber to inspect the infoframes. So maybe kernel CI would like that?
Thanks, pq