Greetings,
Original proposal: https://www.mail-archive.com/amd-gfx@lists.freedesktop.org/msg62387.html
Abstract: Add "preferred color format", "active color format", "active bpc", and "active Broadcast RGB" drm properties, to control color information send to the monitor.
It seems that the "preferred-" properties is not what is actually the most useful for the userspace devs.
Preferable (Note: with only a sample size of 2 people) would be a "force color format" property. If the color format is not available for the current Monitor and GPU combo. the TEST_ONLY check should fail and the property should not be setable.
This however opens another problem: When a Monitor is disconnected and a new one is connected, the drm properties do not get resetted. So if the old monitor did allow to set for example ycbcr420, but the new monitor does not support this color format at all, it will stay permanently black until the drm property is set to a correct value by hand. This is not an expected behavior imho.
So a discussion questions: Does it make sense that connector properties are keep for different Monitors?
If no: On connecting a new Monitor all atomic drm properties should be reset to a default value.
I have an idea how this could be implemented (correct me if i'm wrong): When an atomic property is attached it get assigned an inital value. But if I understood the docu correctly, this value is ignored because atomic properties use the getter and setter methods when their values are read or written. My implementation suggestion would be to iterate over all attached atomic properties once a new monitor is connected and reset them to this initial value, which should be unchanged since initialization? This assumes that besides the initial value being unused it's still a sane default for all drivers.
Kind Regards,
Werner Sembach
Greetings,
Original proposal: https://www.mail-archive.com/amd-gfx@lists.freedesktop.org/msg62387.html
Abstract: Add "preferred color format", "active color format", "active bpc", and "active Broadcast RGB" drm properties, to control color information send to the monitor.
It seems that the "preferred-" properties is not what is actually the most useful for the userspace devs.
Preferable (Note: with only a sample size of 2 people) would be a "force color format" property. If the color format is not available for the current Monitor and GPU combo. the TEST_ONLY check should fail and the property should not be setable.
This however opens another problem: When a Monitor is disconnected and a new one is connected, the drm properties do not get resetted. So if the old monitor did allow to set for example ycbcr420, but the new monitor does not support this color format at all, it will stay permanently black until the drm property is set to a correct value by hand. This is not an expected behavior imho.
User space is aware of output changes and already has to set properties such that the new output will light up. So IMO what you describe is expected behavior. What makes this still a bit hary is when you switch from user space which set the property to user space which is not aware of the property but this is a more general problem that already exists for all new properties. The solution here is a reset mechanism for user space. More context: https://oftc.irclog.whitequark.org/dri-devel/2021-06-16#1623837713-162384216...;
So a discussion questions: Does it make sense that connector properties are keep for different Monitors?
If no: On connecting a new Monitor all atomic drm properties should be reset to a default value.
I have an idea how this could be implemented (correct me if i'm wrong): When an atomic property is attached it get assigned an inital value. But if I understood the docu correctly, this value is ignored because atomic properties use the getter and setter methods when their values are read or written. My implementation suggestion would be to iterate over all attached atomic properties once a new monitor is connected and reset them to this initial value, which should be unchanged since initialization? This assumes that besides the initial value being unused it's still a sane default for all drivers.
Kind Regards,
Werner Sembach
On Tue, 3 Aug 2021 11:38:19 +0200 Werner Sembach wse@tuxedocomputers.com wrote:
Greetings,
Original proposal: https://www.mail-archive.com/amd-gfx@lists.freedesktop.org/msg62387.html
Abstract: Add "preferred color format", "active color format", "active bpc", and "active Broadcast RGB" drm properties, to control color information send to the monitor.
It seems that the "preferred-" properties is not what is actually the most useful for the userspace devs.
Preferable (Note: with only a sample size of 2 people) would be a "force color format" property. If the color format is not available for the current Monitor and GPU combo. the TEST_ONLY check should fail and the property should not be setable.
This however opens another problem: When a Monitor is disconnected and a new one is connected, the drm properties do not get resetted. So if the old monitor did allow to set for example ycbcr420, but the new monitor does not support this color format at all, it will stay permanently black until the drm property is set to a correct value by hand. This is not an expected behavior imho.
So a discussion questions: Does it make sense that connector properties are keep for different Monitors?
If no: On connecting a new Monitor all atomic drm properties should be reset to a default value.
I have an idea how this could be implemented (correct me if i'm wrong): When an atomic property is attached it get assigned an inital value. But if I understood the docu correctly, this value is ignored because atomic properties use the getter and setter methods when their values are read or written. My implementation suggestion would be to iterate over all attached atomic properties once a new monitor is connected and reset them to this initial value, which should be unchanged since initialization? This assumes that besides the initial value being unused it's still a sane default for all drivers.
Kind Regards,
Werner Sembach
Hi Werner,
I just wanted to say that I appreciate the effort and something like these are things I would likely want to use some day in Weston, but currently I can't spend time on this since it's still so far in the future for me. I also feel that I've said what I can without spending a significant amount of time thinking how it should actually work.
The same goes with the thing pointed out by Sebastian, the KMS property reset idea. Since I can't really work on it now, I'll stop shouting about it and wait for problems to arise in the wild and see where that leads. (Probably just patching the KMS client of the day to set a couple more KMS properties.)
Thanks, pq
dri-devel@lists.freedesktop.org
-
Pekka Paalanen -
sebastian＠sebastianwick.net -
Werner Sembach