Hi, On Wed, 30 Mar 2022 at 20:47, Daniel Vetter <daniel@xxxxxxxx> wrote: > On Thu, Mar 31, 2022 at 12:14:31AM +0530, Jagan Teki wrote: > > Does it mean the userspace knows when to disconnect and connect the > > LVDS or HDMI? What if display-switch ISR will disconnect LVDS and > > connect HDMI when HPD is On and connect LVDS and disconnect HDMI when > > HDP is Off of-course it makes only one enable at a time. Don't do that. :) Be fully clear and explicit to userspace. Declare that there are multiple connectors (one LVDS, one HDMI), with different backing encoders as well. Declare their connection status appropriately, and send hotplug events when it changes. It is the responsibility of userspace to listen to these events, check the status, and react accordingly. In the absence of userspace, fbcon pretends to be userspace and tries to do the right thing. > If your QT app directly uses kms, but doesn't handle hotplugs, then yes > nothing at all happens. But that's just a userspace bug, not a kernel bug, > and we really should _not_ work around random userspace issues like this > in the kernel. > > Actually we cannot, because doing so would upset real kms compositors, > since the kernel doing funny stuff underneath it will at best confuse it. > And it some cases it resulted in crashes. FWIW, this is not because userspace sucks and can't handle corner cases; it's because hotplug is an unfixable race condition. The correct way to handle this is eventual consistency; you make the previous connections a zombie (allow them to continue even if they are no longer alive), tell userspace that the connections have changed, and trust that it will make the appropriate changes. > > Does it mean to initialize to encoder instances and start attaching > > those to respective bridge pipelines? > > I haven't checked, but I think it's not possible to change the bridge > chaining after drm_dev_register is called due to locking. > > So doing bridge attach/detach from the hotplug handler is a no-go. The > bridges need to be set up at driver load. > > Also with this design each bridge chain has its own drm_connector (HDMI > and LVDS, if I got you right). But that's just how bridges work. Yep. > > Can you link some references in the source tree for it to make a quick check? > > See the atomic_best_encoder callback, doc link here: > > https://dri.freedesktop.org/docs/drm/gpu/drm-kms-helpers.html?highlight=atomic_best_encoder#c.drm_connector_helper_funcs > > Although thinking about this you should have only 1 encoder for each > drm_connector (if you go with separate connector for hdmi and lvds), and > in that case the atomic helpers will take care of everything for you. Well > except making sure that only one encoder of the two is enabled at the same > time. Yep again. But that's fine: declare one DRM connector for each physical connector, only ever report one connector (and thus encoder) connected at a time, and things will work. Any userspace which tries to light up an output reported as 'disconnected' will expect that it will not work. Any userspace which does not react to hotplug events cannot work with outputs which are being hotplugged. And that's OK. You don't need to solve this with elaborate workarounds in your drivers, you just need to give userspace all the information it needs to make the right decisions, and then fix it if it doesn't. Cheers, Daniel
