From owner-freebsd-x11@freebsd.org Fri Feb 19 12:22:17 2016 Return-Path: Delivered-To: freebsd-x11@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 631F3AADC33 for ; Fri, 19 Feb 2016 12:22:17 +0000 (UTC) (envelope-from dumbbell@FreeBSD.org) Received: from mail.made4.biz (mail.made4.biz [IPv6:2001:41d0:2:c018::1:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 317FE14EE for ; Fri, 19 Feb 2016 12:22:17 +0000 (UTC) (envelope-from dumbbell@FreeBSD.org) Received: from [176.158.145.63] (helo=magellan.dumbbell.fr) by mail.made4.biz with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86 (FreeBSD)) (envelope-from ) id 1aWk4c-000NIG-Nn for freebsd-x11@FreeBSD.org; Fri, 19 Feb 2016 13:22:15 +0100 To: "freebsd-x11@freebsd.org" From: =?UTF-8?Q?Jean-S=c3=a9bastien_P=c3=a9dron?= Subject: Guide to contribute to kernel video drivers X-Enigmail-Draft-Status: N1110 Message-ID: <56C708E9.8050203@FreeBSD.org> Date: Fri, 19 Feb 2016 13:22:01 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="hwamfGoVR3h4Vk2I9sfFUp6NFtclI2sUC" X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2016 12:22:17 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --hwamfGoVR3h4Vk2I9sfFUp6NFtclI2sUC Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi! As promised a (too) long time ago, here are some instructions to get you started with kernel video drivers. First, don't be afraid by the kernel. In the kernel, you have to live with some constraints and debugging is more challenging, but it's not an order of magnitude harder than userland. Moreover, we are porting existing working code. =3D=3D Requirements =3D=3D o You need to run CURRENT on the test computer. I recommend you work from another computer. You only need to copy the built kernel to the test computer. o You need to setup kernel core dumps on the test computer. This is step #1 here: https://wiki.freebsd.org/Graphics/Update%20i915%20GPU%20driver%20to%20Lin= ux%203.8#Testing_Instructions_.2F_How_To To test core dumps work: sysctl debug.kdb.panic=3D1 o You need a clone of Linux. I use the following Git remotes: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git The second one is useful to get the patch releases, such as "v3.8.13". The former only provides "v3.8". o You need a clone of FreeBSD. You can fork this repository: https://github.com/freebsd/freebsd-base-graphics I recommend you add this one as a second remote (in addition to your fork), as well as the FreeBSD official Git mirror: https://github.com/freebsd/freebsd.git =3D=3D Source code locations =3D=3D In Linux, DRM is located in three places: drivers/gpu/drm include/drm include/uapi/drm In FreeBSD, DRM is located in sys/dev/drm2, with the Makefiles in sys/modules/drm2. =3D=3D Targets =3D=3D During the discussion, some wanted to work on Linux 3.9, some on Linux 4.3/4.4. That said, I believe we should start by moving to linuxkpi before anything. It would consist of modifying DRM to use sys/compat/linuxkpi instead of its own drm_os_freebsd.[ch] files. This would help a *lot* next updates. =3D=3D Workflow =3D=3D The workflow was discussed in previous threads: https://lists.freebsd.org/pipermail/freebsd-x11/2015-December/017056.html= The conslusion is here: https://lists.freebsd.org/pipermail/freebsd-x11/2016-January/017109.html The file-by-file workflow, which was more popular in the discussion, was explained in the link above. As for the branches, we are going to use drm-next-$target (eg. drm-next-3.9). Please send pull requests to these branches. At least in freebsd-base-graphics, "master" will remain the same code as Subversion's HEAD so we have a point of comparison. Let's take drm-next-3.9 as an example. We want to update the entire DRM to Linux 3.9: DRM core (the device-independent code), the i915 driver and the Radeon driver. As we are testing the file-by-file approach, we need to coordinate who does what. And before the task is finished, the kernel won't compile (that's the risk with the file-by-file approach). I would like to record all the contributors on the wiki or on GitHub, I'm not sure yet. Maybe it should take the form of issues on GitHub (ie. one issue per file to update and an assignee). The issue even let us discuss specific details about the file. DRM core should be updated first, then the drivers. =3D=3D How to build =3D=3D I usually build a full kernel with "make buildkernel". Then, I can rebuild the DRM part with: make buildkernel -DKERNFAST DEBUG_FLAGS=3D"-g -O0" Add -j$N to accelerate the build. You can't use "-O0" for the entire kernel otherwise the kernel will overflow the stack. However, use it for subsequent rebuilds (ie. when using -DKERNFAST), otherwise, you'll get a lot of "" variables in gdb. When working on the update of a single file, you should move that file to the top of $(SRCS) in the Makefile (eg. sys/modules/drm2/drm2/Makefile) so other files don't prevent you from build-testing your work. I (re)install the new kernel in /tmp, because I use tmpfs there (I don't care about the installed kernel on my working computer): make (re)installkernel DESTDIR=3D/tmp =46rom the test computer, I rsync the new kernel. =3D=3D How to test =3D=3D Do not load the driver from /boot/loader.conf or /etc/rc.conf. Load it manually after boot. You can set drm.debug=3D7 in /boot/loader.conf to have more debug informations during kldload. To lower the log level afterward (in case it's too verbose), the corresponding sysctl is hw.dri.debug. Play with several applications and use cases. I use: o glxinfo/glxgears o clinfo o Some of the games listed in the following page: https://dri.freedesktop.org/wiki/Benchmarking/ (OpenArena and Xonotic in my case) o WebGL, I use this demo: http://www.david.li/waves/ o Desktop environments (GNOME 3, KDE 4) and compositors such as compton. I use compton to have a tearfree environment: compton -CG --backend glx -b o Some video players with the GL and XVideo backends. o HTML5 videos. I watched this video which is exposes tearing a lot: https://www.youtube.com/watch?v=3DhpHknKaq_M0 o Stellarium o xrandr(1) to manage output connectors o Suspend/resume o Piglit (from our development Ports tree; we should definitely commit it) If you find a problem, try to reduce it to the minimum, then: 1. From a remote computer, use tmux or screen for your session (not mandatory, but quite handy) 2. From one tab, start a plain X server: Xorg 3. From another tab, start the bad, bad program: DISPLAY=3D:0 bad_application 4. Use other tabs to look at log files, run dtrace scripts, etc. By doing so, you limit the number of calls to the video drivers to the minmum. Running a full desktop environment will spam a lot of unrelated messages. If the computer doesn't crash and you want to load a newer driver, you ca= n: 1. Close all applications and the X server 2. kldunload the driver (note that it doesn't work for i915kms in HEAD, the update will fix that) 3. kldload the new one. It saves you a reboot. Again, do this from a remote computer because after kldunloading, you may not get a console back (it works with the Radeon driver, but so far, not with the updated i915 driver). If you get a core dump, it will be available in /var/crash after the reboot. Usually, core.txt.$N has enough informations. If not, you can start gdb (either the one in base or the one from Ports): gdb /boot/kernel/kernel /var/crash/vmcore.last (change /boot/kernel/kernel to match the kernel you used) Thanks for reading! :) If something is missing, please ask! I will put this information on the wiki. --=20 Jean-S=C3=A9bastien P=C3=A9dron --hwamfGoVR3h4Vk2I9sfFUp6NFtclI2sUC 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 iQJ8BAEBCgBmBQJWxwjpXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2NzA4N0ZEMUFFQUUwRTEyREJDNkE2RjAz OUU5OTc2MUE1RkQ5NENDAAoJEDnpl2Gl/ZTM57wP/3Hj0sXI0O+tl92gH972FLOG qowdreHH9KTVZvWUpiTvxGnPIXy/qZdRD1sTJPMxg7OB/PjJQF+nZZMFl1w0ICmg bbiTezodNxpnCK4CwOe4InCbz8+reEEB29cjIgNhQi1ioBd4kmeIypZAG6zFWf/4 9tpHk0q2hMfc2Dnnn2lD7hwRXlMu0CIycyU4SMPaAtFJ/rXtM19nAbQnlC45Ewp3 YgKfJLo7+dhLtVJ6Bg8t8QQRFbx2n7V4gaCg1+rbdEpp/l6nX53RoG8pIXZ64XvY 9W4D2SC2sInmmbiV7wpUKegcRgUd0UBUOX53SSE72ItMwg4yBhiXkJ7zl5Dr63rv miewPh7KsPNrqbkzNl/6LH2oApz8Qv6jdSpTN+gMhFraoVeH/Jh+HjHTY2XqgUkR d7Vdy/vkyPIIsFw3gsx3EKDhY+X1VGt5f48JrLTfTSa38H8M7c8kXavLuCIyBMSg Wr+vx5Ie9hm7ldUtrT2Awh4WoOz0T9KqfCENce4h7htP/80h3Da+DJyTM7S9CMzp DKbybL1QTYYZDmCixk4mtIklWMa38IwJkzNXpJdeBjKkFAwN/wJqiJYkmsZ5t77L 4zUwOUVJ9hQgWeqQmb/h2YG1uvVHpb2bwtYfD725VMdXTX05BNFqpFkM28X9uKLx PbrT0m6a8wqcBKHCBdAB =AYbq -----END PGP SIGNATURE----- --hwamfGoVR3h4Vk2I9sfFUp6NFtclI2sUC--