kenoi

Karton Virtual Machine Manager Blog #4: Hardware Accelerating the SPICE viewer (with OpenGL)

Mon, 15 Sep 2025 00:00:00 +0000

I was at Akademy 2025 last-last week where I did some preliminary research on optimizing the VM viewer’s display rendering on Karton. After some more work this past week, it’s somewhat here! I’m still finishing up the merge request, but exciting news to come!

This has been something I’ve been planning on for quite a while now and will significantly improve the experience using Karton :)

Your browser does not support the video tag.

a comparison with an old video I had.

Old Rendering Pipeline

My original approach for rendering listened to display-primary-create and invalidate-display-primary SPICE signals. Everytime it received a callback, it would create a new QImage and render that to the QQuickItem (the viewer window). As you can imagine, this was very inefficient as it is basically generating new images for every single frame being rendered. It suffered a lot from screen-tearing any time there were sudden changes to the screen.

You can read more about my experiences in my SPICE client blog.

We can do better!

Rendering via OpenGL can offload a lot of these tasks to the GPU and can significantly improve performance. I had known about GL properties in SPICE for a while now, but I kept putting it off since I really didn’t want to deal with any more graphics stuff after my last attempt.

Fast forward to last-last week, I was attending my first ever KDE Akademy in Berlin and all of a sudden gained some motivation.

It was really exciting hearing talks about all the kool things happening in KDE.

gl-draw

My first order of business was getting the gl-draw signal to properly receive gl-scanouts from my SPICE connection. After setting up the callback, I found out that I had to reconfigure my VMs to properly support it.

This was easy enough as I’ve made the Karton VM installation classes a few months ago done through the libvirt domain XML format. VMs need enabling of GL and 3D acceleration through the graphics element in the XML. The socket connection to SPICE also had to be switched from TCP to UNIX, which was set to /tmp/spice-vm{uuid}.sock. As a result, previous VMs configured in Karton will no longer work as the previous rendering pipeline has been removed.

<graphics type="spice" socket="/tmp/spice-vm{uuid}.sock">
    <listen type="socket" socket="/tmp/spice-vm{uuid}.sock"/>
    <gl enable="yes"/>
</graphics>
<video>
    <model type="virtio" heads="1" primary="yes">
        <acceleration accel3d="yes"/>
    </model>
    <address type="pci" domain="0x0000" bus="0x00" slot="0x01" function="0x0"/>
</video>

An example libvirt domain XML snippet generated by Karton

Once properly configured, I was able to get SpiceGlScanout objects from my callback linked to the gl-draw signal. Now, I needed to render these scanouts onto my QQuickItem canvas.

EGL stuff

Having no background in graphics, I pretty much had no idea what I was doing by this point.

The SpiceGlScanout is a struct that looks like this:

struct SpiceGlScanout {
    gint fd;
    guint32 width;
    guint32 height;
    guint32 stride;
    guint32 format;
    gboolean y0top;
};

The width, height, stride, etc…, are all parameters that can be used to set your final rendered frame, but the important field is the fd (file descriptor) which is a “a drm DMABUF file that can be imported with eglCreateImageKHR”. I didn’t know what that was; but at least I learned I should be using the EGL library to do the processing.

I had found some forum articles (Qt forum, Arm developer forum) related to rendering OpenGL textures which used the EGL library and were quite helpful. I also looked at the SPICE GTK widget source code which gave me some ideas on the GL parameters to work with.

From these references, I saw that they pretty much followed the same pattern. Very simply put:

-> create egl image from a bunch of attributes/settings
-> generate texture from the fd 
-> bind texture to a texture type 
-> "glEGLImageTargetTexture2DOES" use this function?? still don't know what this does lol
-> destroy egl image

I originally tried setting the GL context properties manually, but there were some issues with getting it to detect my display and apparently thread syncronization. Then, I found out that Qt had a QOpenGLFunctions library which had all of the EGL functions and context properties wrapped and made my life a whole bunch easier.

OpenGL texture -> Qt

After a ton of trial and error, it looked like my EGL images were properly being created. Now I needed to render these GL textures to the QQuickItem.

How you do so is, within the inherited updatePaintNode() function, you return a QSGNode which has the information for updating that frame. Looking through the Qt documentation, QNativeTexture is a struct that allows you to store a texture ID to an OpenGL image. With that, you can create a wrapper QRhi class from the QNativeTexture with some of the generic context of your display.

Finally, you can use the createTextureFromRhiTexture() function under QQuickWindow which allows you to create a QSGTexture from that RHI for a QSGNode that can be returned by updatePaintNode(). And, we’re done! Yay!

