>>>> On Wed, Oct 19, 2016 at 12:19:30PM +0300, Laurent Pinchart wrote: (sorry, I lost your original mail) > >>> DRM bridges indeed don't create encoders. That task is left to the display > >>> driver. The reason is the same as above: bridges can be chained (including > >>> with an internal encoder that is not modelled as a bridge, and that's a case > >>> we have today), while the KMS model exposes a single encoder to userspace. > >>> Exposing DRM encoder objects as part of the KMS UABI was probably a mistake. > >>> Better solutions would have been to expose no encoder at all or all encoders > >>> in the chain. We are however stuck with this model as we can't break the UABI. > >>> For that reason a DRM encoder object doesn't represent an encoder but a chain > >>> of encoders. As a DRM bridge models a single encoder, the DRM encoder object > >>> must be created at a higher level, in the display driver. I wonder why you created 'bridge's instead of simply adding links to the encoders? (that's what ASoC did: the audio CODECs are linked) This way, in simple cases (most cases), there would have been crtc -> (encoder -> connector) instead of crtc -> (bridge + encoder) -> (bridge + connector) without any changes in the actual (encoder + connector)s. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
