SDL support is missing while virglrenderer has problems with GTK

[Olivier Robert]

Disabling SDL support may have its reasons, but I guess that means I may be the only one using the virglrenderer library, because it has problems running with the GTK frontend.

I've been emulating an Android 9.0 device since Eoan, and it took me some time to understand Qemu's GTK frontend and virglrenderer were interacting badly. That may very well be a problem with virglrenderer, not Qemu, but still, using SDL is a good way around it.

Currently it doesn't change anything for me as I have to rebuild to insert a personal patch anyway, but I thought it may be worth mentioning, since people may experience problems with virglrenderer they don't know how to solve.

ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: qemu-system-x86 1:4.2-3ubuntu6.6
ProcVersionSignature: Ubuntu 5.4.0-47.51-generic 5.4.55
Uname: Linux 5.4.0-47-generic x86_64
ApportVersion: 2.20.11-0ubuntu27.8
Architecture: amd64
CasperMD5CheckResult: skip
CurrentDesktop: ubuntu:GNOME
Date: Fri Sep 18 15:30:22 2020
InstallationDate: Installed on 2019-09-22 (361 days ago)
InstallationMedia: Ubuntu 19.04 "Disco Dingo" - Release amd64 (20190416)
KvmCmdLine: COMMAND STAT EUID RUID PID PPID %CPU COMMAND
MachineType: Notebook P17SM-A
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-47-generic root=UUID=788f8a5e-9667-4cfb-abf4-bc76ebcb86bb ro quiet splash mtrr_spare_reg_nr=0 vt.handoff=7
SourcePackage: qemu
UpgradeStatus: Upgraded to focal on 2020-05-16 (124 days ago)
dmi.bios.date: 03/27/2014
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: 4.6.5
dmi.board.asset.tag: Tag 12345
dmi.board.name: P17SM-A
dmi.board.vendor: Notebook
dmi.board.version: Not Applicable
dmi.chassis.asset.tag: To Be Filled By O.E.M.
dmi.chassis.type: 3
dmi.chassis.vendor: To Be Filled By O.E.M.
dmi.chassis.version: To Be Filled By O.E.M.
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr4.6.5:bd03/27/2014:svnNotebook:pnP17SM-A:pvrNotApplicable:rvnNotebook:rnP17SM-A:rvrNotApplicable:cvnToBeFilledByO.E.M.:ct3:cvrToBeFilledByO.E.M.:
dmi.product.family: Not Applicable
dmi.product.name: P17SM-A
dmi.product.sku: Not Applicable
dmi.product.version: Not Applicable
dmi.sys.vendor: Notebook

[Christian Ehrhardt  (paelzer)]

Thanks Olivier for the report.
It is very unlikely that we'll be able or allowed [1] to enable SDL in Focal after the fact. But I'd be very interested which problems you are seeing, what the steps to recreate them are exactly and if you have reported (or found) upstream discussions about these.
Because even if we don't re-enable SDL I'd want to learn what we might need to improve it with GTK.

[1]: https://wiki.ubuntu.com/StableReleaseUpdates

[Olivier Robert (novhak)]

Hi Christian,

Fairly easy to reproduce. I just tried with current qemu (version 4.2.1 (Debian 1:4.2-3ubuntu6.6)).

You need to download the Android 9.0r2 ISO image from the Android-x86 project. Here's a link for the 64-bit image (I chose the non k49 one) :

https://www.fosshub.com/Android-x86.html?dwl=android-x86_64-9.0-r2.iso

Then boot the image in Qemu :
qemu-system-x86_64 -machine q35,vmport=off -cpu host -accel kvm -smp 2 -m 4G -audiodev pa,id=pasound,timer-period=5000 -device ES1370,audiodev=pasound -device virtio-vga,virgl=on -device virtio-mouse -device virtio-keyboard -drive file=android-x86_64-9.0-r2.iso,if=virtio,media=cdrom,format=raw,readonly=on -display gtk,gl=on -usb -nodefaults -monitor vc -nic user,hostfwd=tcp:127.0.0.1:5555-:5555

