From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pekka Paalanen Subject: Re: [PATCH v7 09/11] drm: uevent for connector status change Date: Tue, 4 Jun 2019 10:06:09 +0300 Message-ID: <20190604100609.235cd763@eldfell.localdomain> References: <20190515103731.16855195@eldfell.localdomain> <20190515082449.GA17751@phenom.ffwll.local> <20190516112211.1cd5a8c6@eldfell.localdomain> <20190516122455.GA3851@phenom.ffwll.local> <20190517130824.17372663@eldfell.localdomain> <20190520161107.GA21222@phenom.ffwll.local> <20190521095505.7ef1cbdf@eldfell.localdomain> <9953e1fa-dafa-21c1-9604-50ed1e9fecaf@daenzer.net> <20190603150834.GL21222@phenom.ffwll.local> <6782500f2aa3a2b1fbf2dde6a6c31d1bba8b575c.camel@intel.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1818781260==" Return-path: In-Reply-To: <6782500f2aa3a2b1fbf2dde6a6c31d1bba8b575c.camel@intel.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: "Ser, Simon" Cc: "airlied@linux.ie" , "michel@daenzer.net" , "dri-devel@lists.freedesktop.org" , "paul.kocialkowski@bootlin.com" , "maxime.ripard@bootlin.com" , "thomas.petazzoni@bootlin.com" , "Vetter, Daniel" , "intel-gfx@lists.freedesktop.org" List-Id: intel-gfx@lists.freedesktop.org --===============1818781260== Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/W.iY6vTYf6bkZBrNUXl5Oi9"; protocol="application/pgp-signature" --Sig_/W.iY6vTYf6bkZBrNUXl5Oi9 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Mon, 3 Jun 2019 15:19:13 +0000 "Ser, Simon" wrote: > On Mon, 2019-06-03 at 17:08 +0200, Daniel Vetter wrote: > > It's definitely a very suboptimal situation. Not sure there's a good way > > out. The trouble here is that i915 ended up configuring crtc/connectors > > differently than -modesetting (to allow fastboot, which I think is still > > i915 exclusive). This then highlighted that modesetting can't do atomic > > modesets if you try to reassign connectors. > >=20 > > One idea I have is that vgms would help compositors to play out a bunch= of =20 >=20 > Just so people aren't confused: I think Daniel meant "vkms" here :P >=20 > > standard scenarios, even automated. But that's not there yet, and every > > compositor project needs to care beyond "boots on my laptop, ship it". = No > > idea that's even possible. =20 >=20 > Having documentation for userspace is also important IMHO. >=20 > Regarding automated compositor testing, it's probably not possible to > have a single place where all compositors are tested: vkms should > probably be included as part of their CI. Thoughts? >=20 > Anyway, we could start a discussion to see if compositor people are > interested. Or have you already talked to some compositor maintainers? FWIW, I would absolutely *love* to be able to exercise Weston's DRM-backend in Gitlab CI with anything, even just vkms, at least in Weston's test suite to test Weston against KMS in general. Once that is up, kernel people could replicate from that to their own CI for testing drivers against known userspace. I think it would be an awesome long term plan, whether uAPI specs appear or not. Long term, because I have no idea who could work on it when. In theory, all I would be waiting for is for vkms to be just featureful enough and to figure out a way how to get that running inside Gitlab CI. Thanks, pq --Sig_/W.iY6vTYf6bkZBrNUXl5Oi9 Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEJQjwWQChkWOYOIONI1/ltBGqqqcFAlz2GGEACgkQI1/ltBGq qqc7bQ//T+X7rFpCzQPGd0CUmY4WF5R2A896kDEBG5HCSdBRLOLGZ7C5hBK4zQac gVYha5Hq3GqKPuoOfuAW8XneOgsrMX+89jWA7s/NwETt1W5QDuEsjWEvxWdcvi48 WgvOnPHuKaFWEEOpyVHTWVKaEB7lkyrYitG5g+My4kql5ANEAq2U5BfVgbfBwnNc w8xhgx8tOK71oH7zt2XYd8rQT+QFTE6RK2QWhrgcUxzjPXXCgp+BZCtfRxAWhASF Mp1CLQVKvvH4k26pfrq2tKTZW8Epyn2nqA6dc7/RD00jpPKvAvG7NC/uDso6GBsF sR5ajTYRkkG86aYDwWKHguCph3J3cywNFrMtPPRFO6EIWbo8mUVi8Rh7+8UPj3jv AP4pt2/MWA13WB3ExlXV1D0sa/B6sWFQnY6FNMb/FX+Zad5q4FyNnaQIVmdObVJX p9XHjnLcmMy6wqRJhYvTcoUAPEbJqe/GXsWqp2D5UrvySRaKVNLpBFg1IPISMxMv ZGb3WZ5j9ewjVbVd9kQenH/+vB34Oi/e/kdSm5ZMW3AQv14PuIkVUn1w9kyTvRim Jk5lf5AZYWlGORfiJZuXUgrqvRy7CdA0iwBjMExG/4eNNaqCDI0oy4yeD9wYU2Gc rysEf5lYwHf4ebySiVpNrxQfZUxRODJRGRnG6j5ZymowIcIOlTM= =37SF -----END PGP SIGNATURE----- --Sig_/W.iY6vTYf6bkZBrNUXl5Oi9-- --===============1818781260== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KSW50ZWwtZ2Z4 IG1haWxpbmcgbGlzdApJbnRlbC1nZnhAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vaW50ZWwtZ2Z4 --===============1818781260==--