Re: [PATCH v1 1/4] fbtft: Unorphan the driver

[Sam Ravnborg <sam@ravnborg.org>]

Hi Daniel,

On Tue, Feb 01, 2022 at 06:06:33PM +0100, Daniel Vetter wrote:
> On Tue, Feb 1, 2022 at 6:01 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> >
> > Hi Thomas,
> >
> > On Tue, Feb 1, 2022 at 5:16 PM Thomas Zimmermann <tzimmermann@suse.de> wrote:
> > > Am 31.01.22 um 11:18 schrieb Javier Martinez Canillas:
> > > > Another thing that's missing is a DRM_MODE_CONNECTOR_I2C, because I used for
> > > > now a DRM_MODE_CONNECTOR_Unknown.
> > >
> > > That might have implications on userspace. Maybe ask around. (Not that
> > > we actually run userspace on the device).
> >
> > Looking at the list of connector types (and wondering if we're gonna
> > need more when converting existing fbdev drivers to drm drivers),
> > there seem to be two different families of connector types, for
> >   1. transports between CRTC and display (e.g. VGA, DVID, HDMI),
> >   2. transports between CPU and CRTC (e.g. SPI, possibly USB, and
> >      the proposed I2C)?
> 
> I was trying to argue for a panel connector type and stop doing all
> these internal things because like you point out, it kinda doesn't,
> only the external connectors are relevant to users. But it didn't
> stick anywhere yet, we keep adding more connector types and then
> having to update userspace, which should map these all to "it's the
> panel" or something like that. But also since various technicolor
> abbreviations are about as useful to end-users as "unknown" it really
> doesn't matter, so I'm happy to let this bikeshed get a tad fancier
> every year :-)

We discussed DRM_MODE_CONNECTOR_PANEL or some sort - but I recall we ended up
with worrying about breaking userspace.
See https://lore.kernel.org/dri-devel/?q=DRM_MODE_CONNECTOR_PANEL

For this kind of change I chicken out due to lack of understanding of
the userspace implications.

Typing the patch is simple but taking the correct decision not so.

The discussion popped up when we made it mandatory to specify a
connector so we could better match up stuff between display
drivers/bridges and panel drivers.

	Sam