It shouldn't take long before the screen freezes. Here's the associated log entry :
----- LOG START -----
10-05 01:00:18.548 1147 1259 F libc : Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0xe8 in tid 1259 (frame-worker), pid 1147 (surfaceflinger)
10-05 01:00:18.565 4406 4406 F DEBUG : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
10-05 01:00:18.565 4406 4406 F DEBUG : Build fingerprint: 'Android-x86/android_x86_64/x86_64:9/PI/lh03251128:userdebug/test-keys'
10-05 01:00:18.565 4406 4406 F DEBUG : Revision: '0'
10-05 01:00:18.565 4406 4406 F DEBUG : ABI: 'x86_64'
10-05 01:00:18.565 4406 4406 F DEBUG : pid: 1147, tid: 1259, name: frame-worker >>> /system/bin/surfaceflinger <<<
10-05 01:00:18.565 4406 4406 F DEBUG : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0xe8
10-05 01:00:18.565 4406 4406 F DEBUG : Cause: null pointer dereference
10-05 01:00:18.565 4406 4406 F DEBUG : rax 0000000000000000 rbx 00007eb0cc0585b0 rcx 0000000000000000 rdx 00007eb0d2a9cc08
10-05 01:00:18.565 4406 4406 F DEBUG : r8 0000000000000000 r9 00000000ffffffff r10 0000000000000000 r11 0000000000000246
10-05 01:00:18.565 4406 4406 F DEBUG : r12 0000000000000001 r13 00007eb0d30d7050 r14 000000000000001e r15 00007eb0d30d7100
10-05 01:00:18.565 4406 4406 F DEBUG : rdi 0000000000000000 rsi fffffffffffffff0
10-05 01:00:18.565 4406 4406 F DEBUG : rbp 00007eb0ccf01400 rsp 00007eb0ccf01310 rip 00007eb0cd2892ac
10-05 01:00:18.566 4406 4406 F DEBUG :
10-05 01:00:18.566 4406 4406 F DEBUG : backtrace:
10-05 01:00:18.566 4406 4406 F DEBUG : #00 pc 00000000000202ac /system/vendor/lib64/hw/hwcomposer.drm.so (android::DrmDisplayCompositor::CommitFrame(android::DrmDisplayComposition*, bool)+668)
10-05 01:00:18.566 4406 4406 F DEBUG : #01 pc 000000000001e72b /system/vendor/lib64/hw/hwcomposer.drm.so (android::DrmDisplayCompositor::ApplyFrame(std::__1::unique_ptr<android::DrmDisplayComposition, std::__1::default_delete<android::DrmDisplayComposition>>, int)+27)
10-05 01:00:18.566 4406 4406 F DEBUG : #02 pc 000000000001e68e /system/vendor/lib64/hw/hwcomposer.drm.so (android::DrmDisplayCompositor::FrameWorker::Routine()+318)
10-05 01:00:18.566 4406 4406 F DEBUG : #03 pc 00000000000372e8 /system/vendor/lib64/hw/hwcomposer.drm.so (android::Worker::InternalRoutine()+72)
10-05 01:0...

[Paride Legovini (paride)]

Hello Olivier,

I'm running Groovy and was curious to try to reproduce this, but I'm getting 403 Forbidden errors when trying to download the Android ISO image from the link you provided. Will try again in the next days.

[Olivier Robert (novhak)]

Hi Paride,

Sorry about that, they probably block direct linking.

Try that link instead : https://www.fosshub.com/Android-x86.html

Then, choose the "Android-x86 64-bit ISO file", version "9.0-r2". If it still doesn't work, you could try the Android-x86 project web site : https://www.android-x86.org/

You can choose Download from there, and you will be presented with two options, download from Fosshub, or download from OSDN. I gave the Fosshub link.

[Christian Ehrhardt  (paelzer)]

Most of the links are still down, but after some trying I found a working one that is left on OSDN.
I'll give this a look, but UI is often terribly complex to track down, so no promises in advance :-)

FYI A bug worth to watch that might be related is bug 1898490

[Christian Ehrhardt  (paelzer)]

I got:
- Startup (bootloader) - ok
- Initial kernel messaged - ok, no errors
- Android load screen (shimmering android letters) - ok
- Config wizard - working and clickable
- ... clicking through the setup wizard a bit
=> Indeed it hangs after a while, but there is no message associated by qemu .

