On Wed, 14 Jul 2021 20:18:57 +0200 Werner Sembach <wse@xxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx> wrote: > >> > >>> Am 30.06.21 um 10:21 schrieb Pekka Paalanen: > >>>> On Tue, 29 Jun 2021 13:02:05 +0200 > >>>> Werner Sembach <wse@xxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx> > >>>>>>> --- > >>>>>>> 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
Attachment:
pgp3RlA65nO37.pgp
Description: OpenPGP digital signature
_______________________________________________ amd-gfx mailing list amd-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/amd-gfx
