Hi Daniel, On Tuesday 29 Nov 2016 11:27:20 Daniel Vetter wrote: > On Tue, Nov 29, 2016 at 11:58:44AM +0200, Laurent Pinchart wrote: > > On Tuesday 29 Nov 2016 10:56:53 Daniel Vetter wrote: > >> On Tue, Nov 29, 2016 at 11:04:39AM +0200, Laurent Pinchart wrote: > >>> The drm_bridge object models on- or off-chip hardware encoders and > >>> provide an abstract control API to display drivers. In order to help > >>> display drivers creating the right kind of drm_encoder object, expose > >>> the type of the hardware encoder associated with each bridge. > >>> > >>> Signed-off-by: Laurent Pinchart > >>> <laurent.pinchart+renesas@xxxxxxxxxxxxxxxx> > >> > >> DRM_MODE_ENCODER_BRIDGE. Problem solved, because in reality no one cares > >> one iota about the encoder type. > > > > It's exposed to userspace though, are you 100% sure we won't break > > anything ? > > We've added DP, DSI, DPMST and DPI encoder types thus far, no one > screamed. In that case why don't we go one step further and remove the encoder type completely ? We can't remove the field from the API, but we can hardcode it to a single value. There are however drivers that rely on the encoder type (radeon, nouveau, sti, amdgpu, msm and rcar-du, but I'll fix the last one) so we'd need to address that first. If we don't want to remove the encoder_type field from in-kernel structures and let drivers use it, then I don't think DRM_MODE_ENCODER_BRIDGE would be a good option, we should report the real type instead. > We should be fine I think. Connector types are a bit different, userspace > (at least X) wants to pretty-print them for xrandr names. -- Regards, Laurent Pinchart
