>>>> 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/