To sum it up, here’s the framebuffer pipeline:

gl-draw signal->receive gl-scanout->import GL texture->GL texture ID->QNativeTexture->QRhi->QSGTexture->QSGNode->QQuickItem

Your browser does not support the video tag.

so much smoother! yes, I was very excited.

Socials

Website: https://kenoi.dev/

Mastodon: https://mastodon.social/@kenoi

GitLab: https://invent.kde.org/kenoi

GitHub: https://github.com/kenoi1

Matrix: @kenoi:matrix.org

Discord: kenyoy

GSoC 2025 Final Project Blog: Developing Karton, the KDE Virtual Machine Manager!

Thu, 28 Aug 2025 00:00:00 +0000

Hello again everyone!

I’m Derek Lin also known as kenoi, a second-year Math student at the University of Waterloo.

Through Google Summer of Code 2025 (GSoC), mentored by Harald Sitter, Tobias Fella, and Nicolas Fella, I have been developing Karton, a virtual machine manager for KDE.

As the program wraps up, I thought it would be a good idea to put together what I’ve been able to accomplish as well as my plans going forward.

A final look at Karton after the GSoC period.

Research and Initial Work

The main motivation behind Karton is to provide KDE users with a more Qt-native alternative to GTK-based virtual machine managers, as well as an easy-to-use experience.

