linux evdev input support in qemu 2.6

Another nice goodie coming in the qemu 2.6 release is support for linux evdev devices. qemu can pick up input events directly from the devices now, which is quite useful in case you don’t use gtk/sdl/vnc/spice for display output. Most common use case for this is vga pass-through. It’s used this way:

qemu -object input-linux,id=$name,evdev=/dev/input/event$nr

Note that udev creates symlinks with static names in /dev/input/by-id and /dev/input/by-path which you might find more convinient to use. It is possible to pass through multiple devices (i.e. mouse and keyboard).

Hitting both control keys at the same time will acquire and release the keyboard grab, i.e. it’ll switch the keyboard between guest and host. With the grab_all option enabled the keyboard hotkeys will toggle the grab for all other input devices too, so you can switch keyboard and mouse together. For the ps/2 devices on my thinkpad the command line for that looks like this:

qemu -object input-linux,id=kbd,evdev=/dev/input/by-path/platform-i8042-serio-0-event-kbd,grab_all=true
-object input-linux,id=mouse,evdev=/dev/input/by-path/platform-i8042-serio-2-event-mouse

Note: On my laptop platform-i8042-serio-1-event-mouse is the touchpad which can’t be used.

When using this with usb devices take care that they often have multiple functions, and each of them gets its own input device. The usb nano receiver for my wireless microsoft mouse has three event devices (probably because they use the same thing for all devices not only the mouse):

nilsson root ~# ls /dev/input/by-id/


Fedora on Raspberry PI updates

Some updates for the Running Fedora on the Raspberry PI 2 article.

There has been great progress on getting the Raspberry PI changes merged upstream in the last half year. u-boot has decent support meanwhile for the whole family, including 64bit support for the Raspberry PI 3. Raspberry PI 2 support has been merged upstream during the 4.6 merge window. It looks like Raspberry PI 3 will follow in the next (4.7) merge window. Time to have a closer look at all this new stuff.

arm images

There are two different kinds of arm images now:

First arm-rpi2-f23-foundation. They are using a kernel built from the tree maintained by the Raspberry PI Foundation at github. They are like the older ones, just with newer packages. The kernels are booted directly by the firmware.

Second arm-rpi2-f23-mainline. They are using a mainline kernel, with a few patches on top for Raspberry PI 3 support (device tree, 64bit, wifi). I expect the number of patches will decreate quickly as things get merged mainline with the next merge windows. The kernel is booted using u-boot. On the Raspberry PI 3 it’ll boot a 64bit kernel (with 32bit userspace) by default. If you don’t want that you can just run “dnf remove uboot-rpi3-64“, which will remove both 64bit uboot and kernel, then reboot.