Initially (way before the hang) I got:
gl_version 46 - core profile enabled
vrend_renderer_fill_caps: Entering with stale GL error: 1280
GLSL feature level 430
virtio_input_hid_handle_status: unknown type 20
virtio_input_hid_handle_status: unknown type 20

But around the hang no message occurred, nor did anything segfault as on your report.
Did you collect that part of th elog/crash in a different place (file, console, ...(?

Re-running the same test hangs at various places, always the same way.

For the sake of excluding Android from the equation I'll try the same with an Ubuntu Desktop ...

[Christian Ehrhardt  (paelzer)]

I've tested on two systems
1. one comes with the usual defaults (no 3d), checked it to work fine as-is, then enabled virtiogpu+3d. I added this case as sometimes libvirt fixes up some rough edges, so it is useful to compare cases executed that way
2. a ubuntu live desktop installer booting into the live env, started the same way as shown for the Android ISO above

1a)
First it had in the guest the usual QXL/Spice setup with 3d just using llvmpipe

1b)
Setting it up for 3d
<graphics type="spice">
  <listen type="none"/>
  <image compression="off"/>
  <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>

Now I got "renderer string: virgl" in glxinfo and in dmesg "virtgl 3d acceleration enabled".

The related config isn't much different for virtio-vga, but obviously using spice instead of sdl/gtk:
-nodefaults
-device virtio-vga,id=video0,virgl=on,max_outputs=1,bus=pcie.0,addr=0x1 \
-spice port=0,disable-ticketing,image-compression=off,gl=on,rendernode=/dev/dri/renderD128,seamless-migration=on \

I must admit there is some graphic "noise" when connecting to this through spice.
Also I have a sound issue in the guest.
So it is far from perfect.
But neither can I see any of the crashes reported above.

... (more updates later) ...

[Christian Ehrhardt  (paelzer)]

2) The same image I used through lbivirt before
 $ sudo qemu-system-x86_64 -machine q35,vmport=off -cpu host -accel kvm -smp 2 -m 4G -audiodev pa,id=pasound,timer-period=5000 -device ES1370,audiodev=pasound -device virtio-vga,virgl=on -device virtio-mouse -device virtio-keyboard -drive file=/var/lib/libvirt/images/ubuntu20.04-Desktop.qcow2,if=virtio,format=qcow2 -display gtk,gl=on -usb -nodefaults -monitor vc -nic user

I think I had some issues, but was drowned in the sound related messages, so I later removed "-audiodev pa,id=pasound,timer-period=5000 -device ES1370,audiodev=pasound" as I was triggering the same audio issues I was seeing before.
That cleared the view but not things were fine AFAICS.

For the sake of not having a great test case I was running glxgears to see if they'd "still spin" or be stuck later when I come back.
After quite some minutes they were still spinning and working (it was in screensaver and I unlocked it to find it happy).

[Christian Ehrhardt  (paelzer)]

Fixes after 4.2:
Note we are on 4.2.1 already plus extra fixes as identified so far, but still:

$ git log --oneline upstream/master...v4.2.0 | grep -e virtio-gpu -e VirGL -e gtk
4bf47f3634 virtio-gpu: set physical dimensions for EDID
3745d59ee4 virtio-gpu-3d: fix abnormal display after a warm reboot
7b0de5b796 virtio-gpu: build modular
3b593b3fe4 virtio-gpu: make virtio_gpu_ops static
eb398a54e3 virtio-gpu: fix unmap the already mapped items
dc26435edb ui/gtk: Update refresh interval after widget is realized
2cd1e3f915 ui/gtk-gl-area: Plug memleak in gd_gl_area_create_context()
e94f068720 Revert "vga: build virtio-gpu as module"
8d5a24c83d vga: build virtio-gpu as module
9ad7ecf6a6 vga: build virtio-gpu only once
1454192746 ui/gtk: use native keyboard scancodes on Windows
d3953bf797 ui/gtk: don't pass on win keys without keyboard grab
fd7c1bea17 ui/gtk: remove unused variable ignore_keys
9ef99eccb1 ui/gtk: remove unused code
bd593d2cd9 ui/gtk: fix handling of AltGr key on Windows
02501fc393 compat: disable edid on correct virtio-gpu device
d2763944e2 tests/docker: Update VirGL to v0.8.0
5b9d40fafe tests/docker: Remove obsolete VirGL --with-glx configure option
72e3c1dd57 tests/docker: Update VirGL git repository URL
9cfca0b937 ui/gtk: implement show-cursor option
7f4d96f960 ui/gtk: Fix gd_refresh_rate_millihz() when widget window is not realized
31ab416d7d ui/gtk: Update gd_refresh_rate_millihz() to handle VirtualConsole
28b58f19d2 ui/gtk: Get display refresh rate with GDK version 3.22 or later
c4c00922cc display/gtk: get proper refreshrate

