Remix OS on Qemu

Hi, did anyone install Remix OS in Qemu?
I used the ISO from the zipfile (as a live CD). Starts well, looks good, but I can move the mouse only when I press a mouse button :frowning:
I burned the ISO on a DVD and started the whole PC with it: no problem.
Who can help me?

Greetings, Wim

What options are you using, maybe add -usbdevice mouse to override the default PS/@ one?

No, does not help.

Greetings, Wim

To avoid misunderstanding, pls provide

Your entire command invoking your guest.
Link to the distro image download.
Links to any guides you may be following

Also, is there any reason you’re preferring to invoke using QEMU instead of KVM?

So, for example…
Make sure you’re running an x86/x64 image and not something intended to run on Android (That would be a good reason to run on QEMU), and then of course “touch” gestures are different than mouse events…


Hi, I downloaded,

I Unzipped the ISO - that is my IDE CDROM1 drive in Qemu
The IDE Disk1 in Qemu is /mnt/Remix-OS/virtio26.qcow2 12.00 GB
I booted from the CDROM drive and I gave the options UVESA_MODE=1680x1050 INSTALL=1
That installed Remix-OS on the Disk 1.

After that I booted from Disk 1: a beautiful working OS except the mouse, I can only move it when I press a mouse button…

Oh yes, Qemu works together with KVM in my system :slight_smile:

Then I burned the ISO on a DVD and started the whole computer from the DVD: a live session of Remix-OS. Now the mouse works fine, but when I start the computer normal after that I have to reset my KVM-switch (hardware: 2 computers, 1 keyboard, 1 video, 1 mouse).
I think Remix-OS does something strange with the mouse…

Thanks for helping me!
Greetings, Wim

By your reference to QEMU I assume you might not have installed KVM using YAST (You probably should).

A few years ago, QEMU was absorbed into KVM (and Xen), so now QEMU is considered a sub-set technology of KVM.
The diff is that if you run KVM, you are using CPU extensions and can benefit from the hardware acceleration.
Although things are currently changing, invoking QEMU specifically and not KVM will put you in full emulation mode which is slower than paravirtualization, but give you the ability to run Guests on completely alien hardware architecture, like ARM, SPARCS, Alpha, Dec, x286, etc.

If the image really is an Android-x86, then you probably shouldn’t be invoking QEMU, whether launching from a console or modifying libvirt to implement QEMU instead of KVM (I didn’t ask you about this earlier because I don’t know yet that it’s related specifically to your mouse issue), you should be running KVM.

Is your host machine (openSUSE) using a touchscreen?

In any case,
However you installed your QEMU, I highly recommend you open up YAST and install KVM using the “install virtualization” applet if you didn’t do that before.


I’ve taken a brief look at Remix on VMware instead of KVM or QEMU, the mouse didn’t behave differently than expected.

So, suspect that you have Tablet/touch enabled.
Depending on how you are launching your Guest, the community openSUSE documentation recommends that Tablet/touch be enabled to support automatically sensing the mouse focus when you move your mouse between the Guest and the Host’s desktop… When I saw that, I opined that this could have unexpected consequences including what you describe. Look for this setting (shouldn’t be default but who knows if this setting was turned on in some recent update…) and disable if you see it. Sorry, since you haven’t been specific how you’re managing and launching your Guests I have no idea if you’re using libvirt (vm manager) or something else so can’t provide specifics.

When Tablet/touch is disabled, you will need to release the mouse focus from your Guest using a keystroke combination.


As I said, Qemu and KVM work together in my system.

That was it. Problem solved!
Thank you very much!

Greetings, Wim