On Wed, Nov 23, 2016 at 4:52 PM, Jani Nikula <jani.nikula@xxxxxxxxxxxxxxx> wrote: >> Take the CDN DP driver in rockchip for example (posted yesterday). >> There's a worker in the driver that is responsible for handling >> hpd/extcon events from the USB-C port. Ideally, this worker should >> just be a thin shell around a kms uevent that lets userspace know >> there's been a change. Unfortunately since we need to make re-training >> work (/me grumbles about productization) seamlessly, we need to add a >> bunch of goo into the worker to handle re-training. Since we need to >> handle re-training there and in modeset, we need to properly >> synchronize things. So we end up with a bunch of code that doesn't >> *really* need to be there. >> >> So is the correct path forward to add GOOD/BAD connection handling to >> Chrome/drm_hwc > > I think so. > >> and rip re-training out of the various kernel drivers? > > IMO if it works, don't change it, at least not in a rush. It also > depends on the hardware and the driver; the amount of code required may > be vastly different for various drivers. > > Personally, I think in the long run letting userspace help here leads to > a simpler design and more efficient happy day scenario handling, and > userspace knows what's going on. We can't rip out re-training from existing drivers since it would break existing userspace in certain cases (like cable re-plug into same screen). But we could try to not implement so much for new drivers. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