About half of that is in 5.0, the rest in 5.1 or no release at all yet.
Unfortunately nothing of the above sounds exactly like "yeah this is the issue".

Next:
- get back to my running glxgears if they still run fine
- could it actually be a sound issue going through GTK/SDL? I need to try the android without sound device as well...
- Try the same with more recent qemu (we have 5.0 in groovy, 21.04 didn't start yet but then will have 5.1 soon once it starts to open)

[Christian Ehrhardt  (paelzer)]

Ha, I found something that fells like a stuck guest with Ubuntu as well, but it wasn't "as stuck as Android".
I have found after a while that it seems infinitely happy to run without focus (no mouse / keyboard events getting to the guest).
But when I focus the guest sometimes the glxgears in the guest seemed stuck.

It almost seems like the host needs a "bump" to realize the guest still writes.
glxgears FPS usually are at 180-200 for me.
In those stutter moments they drop to ~5-20 FPS.

To give the host the bump for me it always worked to leave the guest mouse-capture (CTRL+ALT+G) and select and other window on the host. That made it realize "oh there is content" and things moved correctly again.

I'm unsure to what extend that is the same or a different problem, so I'm not going much further down this route.

Next:_ trying android ISO without sound device (and trying the host focus trick).

[Christian Ehrhardt  (paelzer)]

- The drop of the sound device nor the "bump the host UI to force updates" didn't help the android case :-/
- The Android CD also has a "Live CD VESA Mode - No GPU hardware acceleration"
  Trying that seems to work more smoothly at first, but later on fails for other reasons and
  obviously would limit the usage of this guest with real apps that need acceleration.

Next: trying newer qemu ...

[Christian Ehrhardt  (paelzer)]

qemu 4.2.1 / virglrenderer 0.8.2-1ubuntu1 - issues, see above
qemu 5.0 / virglrenderer 0.8.2-4 - Seems to work fine for me

That is interesting, I'll stop trying to prep an experimental 5.1 in https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4302/+packages then.

I've seen acceleration and multi-gpu fail in guests dependent on the host number of monitors and one other difference between my 4.2.1 and my 5.0 system is that the 5.0 system has just one screen (and generally is on groovy level).

@Olivier - could you give your case a try on Ubuntu groovy as well to confirm that the software levels in Ubuntu 20.10 really fix this (and not just being a random chance on the HW I used).
Once that would be confirmed we could start trying to separate
a) which package upgrade fixes the issue (qemu, virtglrenderer, any other part oft he Host UI, ..)?
b) once we know the package we can try to identify the change that fixes it

Therefore do you have a chance to try Ubuntu Groovy on the HW that gave you the issues (or identical HW)?

[Olivier Robert (novhak)]

Hello Christian,

I should have pointed that the log is from the Android system, not Qemu or my host system !

I got the failure message running the following command in an Android shell :

logcat '*:F'

(which means display log entries from all facilities (*), with the Fatal (F) severity)

It seems indeed that Fosshub has a hosting problem with the Android-x86 images, I'll have to report this to the project maintainer.

You seem to experience the same crash as I do. Bootloader OK, the GUI is responsive at the beginning, and it crashes after a variable amount of time.

You're right, the bug #1898490 looks like it could be related, I don't see the virgl=on option, but I suppose it's on by default.

