On Wed, Jun 03, 2020 at 01:17:14PM +0000, Simon Ser wrote: > On Wednesday, June 3, 2020 1:36 PM, Daniel Vetter <dan...@ffwll.ch> wrote: > > > On Wed, Jun 03, 2020 at 02:13:43PM +0300, Ville Syrjälä wrote: > > > > > On Wed, Jun 03, 2020 at 10:45:23AM +0000, Simon Ser wrote: > > > > > > > In update_output_state, the link-status property was reset to GOOD to > > > > ensure legacy drmModeSetCrtc re-trains the link. However this auto-reset > > > > is also performed on an atomic commit without ALLLOW_MODESET. If a > > > > > > I didn't think udate_output_state() was getting called for > > > non-legacy paths. Where is that coming from? > > > > Oops, I'm blind and you're right, there's no bug. We already only > > force-set this for legacy modeset (and fbcon). > > Indeed, good catch Ville. set_config is purely a legacy thing. > > > That also means that atomic userspace has to handle this, which is maybe > > not so awesome ... So maybe we need to duct-tape over this for atomic too, > > and in that case it should be only done when ALLOW_MODESET is set. > > > > But maybe all the compositors that care will handle this :-/ > > Not fond of this because we'll basically end up with some drivers > checking for link-status (none do that yet) and some user-space > resetting it to GOOD. It'll break only if user-space doesn't reset and > a driver which checks link-status is used. Driver-specific behaviour > isn't great.
See my other reply, drivers don't need to check for GOOD, it's kinda magic. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
