Date: Wed, 24 Feb 2016 09:08:27 +0100 From: =?UTF-8?Q?Jean-S=c3=a9bastien_P=c3=a9dron?= <jean-sebastien.pedron@dumbbell.fr> To: freebsd-x11@freebsd.org Subject: Re: Guide to contribute to kernel video drivers Message-ID: <56CD64FB.3000103@dumbbell.fr> In-Reply-To: <56CAEF4A.9070208@gmail.com> References: <56C708E9.8050203@FreeBSD.org> <20160220104349.2bc8b22a@fujitsu> <56C8F89D.5060703@dumbbell.fr> <CABHD1wSFdGUZ5wmDzN8Twu5F1BeERoJZ5zeRaGjNMv%2Bbb7gwYA@mail.gmail.com> <56CAE91D.7060905@dumbbell.fr> <56CAEF4A.9070208@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --iDpJ9jWQb8V3Gvf8vFGn3I5JhmptO7XHr Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 22/02/2016 12:21, Alexander Mishurov wrote: > 1. Linux kpi is conflicting with drm_os_freebsd and drm_scatter and may= > be some other things from drm. This means we have to migrate whole drm > core to linux kpi and therefore that affects at least radeon drivers. > It's quite huge amount of work in comparison to only i915. What about > existing non i915 drivers depend on drm and drm_os_freebsd ? The whole DRM needs to be moved to linuxkpi, not just a driver. Some interfaces will change in the process and we must keep DRM components consistent. > 2. Move to linux kpi is not enough, I'm sure there should be one more > layer like drm_os_freebsd on top of linux kpi with our own macros, > inlines and other things for minimizing modifications of the original > Linux driver sources because linux kpi covers only basic things. No, I believe if linuxkpi misses something, it should be added there, not in an additional wraper. The goal is not to eliminate completely the diff with Linux. For instance, the integration with the VM won't be abstracted: the Linux VM and the FreeBSD vm work differently. This must be reflected into DRM. Another one is I=B2C. FreeBSD and Linux' I=B2C subsystems have incompatib= le design and API. Unlike the VM however, this looks more like a pain point :) In the beginning, we will keep the I=B2C calls unabstracted, but in th= e long term, it would be nice to add a Linux API wrapper to our I=B2C subsystem, if it's possible. --=20 Jean-S=E9bastien P=E9dron --iDpJ9jWQb8V3Gvf8vFGn3I5JhmptO7XHr Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJWzWUAXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2NzA4N0ZEMUFFQUUwRTEyREJDNkE2RjAz OUU5OTc2MUE1RkQ5NENDAAoJEDnpl2Gl/ZTMkmIQAJjSOoFXKGzfAon5fM2XNN5s caJDN4bK3poZnTkhFBvfzC9rAMxsI6TE8orTfZAgxbUTrYUpzJZO9uCdMS5hLwxQ KzSdvdxxJwS+erqgrh8JhgZkzCKZPo9QeQiFySyMJisN/g5T5ByX2tkc7wKqvqqG oECJMkx8TmrE9BeResr1pgyYB09eyfvjIMtlnvGIes0FkG8AIh4ySdnmZ0n5OsOo 4kEl6KmtT5M7r014arWM18BijZh3QmGGwDgCaJiLt2825H97qyDKupst4koj8QTu YVfuyyvGzppNIYlNNMeEiz1bfSjNjLdNMPSgqfcXfld52orJ385jjmUep36Q2/vO C9OHvSpT/2N9opKw/JoPLWtp5f8+IAR06m7DzSVoIKy/n7tOPrw1rLXUnjBbSGFp YOGweJ9lMiWsiIa5ZPZPFfqP9cp1+3DKUDd2LrVyamE3DojaJX4UJW/OsvkmdKxu JmeVcWEV6twx/ePngOEjrAi9XBYTO8StuzUx0BLiZD63/QIGtzTMCIP3CD0eBHDQ 739YGjqS+n1TTVU82VZkLRbPU/cpBp2Iza+AcxX8WBq2Z4r3bDDheiYZq8otXWCT ZU5GBOvS2YiUG1dtjQAdCPLXEgJRQhKxTouXAfXUZ9JeEmxpUY6q2oabFPKCBwqp xOSx0X01AVuWgo/kVC+c =lRow -----END PGP SIGNATURE----- --iDpJ9jWQb8V3Gvf8vFGn3I5JhmptO7XHr--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?56CD64FB.3000103>