I normally have those messages on my Qemu instance :
gl_version 45 - core profile enabled
GLSL feature level 430
virtio_input_hid_handle_status: unknown type 20
virtio_input_hid_handle_status: unknown type 20

The virtio_input_hid messages don't seem to be a problem, and certainly unrelated to the Android 9.0 crashing problem since at the time I tried with other, non-virtio input devices, I didn't have that message but it was still crashing the same way.

It happens that I have that "stale GL error" from time to time, that almost always corresponds to an app not displaying properly in Android. Generally, quitting and restarting the app solves the problem, but not always, there are cases and Android apps that never worked correctly with virglrenderer, such as Armello.

So, virglrenderer seems less stable with Android (or is it virtio-vga ?). In particular, switching from the surfaceflinger OpenGL display to a VGA, non-OpenGL console display (Alt+F1) never worked correctly (Alt+F7 to go back to the surfaceflinger display).

However, as I said before, it seems to me it shouldn't behave differently depending on which display, GTK or SDL, is used.

Concerning other frontends, I'm not familiar with those since my setup isn't headless : I'm not a server guy, I run the emulator on my laptop, so apart from GTK and SDL, it's not clear to me if I could run something else that would give me 3D acceleration. Moreover, my hardware is more than 6 years old now, and lacks some virtualisation capabilities that could serve as an alternative to virglrenderer.

Anyway virglrenderer is still pre 1.0 so I guess it's the prime suspect after all.

I will upgrade to Groovy next month, I'll keep you informed on that (I may even try Qemu 5.0 before upgrading).

[Christian Ehrhardt  (paelzer)]

Thanks Olivier for the feedback.
Looking forward if groovy fixes things for you as well then - with graphics things often seem "hard to ensure" so the more results = the better.

My test box that worked with groovy is similarly old to yours. So maybe I should re-deploy it with focal and see if on there I can reproduce the issue to then upgrade one-by-one.

[Christian Ehrhardt  (paelzer)]

I re-installed my test system (an older NUC) and it works just fine on Focal as well.
I was running Android for ~10 minutes and on my former tests (other system) it never made >4.

Software levels are mostly equal (a fully upgraded Focal).
But also the HW isn't "too" different:

Nuc:
lspci -s 02.0 -vv
00:02.0 VGA compatible controller: Intel Corporation HD Graphics 6000 (rev 09) (prog-if 00 [VGA controller])
 Subsystem: Intel Corporation HD Graphics 6000
 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
 Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
 Latency: 0
 Interrupt: pin A routed to IRQ 48
 Region 0: Memory at f6000000 (64-bit, non-prefetchable) [size=16M]
 Region 2: Memory at e0000000 (64-bit, prefetchable) [size=256M]
 Region 4: I/O ports at f000 [size=64]
 Expansion ROM at 000c0000 [virtual] [disabled] [size=128K]
 Capabilities: <access denied>
 Kernel driver in use: i915
 Kernel modules: i915

I also attached an image what the guest reports as GPU.

[Christian Ehrhardt  (paelzer)]

Laptop (Failing with Focal, unable to upgrade to Groovy)
$ lspci -s 00:02.0 -vvv
00:02.0 VGA compatible controller: Intel Corporation UHD Graphics 620 (rev 07) (prog-if 00 [VGA controller])
 Subsystem: Lenovo UHD Graphics 620
 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
 Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx+
 Latency: 0
 Interrupt: pin A routed to IRQ 149
 Region 0: Memory at db000000 (64-bit, non-prefetchable) [size=16M]
 Region 2: Memory at 80000000 (64-bit, prefetchable) [size=512M]
 Region 4: I/O ports at e000 [size=64]
 Expansion ROM at 000c0000 [virtual] [disabled] [size=128K]
 Capabilities: <access denied>
 Kernel driver in use: i915
 Kernel modules: i915

Not too different I'd think :-/
Due to that I'm unsure where to go next.

Maybe after all my "multiple monitors" theory might be important (the laptop has 5 the working test box just 1).
Let me know from your groovy tests what you've got and also what your monitor setup looks like (for the remote chance to be related).

[Olivier Robert (novhak)]

