On Tue, Jan 09, 2024 at 11:12:11PM +0000, Andri Yngvason wrote: > Hi Daniel, > > þri., 9. jan. 2024 kl. 22:32 skrifaði Daniel Stone <dan...@fooishbar.org>: > > > On Tue, 9 Jan 2024 at 18:12, Andri Yngvason <an...@yngvason.is> wrote: > > > + * active color format: > > > + * This read-only property tells userspace the color format > > actually used > > > + * by the hardware display engine "on the cable" on a connector. > > The chosen > > > + * value depends on hardware capabilities, both display engine and > > > + * connected monitor. Drivers shall use > > > + * drm_connector_attach_active_color_format_property() to install > > this > > > + * property. Possible values are "not applicable", "rgb", > > "ycbcr444", > > > + * "ycbcr422", and "ycbcr420". > > > > How does userspace determine what's happened without polling? Will it > > only change after an `ALLOW_MODESET` commit, and be guaranteed to be > > updated after the commit has completed and the event being sent? > > Should it send a HOTPLUG event? Other? > > > > Userspace does not determine what's happened without polling. The purpose > of this property is not for programmatic verification that the preferred > property was applied. It is my understanding that it's mostly intended for > debugging purposes. It should only change as a consequence of modesetting, > although I didn't actually look into what happens if you set the "preferred > color format" outside of a modeset.
This feels a bit irky to me, since we don't have any synchronization and it kinda breaks how userspace gets to know about stuff. For context the current immutable properties are all stuff that's derived from the sink (like edid, or things like that). Userspace is guaranteed to get a hotplug event (minus driver bugs as usual) if any of these change, and we've added infrastructure so that the hotplug event even contains the specific property so that userspace can avoid re-read (which can cause some costly re-probing) them all. As an example you can look at drm_connector_set_link_status_property, which drivers follow by a call to drm_kms_helper_connector_hotplug_event to make sure userspace knows about what's up. Could be optimized I think. This thing here works entirely differently, and I think we need somewhat new semantics for this: - I agree it should be read-only for userspace, so immutable sounds right. - But I also agree with Daniel Stone that this should be tied more directly to the modeset state. So I think the better approach would be to put the output type into drm_connector_state, require that drivers compute it in their ->atomic_check code (which in the future would allow us to report it out for TEST_ONLY commits too), and so guarantee that the value is updated right after the kms ioctl returns (and not somewhen later for non-blocking commits). You probably need a bit of work to be able to handle immutable properties with the atomic state infrastructure, but I think otherwise this should fit all rather neatly. Cheers, Sima > > The way I've implemented things in sway, calling the > "preferred_signal_format" command triggers a modeset with the "preferred > color format" set and calling "get_outputs", immediately queries the > "actual color format" and displays it. > > Regards, > Andri -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
