Hello again!
I’m moving. I mean, I’m moving to another subsystem. As a new step in my journey to develop Linux development skills, I will start contributing to DRM. To start this process, I asked Siqueira for advice about the first steps. We are now geographically distant, me in Portugal and he in Canada, so sometimes it is not very simple to match time to stablish some conversation since we are five hours apart and he is working full-time.
Since the USP time, Siqueira is always a guy willing to learn, teach and also pass on knowledge. This knowledge transfer works even unilaterally since I don’t have much skills to contribute more. But if I become technically good at developing for the kernel, maybe in the future I can bounce ideas off him. :)
Well, he told me that the first step is setting up my environment to start contributing. Yes, I know… setting up the environment to start work and checking that your current environment is working well is clearly the first step. As I already sent some contributions to IIO, I already had some things ready:
- A virtual machine working well and sharing a folder with the host.
- Knowledge of the commands to compile and install the kernel on the VM. I also had kworkflow working. Kworkflow is a set of scripts that makes life easier for the kernel developer, abstracting several commands that we need to use in day-to-day development activities. It was originally created by Siqueira. Some FLUSP members also have contributed and improved the code.
- neomutt installed and working fine (as well as knowledge on how to format and send a patch using neomutt). You can also use git, as shown here: https://flusp.ime.usp.br/git/2019/02/15/sending-patches-by-email-with-git/
However, as I was going to work with vkms, I also needed some new knowledge:
- Install a kernel version based on drm-misc: https://anongit.freedesktop.org/git/drm/drm-misc.git
- Compile the IGT: https://gitlab.freedesktop.org/drm/igt-gpu-tools
- Install VKMS on the VM
- Run kms_flip inside the VM and using VKMS
Stage 1 was smooth since it was basically doing what I had already done in IIO, but now using another kernel tree.
Compiling IGT
First of all, as I use VM to develop, I have to clone the IGT repository (https://gitlab.freedesktop.org/drm/igt-gpu-tools) into the folder shared with my virtual machine. That done, I need to check if all the packages listed in the Dockerfile.build-debian file are installed … So I installed the packages and did the compilation as it is in README.md. I went to the next step (installing VKMS and running the kms_flip test) and .. oops, we have a problem!
My host uses the Debian distro, but my VM uses Arch. It makes no sense to compile IGT on the host since the kernel I am going to test and work will be installed on the VM! I have to run commands to build and test inside my VM with the DRM kernel installed. Therefore, the right way is that my VM has all the necessary packages installed … OK! But … where’s the list of packages for Arch? I only see Fedora and Debian.
Well, I could check, for each necessary package on the list, its name on Arch (and hope that everyone is there). For future works, a shortcut is this packages list:
List of packages:
arch:
gcc flex bison pkg-config libpciaccess kmod procps-ng libunwind
libdwarf zlib xz cairo pixman libudev0-shim gsl alsa-lib xmlrpc-c
json-c curl libxrandr libxv xorgproto python-docutils valgrind peg
meson libdrm libtool make autoconf automake gtk-doc python-docutils
git vim sudo
debian:
flex bison pkg-config x11proto-dri2-dev python-docutils valgrind peg
libpciaccess-dev libkmod-dev libprocps-dev libunwind-dev libdw-dev
zlib1g-dev liblzma-dev libcairo-dev libpixman-1-dev libudev-dev
libgsl-dev libasound2-dev libjson-c-dev libcurl4-openssl-dev
libxrandr-dev libxv-dev meson libdrm-dev qemu-user qemu-user-static
liboping-dev gtk-doc-tools
So I was able to continue on with my VM and Arch. I ran the VM, went into the shared folder, then into the IGT folder and did the compilation and selftests. All right! Now, let’s go to the next step.
Install VKMS
You need to enable VKMS in the kernel configuration, using nconfig (please). But where is the VKMS there? I always get lost in that configuration file.
- Run
make nconfig - Go to
Device Drivers> Graphics Support - Enable
Virtual KMS (EXPERIMENTAL)
Now, compile and install the module and I do it easily with kworkflow (with the kw bi command) !!
Don’t forget to load the vkms module: sudo modprobe vkms
And check if vkms appears here: lsmod | grep drm
Finally, let’s test now if everything is really right.
Run kms_flip test in VM with VKMS
Having the kernel with VKMS enabled, the VM working with the packages and the IGT compiled, it’s time to run the kms_flip tests!
To test, you just need to run
build/tests/kms_flip
To perform a more specific subtest, you need to use the --run-subtest option.
build/tests/kms_flip --run-subtest basic-plain-flip
You will see that the test will start printing several dots on the command line (…….) and little by little the subtests performed will have its result displayed. This takes a while. At first, I even thought I had done something wrong and it would never stop showing dots. Then, with a little more patience, I realized that there was life beyond the dots and I waited for all tests passing.
It can happen that you are not running the kms_flip test specifically on top of the vkms.
When I was reading a blog post by a developer called Haneen (http://haneensa.github.io/2018/07/29/drmdebug/), I saw that she talked about the --force-module feature” that has been added recently by Rodrigo Siqueria to enable the IGT to choose a specific module to run the tests on it “.
With this functionality (https://patchwork.kernel.org/patch/10512983/) is possible to ensure that we are running kms_flip on vkms “–force-module vkms”.
But when I tried to reproduce, the parameter was not recognized.
So, I asked Siqueira about it and he told me that in the upstream implementation this parameter is declared in another way.
sudo IGT_FORCE_DRIVER=vkms ./tests/kms_flip --run-subtest basic-plain-flip
If you are using QEMU, you can also ensure the use of vkms disabling on .config the option : Device Drivers> Graphics Support > DRM Support for bochs dispi vga interface (qemu stdvga)
Hey, I think I’ve finished these preparation steps! However, for work portability between the VM and the Host, I need to redo this VM setup to use Debian (as my computer is Debian). Ok, good for memorization.