I guess the next step would be to confirm that upgrading to Qemu 5.0 solves the problem. I'll try that either by directly compiling 5.0, or I'll wait until november when I will upgrade to Groovy.

However, I doubt it will really solve the problem, now I tend to stick to the idea that the problem comes from virglrenderer... but we'll see !

[Christian Ehrhardt  (paelzer)]

You could give the involved components a try on Focal+[1].
That would allow to switch the components one by one while staying on Focal.

There is no linux-generic-hwe-20.04 yet that is on the new level. But that you could try from [2] (even more versions to compare if needed).

[1]: https://launchpad.net/~canonical-server/+archive/ubuntu/server-backports/+packages
[2]: https://wiki.ubuntu.com/Kernel/MainlineBuilds

[Olivier Robert (novhak)]

Hi Christian ! I just upgraded to Groovy and it still crashes on my side.

As before, recompiling w/SDL and using it instead solves the problem.

I remember I tried to use some of those vhost devices (check "qemu-system-x86_64 -device help | grep vhost") in the hope it would work around the problem, using a dedicated Unix socket to exchange device-related data, but never managed to even have it correctly set up, maybe I should try again...

[Christian Ehrhardt  (paelzer)]

Thanks for the feedback Oliver!

IMHO re-enabling SDL for that is still no option for all the reasons outlined and discussed when it was disabled. Since we still miss a good "next step to go" other than trying new versions I'm unsure what to do for now.

For the sake of trying - I have qemu 5.1 in the new qemu 21.04 (in development but usable) which can be worth a shot.

Grml ... we don't even have a good crash to debug/report upstream just "it grinds to a halt" :-/.

Never the less especially after you have had a chance to try the most recent qemu 5.1 if still failing might consider reporting it to upstream mailing list [1] (there might be a graphic expert on the list that recognizes something).

P.S. Qemu 5.2 is out mid-December and in Ubuntu 21.04 in ~January which then is another version to try

[1]: https://lists.nongnu.org/mailman/listinfo/qemu-discuss

[Olivier Robert (novhak)]

While it seems to be a "virtual hardware" problem, I'm not sure the problem comes from Qemu. Right now the problem doesn't change much for me, as I have to patch Qemu for another bug that's not yet addressed, so adding SDL in the process doesn't change anything timewise.

In fact we do have a crash, but it's an Android crash. Not sure to what extent it could be used for diagnosis though... And honestly, I don't think trying Qemu 5.1 will change anything !

You're right, I will have to report this to the mailing list (along with that other bug I'm patching, which I did on their IRC channel, but no one was responding).

[Christian Ehrhardt  (paelzer)]

Update as I've not forgotten this.
So far I was still not able to reproduce this myself, I was either having cases where GTK+virtgl worked fine for my simple testing OR I had it broken but even when trying to add SDL it didn't help.
Still I appreciate all the debug you have done and while GTK is generally preferred you are not the only one with an edge case for SDL. Therefore in Impish and later I'll re-enable SDL support as I finally managed to complete the MIR process for it in bug 1256185.

Since enabling SDL is a helpful workaround but not an actual "fix" for this problem I'll not close this bug when doing that upload.

[Olivier Robert (novhak)]

Nice, thanks !

I've got a new laptop in the meantime, where I will likely use Intel's GVT-g GPU virtualisation feature (my old hardware couldn't), hence no need for virglrenderer, but of course that's only me. Moreover, virglrenderer still has the advantage of being hardware-independent.

Additionally, SDL has the advantage of completely grabbing the keyboard, as I remember having the problem that a Ctrl-Alt-Del wasn't caught using GTK (but maybe I don't remember correctly, because that sounds odd), while it clearly works fine with SDL.

[Christian Ehrhardt  (paelzer)]

Ok, since you are ok with the alternative of GVT-g and other users have SDL now I'll close this bug as incomplete (even though as stated in comment 23 it isn't a real fix to the issues in the GTK backend for this particular use case).

[Launchpad Janitor (janitor)]

[Expired for qemu (Ubuntu) because there has been no activity for 60 days.]

[Launchpad Janitor (janitor)]

[Expired for virglrenderer (Ubuntu) because there has been no activity for 60 days.]