From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keith Packard Date: Mon, 19 Sep 2011 06:53:27 +0000 Subject: Re: Proposal for a low-level Linux display framework Message-Id: MIME-Version: 1 Content-Type: multipart/mixed; boundary="=-=-=" List-Id: References: <1316088425.11294.78.camel@lappyti> <1316100594.23214.65.camel@deskari> <1316107275.23214.99.camel@deskari> <20110916175326.54567b14@lxorguk.ukuu.org.uk> <1316414014.1978.12.camel@deskari> In-Reply-To: <1316414014.1978.12.camel@deskari> To: Tomi Valkeinen , Alan Cox Cc: linux-fbdev@vger.kernel.org, linaro-dev@lists.linaro.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, Archit Taneja , "Clark, Rob" --=-=-= Content-Transfer-Encoding: quoted-printable On Mon, 19 Sep 2011 09:33:34 +0300, Tomi Valkeinen = wrote: > I think it's a bit more complex than that. True, there are MIPI > standards, for the video there are DPI, DBI, DSI, and for the commands > there is DCS. And, as you mentioned, many panels need custom > initialization, or support only parts of the DCS, or have other > quirks. So DSI is more like i2c than the DisplayPort aux channel or DDC. That seems fine; you can create a DSI infrastructure like the i2c infrastructure and then just have your display drivers use it to talk to the panel. We might eventually end up with some shared DRM code to deal with common DSI functions for display devices, like the EDID code today, but that doesn't need to happen before you can write your first DSI-using display driver. =2D-=20 keith.packard@intel.com --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iD8DBQFOdubnQp8BWwlsTdMRAusOAKCegZhdtYGIUQrd8gu69/RZ474TigCdFfyS YiohI3JOdnyz+UzbK0fRb7A= =wU+N -----END PGP SIGNATURE----- --=-=-=--