There are no big differences between the two images types. At the end of the day it is just a different set of packages. You can move from foundation kernels (package name “kernel-rpi2” to mainline kernels (package names “kernel-main” and “kernel-main64“) and back without problems. Having them installed in parallel works fine too. The foundation kernels set kernel= in config.txt in postinstall, so one just needs to install and reboot. Switching to mainline is done by installing them, then commenting out the kernel= line in config.txt. Next boot will load uboot then, which in turn loads the mainline kernel.

arm64 images

While looking at the image directory you might have noticed the arm64-rpi3-f23-mainline image. That is a full 64bit (aka aarch64) build, with both 64bit kernel and userspace. Will boot on the Raspberry PI 3 only, for obvious reasons.


There is progress with kvm too. Recent firmware loads the kernel in hyp mode, so the hypervisor extensions are available to the linux kernel. Also it seems the kvm core and irqchip (GIC) emulation are separated now. kvm initializes successfully, but the kernel doesn’t provide irqchip because the Raspberry PI hasn’t a GIC. Result is this:

[kraxel@pi-dpy ~]$ sudo lkvm run
# lkvm run -k /boot/vmlinuz-4.5.1-103-rpi2 -m 448 -c 4 --name guest-10565
Error: Unsupported KVM extension detected: KVM_CAP_IRQCHIP
Fatal: Failed to create virtual GIC

So, userspace can’t deal with the missing GIC emulation (qemu fails too). But it looks like by doing GIC emulation in userspace it should be possible to run kvm on the Raspberry PI.

latest updates from virtio-gpu department

It’s been a while since the last virtio-cpu status report. qemu 2.6 release is just around the corner, time for a writeup about what is coming.

virgl support was added to qemu 2.5 already. It was supported only by the SDL2 and gtk UIs. Which is a nice start, but has the drawback that qemu needs direct access to your display. You can’t logout from your desktop session without also killing the virtual machine.

qemu 2.6 features headless opengl support and spice integration. qemu will use render nodes, render the guest display into dma-bufs, and pass on those dma-bufs to spice-client for display (if connected). Works for local display only for now, i.e. spice will simply display the dma-bufs. Long-term plan (after the spice video support overhaul currently in progress is merged) is to also support hardware-assisted video encoding for a remote display.

If you want play with this you need:

  • latest spice-gtk version (0.31)
  • latest spice-server development release (0.13.1)
  • virglrenderer (packages should start showing up in distros now).

If you are running fedora or rhel7 you can use my copr repo.
And of course you need latest qemu (2.6 release candidate or final release once out) too.

OpenGL support is off by default in qemu, you have to enable it manually by appending gl=on to the -spice options. libvirt 1.3.0 and newer has support for that in the domain xml. The spice client must be attached (virt-viewer –attach) using unix sockets because they are used to pass the dma-bug file descriptors.

Have fun!

fbida 2.11 released

New fbida release is out.

Needed something lightweight for drm testing. So I’ve decided to give the fbi display code a overhaul:

  • Untangled the console switching code from the fbdev code.
  • Added support for drm, which also is the new default.
  • Missing console switching support is not a fatal error any more.

The last item implies that you can start fbi from a remote login just fine now. When running on drm this actually works pretty well, fbi will simply allocate a new framebuffer and link it to the output, so things are nicely separated. When running on fbdev framebuffer access coordination goes away without console switching, so fbi and other users can draw at the same time. So if you find a friendly blinking fbcon cursor in the middle if your image, this is the reason for it.

Download the bits here.

virtio-gpu and libvirt

libvirt has no support for virtio-vga yet. There is a bug for virtio-vga support in libvirt. But for the time being we need to play some tricks. Luckily libvirt has some special xml syntax to pass command line options to qemu. So here we go:

<domain type='kvm' xmlns:qemu=''>
  [ ... ]
    [ ... ]
      <model type='cirrus' vram='16384' heads='1'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
    [ ... ]
    <qemu:arg value='-set'/>
    <qemu:arg value='device.video0.driver=virtio-vga'/>

The idea is to tell libvirt we wanna have a cirrus vga. That one has no config options, thats why it works best for our purposes. Then use the -set switch to change the emulation driver from cirrus to virtio-vga. video0 is the id libvirt assigns to the (first and only) video device.

Next level is turning on virgl & opengl support. Initially sdl and gtk user interfaces will be supported (qemu 2.5 most likely). Spice will follow later. So lets pick gtk. Here we go:

<domain type='kvm' xmlns:qemu=''>
  [ ... ]
    [ ... ]
    <graphics type='sdl' display=':0' xauth='/path/to/.Xauthority'/>
      <model type='cirrus' vram='16384' heads='1'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
    [ ... ]
    <qemu:arg value='-set'/>
    <qemu:arg value='device.video0.driver=virtio-vga'/>
    <qemu:arg value='-display'/>
    <qemu:arg value='gtk,gl=on'/>

Simliar approach: We ask libvirt for sdl support. Picking that one because libvirt will take care to pass xauth info to qemu so it gets access to the X11 display. Then use the -display switch to override the libvirt display configuration with gtk, and turn on opengl.

One final remark: On modern linux systems xauth info is stored in /run/gdm/auth-for-$USER-$RANDOM/database instead of $HOME/.Xauthority. I have a little script to copy the xauth info to a fixed place and also make it readable so libvirt can access it:

if test "$XAUTHORITY" != "$HOME/.Xauthority"; then
    xauth extract "$HOME/.Xauthority" "$DISPLAY"
    chmod +r $HOME/.Xauthority

Note that making .Xauthority world-readable effectively gives every user on your machine access to your X11 display. On your private laptop where you are the only user that should be ok, but on a shared machine you probably want do something more secure instead.

Running Fedora on the Raspberry PI 2

The new Raspberry PI B 2 model got an armv7 core (the older ones are armv6), which makes it much easier to run Fedora on it. All Fedora packages are built for armv7, so they work as-is. Only things needed additionally are (a) the firmware and (b) a kernel. So I’ve packaged up the stuff. Firmware is just the binary stuff canned into rpms. Kernel is build from rapsberrypi git repo.

Package repository is here:
Images are here:

Install & usage

Just unpack the image and write it to a memory card. On first boot a rc.local script configures some things, then reboots the pi. root password is “pi”. Network is configured use dhcp on both eth0 and wlan0, using systemd-networkd. wireless needs configuration though, use wpa_passphrase "$ssid" "$psk" >> /etc/wpa_supplicant/wpa_supplicant.conf for that. kernel-rpi packages have a postinstall script updating /boot/config.txt, so kernel updates work as usual.


There is a uboot-rpi2 package as I’ve played around with u-boot. Didn’t found it that useful though. The firmware passes some command line args and a device tree to the kernel. With u-boot as boot loader inbetween that gets lost. So I’ve found myself facing problems by adding uboot to the mix, with no real advantages. Therefore the images don’t use u-boot. But you can install the rpm and play around with it if you want.


Didn’t came very far. Booting a kvm-enabled kernel in hyp mode isn’t that difficuilt. The more serve problem is that there is no GIC which kvm needs too. Someone hacked up vgic emulation to solve that issue. But the patches are old and unmaintained. They don’t rebase easily. And they also don’t solve the problem that the machine has problems accepting hardware interrupts in guest mode. Which can be worked around with isolcpus & taskset. But after all it doesn’t look like worth bothering …

New member in the virtio family: input devices.


If you have build a fresh 4.1-rc kernel you might have already noticed the new CONFIG_VIRTIO_INPUT config option. So, here is some background information on what this is and how to use it.

virtio-input basically sends linux evdev events over virtio. The device capability bits (available via ioctl for evdev) live in virtio device config space. The events themself are sent over virtio queues. They look exactly like evdev events, except that the struct fields are always in little endian byte order. So this allows the host to emulate pretty much any input device the linux kernel’s input layer is able to handle.

On the guest side the only thing you need is a kernel with CONFIG_VIRTIO_INPUT=m.

On the host side you need pretty recent qemu master branch. The first release with virtio-input support will be 2.4.

emulated devices

qemu has three virtual devices right now:

  • -device virtio-keyboard-pci : virtual keyboard, simliar to the ps/2 keyboard.
  • -device virtio-mouse-pci : virtual mouse, simliar to the ps/2 mouse.
  • -device virtio-tablet-pci : virtual tablet, simliar to usb-tablet, but without the usb overhead.

The tablet is probably the most useful one in practice. The pseries guys might be interested in the keyboard too as usb-keyboard replacement.

device pass-though

Not yet merged, but the patch should land upstream in time for the 2.4 release: There also is support for passing through host evdev devices to the guest:

-device virtio-input-host-pci,evdev=/dev/input/eventn

Take care: The guest gets exclusive access to the input device then. So better don’t try that with your one and only keyboard 😉

virtio-gpu on the way upstream

We are making progress, time for the next status report …

virtio-gpu, 2d mode

It’s on the way upstream, both guest and host side. The qemu code landed in git master already and will be shipped with the upcoming 2.4 release. The linux kms driver is in drm-next right now and will most likely land upstream in the 4.2 merge window.

virtio-gpu, 3d mode

With 2d mode being almost completed now the focus shifts to put 3d/virgl into shape.

The qemu code is in a new virgl branch now, the vga and ui bits are no longer separated.

Current state: SDL2 display is working. egl display (headless, see below) is working.

TODO list: Make gtk diplay (egl mode) work. Add support for native opengl (available in 3.16+, needed to run on wayland) to gtk display. Add spice support.

Building qemu with virgl:
You need virglrenderer. Copr has packages. If you want try egl display too you need pretty cutting edge mesa and libepoxy packages, for dma-buf export and import support. Fedora 22 will do for mesa. For libepoxy you need the rawhide/F23 version.

Linux guest bits for virgl:
The virtio-gpu branch in my linux repo has the kernel bits you need. The Copr repos have a “mesa.git” package which you need to install. This isn’t full mesa, only the guest driver for virtio-gpu. I suggest to use Fedora 22 as guest as I’m usually testing with F22 too.

You might need to put selinux (at the host) into permissive mode when playing with this. svirt doesn’t allow qemu access the gpu.

headless egl display

In this mode qemu doesn’t need access to your X11 (or wayland) display. It’ll open a drm render node instead and use that for opengl operations. The guest display is rendered into a dma-buf. A simple standalone app can connect to qemu, get access to the dma-bufs via file descriptor passing and blit the dma-buf to your screen.

Start qemu: qemu-system-x86_64 -display egl -name $name
Start viewer: qemu-eglview $name

The viewer is proof-of-concept for the dma-buf passing and it is pretty simple. No pointer shape support. No relative pointer support, so a tablet device is mandatory for the guest if you want a working pointer.

Not sure yet how the long-term future will look like for qemu-eglview. Right now it is a useful hacking and testing tool. But spice will some day operate in a very simliar way and additionally provide all the extra goodies spice has to offer (sound, usb, smartcard, webdav, …), so it probably isn’t that useful to turn it into a full-blown viewer app …

virtio-gpu and virgl status update

Just received a email asking where we are in terms of virgl support in qemu, partly because the links from last years kvm talk are outdated meanwhile. I suspect there might be more folks wondering, so it is probably a good idea to write up an update in public. So, here we go with the news …

virglrenderer isn’t a branch in Dave’s mesa repo any more, it got factored out into its own git repo.

The mesa guest driver still is in Dave’s mesa repo (branch virgl-mesa-driver).

The xorg guest driver is not needed any more because xorg can do 2d acceleration via opengl/mesa now.

The guest kernel driver is in my virtio-gpu branch.

The qemu bits are splitted over two branches at the moment: The sdl2 and opengl bits are in my sdl branch, whereas the virtio-gpu bits are in the vga branch. In theory making things work should be as easy as merging these two branches. I didn’t test this for a while though as I’m busy bringing the first batch of virtio-gpu patches (with 2d support only) into shape for upstream merging.

Upstream merge is stalled atm because the virtio-gpu patches depend on virtio 1.0 support, which in turn is blocked by qemu being in freeze for the 2.3 release right now. Things should start moving forward very soon though, once qemu 2.3 is released the master branch will be opened for 2.4 development.