I had first expressed interest in working on Karton in early Feburary where I made the initial full rewrite (see MR #4), using libvirt and a new UI, wrapping virt-install and virt-viewer CLIs. During this time, I had been doing research, writing a proposal, and trying out different virtual machine managers like GNOME Boxes, virtmanager, and UTM.

You can read more about it in my project introduction blog!

A screenshot of my rewrite in March 8, 2025.

VM Installation

One of my goals for the project was to develop a custom libvirt domain XML generator using Qt libraries and the libosinfo GLib API. I started working on the feature in advance in April and was able to have it ready for review before the official GSoC coding period.

I created a dialogue menu to accept a VM name, installation media, storage, allocated RAM, and CPUs. libosinfo will attempt to identify the ISO file and return a OS short-ID (ex: fedora40, ubuntu24.04, etc), otherwise users will need to select one from the displayed list.

Through the OS ID, libosinfo can provide certain specifications needed in the libvirt domain XML. Karton then fills in the rest, generating a UUID, a MAC address to configure a virtual network, and sets up display, audio, and storage devices. The XML file is assembled through QDomDocument and passed into a libvirt call that verifies it before adding the VM.

VM information (id, name, state, paths, etc) in Karton is parsed explicitly from the saved libvirt XML file found in the libvirt QEMU folder, ~/.config/libvirt/qemu/{domain_name}.xml.

All in all, this addition (see MR #8) completely removed the virt-install dependency although barebones.

A screenshot of the VM installation dialog.

The easy VM installation process of GNOME Boxes had been an inspiration for me and I’d like to improve it in the future by adding a media installer and better error handling later on.

Official Coding Begins!

A few weeks into the official coding period, I had been addressing feedback and polishing my VM installer merge request. This introduced much cleaner class interface separation in regards to storing individual VM data.

SPICE Client and Viewer

My use of virt-viewer previously for interacting with virtual machines was meant as a temporary addition, as it is a separate application and is poorly integrated into Qt/Kirigami and lacks needed customizability.

Previously, clicking the view button would open a virtviewer window.

As such, the bulk of my time was spent working with SPICE directly, using the spice-client-glib library, in order to create a custom Qt SPICE client and viewer (see MR #15). This needed to manage the state of connection to VM displays and render them to KDE (Kirigami) windows. Other features such as input forwarding, audio receiving also needed to be implemented.

I had configured all Karton-created VMs to be set to autoport for graphics which dynamically assigns a port at runtime. Consequently, I needed to use a CLI tool, virsh domdisplay, to fetch the SPICE URI to establish the initial connection.

The viewer display works through a frame buffer. The approach I took was rendering the pixel array I received to a QImage which could be drawn onto a QQuickItem to be displayed on the window. To know when to update, it listens to the SPICE primary display callback.

You can read more about it in my Qt SPICE client blog. As noted, this approach is quite inefficient as it needs to create a new QImage for every frame. I plan on improving this in the future.

Screenshots of my struggles getting the display to work properly.

I had to manage receiving and forwarding Qt input. Sending QMouseEvents, mouse button clicks, were straightforward and can be mapped directly to SPICE protocol mouse messages when activated. Keystrokes are taken in as QKeyEvents and the received scancodes, in evdev, are converted to PC XT for SPICE through a map generated by QEMU. Implementing scroll and drag followed similarly.

I also needed manage receiving audio streams from the SPICE playback callback, writing to a QAudioSink. One thing I found nice is how my approach supported multiple SPICE connections quite nicely. For example, opening multiple VMs will create separate audio sources for each so users can modify volume levels accordingly.

Later on, I added display frame resizing when the user resizes the Karton window as well as a fullscreen button. I noticed that doing so still causes resolution to appear quite bad, so proper resizing done through the guest machine will have to be implemented in the future.

Your browser does not support the video tag.

Now, we can watch Pepper and Carrot somewhat! (no hardware accelleration yet)

UI

My final major MR was to rework my UI to make better use of screen space (see MR #25). I moved the existing VM ListView into a sidebar displaying only name, state, and OS ID. The right side would then have the detailed information of the selected VM. One my inspirations was MacOS UTM’s screenshot of the last active frame.

When a user closes the Karton viewer window, the last frame is saved to $HOME/.local/state/KDE/Karton/previews. Implementing cool features like these are much easier now that we have our own viewer! I also added some effects for opacity and hover animation to make it look nice.

Finally, I worked on media disc ejection (see MR #26). This uses a libvirt call to simulate the installation media being removed from the VM, so users can boot into their virtual hard drive after installing.

Demo Usage

As a final test of the project, I decided to create, configure and use a Fedora KDE VM using Karton. After setting specifications, I installed it to the virtual disk, ejected the installation media, and properly booted into it. Then, I tried playing some games. Overall, it worked pretty well!

Your browser does not support the video tag.

List of MRs

Major Additions:

Subtle Additions:

Difficulties

My biggest regret was having a study term over this period. I had to really manage my time well, balancing studying, searching for job positions, and contributing. There was a week where I had 2 midterms, 2 interviews, and a final project, and I found myself pulling some late nighters writing code at the school library. Though it’s been an exhausting school term, I am still super glad to have been able to contribute to a really cool project and get something work!

I was also new to both C++ and Qt development. Funny enough, I had been taking, and struggling on, my first course in C++ while working on Karton. I also spent a lot of time reading documentation to familiarize myself with a lot of the different APIs (libspice, libvirt, and libosinfo).

Left: Karton freezes my computer because I had too many running VMs.

Right: 434.1 GiB of virtual disks; my reminder to implement disk management.

What’s Next?

There is still so much to do! Currently, I am on vacation and I will be attending Akademy in Berlin in September so I won’t be able to work much until then. In the fall, I will be finally off school for a 4 month internship (yay!!). I’m hoping I will have more time to contribute again.

There’s still a lot left especially with regards to the viewer.

Here’s a bit of an unorganized list:

Optimize VM display frame buffer with SPICE gl-scanout
Improved scaling and text rendering in viewer
File transfer and clipboard passthrough with SPICE
Full VM snapshotting through libvirt (full duplication)
Browse and installation tool for commonly installed ISOs through QEMU
Error handling in installation process
Configuration and allow modifying of existing VMs in the application
Others on the issue tracker

Release?

In its current state, Karton is not feature complete, and not ready for officially packaging and releasing. In addition to the missing features listed before, there have been a lot of new and moving parts throughout this coding period, and I’d like to have the chance to thoroughly test the code to prevent any major issues.

However, I do encourage you to try it out (at your own risk!) by cloning the repo. Let me know what you think and when you find any issues!

In other news, there are some discussions of packaging Karton as a Flatpak eventually and I will be requesting to add it to the KDE namespace in the coming months, so stay tuned!

Conclusion

Overall, it has been an amazing experience completing GSoC under KDE and I really recommend it for anyone who is looking to contribute to open-source. I’m quite satisfied with what I’ve been able to accomplish in this short period of time and hoping to continue to working and learning with the community.

Working through MRs has given me a lot of valuable and relevant industry experience going forward. A big thank you to my mentor, Harald Sitter, who has been reviewing and providing feedback along the way!

As mentioned earlier, Karton still definitely has a lot to work on and I plan continuing my work after GSoC as well. If you’d like to read more about my work on the project in the future, please check out my personal blog and the development matrix, karton:kde.org.

Thanks for reading!

Socials

Website: https://kenoi.dev/

Mastodon: https://mastodon.social/@kenoi

GitLab: https://invent.kde.org/kenoi

GitHub: https://github.com/kenoi1

Matrix: @kenoi:matrix.org

Discord: kenyoy

Karton Virtual Machine Manager GSoC 2025 Blog #2: Qt SPICE Client

Fri, 04 Jul 2025 00:00:00 +0000

After my initial status blog, I was really surprised to see so much support and excitement about Karton, and I’m grateful for it!

A few weeks have gone by since the official coding period for Google Summer of Code began. I wanted to share what I’ve been working on with the project!

VM Installer

Earlier last month, I was finishing up addressing feedback (big thanks again to Harald) on the VM installer-related MR. I had made some improvements to memory management, bug fixes related to detecting ISO disks, as well as refactoring of the class structures. I also ported it over to using QML modules, which is much more commonly used in KDE apps, instead of exposing objects at runtime.

After a bit more review, this has now been merged into the master branch! This was what was featured in the previous demo video and you can find a list of the full changes on the commit.

SPICE Client

Two weeks ago, I started to get back to work on my SPICE viewer branch. This is the main component I had planned for this summer.

It took a few days to clean up my code that connects to the SPICE display and inputs channel.

However, a lot of my time was spent trying to get a properly working frame buffer that grabs the VM display from SPICE (spice-client-glib) and renders it to a native KDE window. The approach I originally took was rendering the pixel array I received to a QImage which could be drawn onto a QQuickItem to be displayed on the window. It listens to SPICE callbacks to know when to update, and was pretty exciting to see it rendering for the first time!

One of the most confusing issues I encountered was when I was encountering weird colour and transparency artifacts in my rendering. I initially thought it was a problem due to the QImage 32-bit RGB format I was labelling the data as, so I ended up going through a bunch of formats on the Qt documentation. The results were very inconsistent and 24-bit formats were somehow looking better, despite SPICE giving me it in 32-bit. Turns out (unrelatedly), there was some race condition with how I was reading the array while SPICE was writing to it, so manually copying the pixels over to a separate array did the trick.

Here are nice pictures from my adventures!

my first time properly seeing the display… (also in the wrong format) ( •͈ ૦ •͈ )

I have also set up forwarding controls which listens to Qt user input (mouse clicks, hover, keyboard presses) and maps coordinates and events to SPICE messages in the inputs channel. Unfortunately, Qt key event scancodes seem to be in evdev format while SPICE expects PC XT. Currently, I have been manually mapping each scancode, but I might see if I can switch to use some library eventually.

Once I polish this up, I hoping to merge this into master soon. It’ll likely be very slow and barebones, but I’m hoping I can make more improvements later on!

Your browser does not support the video tag.

still very lagging scrolling, but now we can read Pepper & Carrot!

What’s Next?

While relatively simple, I noticed my approach is quite inefficient, as it has to convert every received frame to a QImage, and suffers from tearing when it has to update quickly (ex: scrolling, videos).

SPICE has a gl-scanout property which is likely much more optimized for rendering frames and I plan on looking into switching over to that in the long-term.

I also need to implement audio forwarding, sending proper mouse drag events, and resizing the viewing window.

On a side note, I also helped review a nice QoL feature from Vishal to list the OS variants in the installation dialog. I’ve just been memorizing them up until now… :')

Hopefully, once I get the SPICE viewer to a reasonable state, I can get back to improving the installation experience further like adding a page to download ISOs from.

As I mentioned a bit previously, I also want to rework the UI eventually. This means spending time to redevelop the components to include a sidebar, which is inspired by UTM and DistroShelf.

Lastly,

I also wanted to make a bit of a note on my plans and hopes throughout the GSoC period. After working on developing these different components of the app, I started to realize how much time goes into polishing, so I believe that I need to prioritse some of the most important features and making them work well.

Overall, it’s been super busy (since I’m also balancing school work), but it has been quite exciting!

Come join our matrix channel: karton:kde.org

Another thing, I recently made a personal website, kenoi.dev, where I also plan on blogging!

That’s all, thank you for reading :D

hi, I made a website :>

Fri, 27 Jun 2025 00:00:00 +0000

Hey! I’ve been wanting to make a personal website for a while now, and while I’m currently contributing to GSoC @ KDE, I thought it’d be nice to have somewhere to share my status also.

So, here it is! I hope I can find some time to write something once in a while!

Most my blogs will likely about the work I’m doing with ongoing projects, but I might write occasionally about travel, music, and maybe drawing!

Thanks for reading and have a nice day! :-D

GSoC 2025 Project Intro: Developing Karton, the KDE Virtual Machine Manager!

Sun, 18 May 2025 00:00:00 +0000

(This blog is originally posted to KDE Blogs.)

Hi everyone!

I’m Derek Lin, also known as kenoi. I’m a second-year student at the University of Waterloo and really excited to be working on developing Karton, a virtual machine manager, this summer. This project will be a part of the Google Summer of Code (GSoC) 2025 program and mentored by Harald Sitter, Tobias Fella, and Nicolas Fella. Over the past few months, I’ve been contributing to the project through some merge requests and I hope to get it to a somewhat polished state towards the end of the program!

About Karton Virtual Machine Manager

Currently, GTK-based virtual machine managers (virt-manager, GNOME Boxes) are the norm for a lot of KDE users, but they are generally not well integrated into the Plasma environment. Although there has been work done in the past with making a Qt-Widget-based virtual machine manager, it has not been maintained for many years and the UI is quite dated.

Karton, as originally started by Aaron Rainbolt was planned to be a QEMU frontend for virtualization through its CLI. Eventually, the project ownership was handed over to Harald Sitter and it was made available as a GSoC project. My aim is to make Karton a native Qt-Quick/Kirigami virtual machine manager, using a libvirt backend. Through libvirt, lower-level tasks can be abstracted and it allows for the app to be potentially cross-platform.

If anyone is interested, I wrote a bit more in detail in my GSoC project proposal (although a bit outdated).

My Work so Far

I originally became interested in the project back in February this year where I tested out GNOME Boxes, virt-manager, and UTM. I also experimented on the virsh CLI, configuring some virtual machines through the libvirt domain XML format.

My first merge request was a proof-of-concept rewrite of the app. I implemented new UI components to list, view, configure, and install libvirt-controlled virtual machines. This used the libvirt API to fetch information on user domains, and wrapped virt-install and virtviewer CLIs for installing and viewing domains respectively. I had spent a big portion of this time getting know Qt frameworks, libvirt, and just C++ overall, so a big thank you to Harald Sitter and Gleb Popov, who have been reviewing my code!

A few weeks later I also made a smaller merge request building off of my rewrite, adding QEMU virtual disk path management which is where the main repository stands as of now.

In between my school terms in mid-April, I had the amazing opportunity to attend the Plasma Sprint in Graz where I was able to meet many awesome developers who work on KDE. During this time, I worked on a merge request to implement a domain installer (in order to replace the virt-install command call). This used the libosinfo GLib API to detect a user-provided OS installer disk image, getting specifications needed for the libvirt XML domain format. Karton is then able to generate a custom XML file which will make it easier to work off of and implement more features in the future. I had to rework a lot of the domain configuration class structure and shifted away from fetching information from libvirt API calls to parsing it directly from XML.

A libvirt domain XML configuration generated by Karton.

A Video Demo

Your browser does not support the video tag.

Current Works in Progress

As virt-install is very powerful program, my installer is still hardcoded to work with QEMU and I haven’t been able to implement a lot of the device configuration yet. I also am currently working on addressing feedback on this merge request.

Recently, I also started work on a new custom Qt-Quick virtual machine viewer. It connects to virtual machines through the spice-client-glib library and renders the frames on a QQuickItem with the images it receives from the active virtual machine. This is still very buggy and has yet to support user input.

Your browser does not support the video tag.

a very cursed viewer…

Warning: Karton is still under development. I would not recommend running Karton with any VMs that are important as they may break.

My Plans for Google Summer of Code ‘25

Once the domain installer is finished up, I think the majority of my time will be spent on working on and polishing the virtual machine viewer.

Some of the other things I would want to get to during the summer are:

Support snapshotting, so users can save the state of their virtual machines.
Rework the UI so that it uses space more effectively, possible more similar to UTMs layout.
System monitor to graph CPU and RAM usage of VMs, similar to virt-manager.
Other configuration options for the installer to support device passthrough and such.
A bunch of more stuff mentioned in the project proposal!

If you have any features you’d like to see in the future, let us know in our Matrix, karton:kde.org!

That’s all!

Thanks for reading! I’m still new to KDE development and virtualization in general, so if you have any suggestions or thoughts on the project, please let me know!

Email: [email protected]">[email protected]

Matrix: @kenoi:matrix.org

Discord: kenyoy

I also made a Mastodon recently: mastodon.social/@kenoi

sketches

Wed, 01 Jan 2025 00:00:00 +0000

2024-05-24

2023-09-12

2022-09-22

2024-07-29

Mon, 29 Jul 2024 00:00:00 +0000

2022-07-20

Wed, 20 Jul 2022 00:00:00 +0000

2021-10-14

Thu, 14 Oct 2021 00:00:00 +0000

Digital Artwork

Mon, 01 Jan 1100 00:00:00 +0000

This is my latest digital artwork. I spent about 5 hours working on this piece. Experimenting with digital painting techniques in Photoshop. This portrait study focuses on light and shadow, using custom brushes and layer blending modes to achieve a painterly effect. Created over multiple sessions, refining details and color harmony throughout the process.