Qemu GTK/SDL display problems

@Hans
Quote:
The CPU should run in its own thread. I'm not too familiar with that but QEMU has a main thread and vcpu threads for each CPU (but these machines only have 1 CPU) so the UI should not block the CPU, expecially with virtio that should communicate via shared buffer so it can't even be blocked by device access. Unless maybe if it's waiting on an interrupt that's delayed but I don't know how all this works so can't tell for sure.

Quote:
Some of the parameters of the EDID generated by QEMU is tunable (see qemu-edid -h) but frequency is not among those. Also as the edid device is within the display device setting these parameters aren't too easy. Either the virtio-gpu forwards them in which case you can add them to it like -device virio-gpu,xres=1920 or you may need to use -global which I never know how to use. The qemu/hd/display/edid-generate.c does have a refresh_rate parameter which is should get from the display but I'm not sure how that works or where it comes from. This is again something that you can ask on the list. I've seen patches before that matches refresh to screen but don't remember what was the end result of those. Somebody may remember if you ask or finally fix it.

@Hans
Quote:
Again, don't know what I'm talking about, just guessing but could it be related to resizing the bitmap? The problem seems to be related to HIDPI displays so maybe it scales the guest screen and uses a slow way to do that instead of some hardware accelerated way? If that's the case there could be some settings somewhere in SDL to help with that?

@Balaton

I would recommend that you first ask on some ubuntu formu.
If @Hans stardowefo kernel from the distribution and standard settings I think that someone can immediately verify whether he also has this problem.

Of course, there must be a description whether it is a "color" ubuntu such as Kubuntu, Xubuntu, Lubuntu if it uses any variation.
What graphics card (hopefully not nvidia) , what kernel, whether X11 or Wayland.... what desktop environment gnome, kde ...


I have checked at my place - all the problems that @Hans described (if they do not apply to what @Hans - Virtio is working on) do not occur at my place.

I remembered one topic, that a few months ago @Hans was thinking about changing his laptop and also had some problems... maybe jsete this is related to the current problems ?

@smarkusg
If the problem is QEMU related then asking on Ubuntu forums may not help that much. Some QEMU developers may use Ubuntu so asking there would allow them to test too but I don't think it's distro specific. Could be GPU specific and @Hans did mention NVidia (if that's using binary driver then hard to find out what's going on). But @Maijestro could also reproduce it on completely different hardware and OS so this may be something related to HIDPI display or QEMU. If this can be reproduced with a Linux guest too then reporting to the list may find somebody who debugs and fixes it, otherwise not likely to get fixed unless we debug and fix it.

This also reminded me that I think Ubuntu has some tool to gather all the hardware and software info you were mentioning such as X, kernel, driver versions and such which they ask to use when you report bugs. Don't know what it's called, but I think has "bug" in its name and that should answer all your questions about the setup.

@balaton

A bit of professional courtesy would be appreciated. You do NOT need to lecture a fellow developer about how posting problems on an obscure forum is unlikely to get them fixed. I haven't submitted any bug reports yet because, so far, I haven't had enough information to do so.

Quote:

I just tried disabling scaling, and performance went up (still slower than expected, but a lot better). The mouse pointer also suddenly works just fine. Looks like HIDPI may indeed be a problem...

Setting scaling to 200% also triggered a slow-down, and made the mouse pointer unusable again. So, any scaling is a problem.

This looks like a system/driver issue (not sure which module is to blame, yet). I've seen plenty of complaints about fractional scaling causing performance issues (and other problems). AFAIK, Ubuntu is also on the conservative side when updating packages, so these problems may well have been fixed upstream already.

The mouse pointer not handling scaling definitely is a QEMU issue, and there's already a bug report for it.** I'll add my observations to that ticket, and update the broken scaling bug report too...

Hans


** NOTE: This is with the mouse pointer input being in normal mode. IIRC, the recommendation is to use tablet mode (with a suitable driver on the guest OS). I haven't tried that out yet.

@smarkusg

Yes, I have an nvidia GPU. Actually, it's one of those dual GPU setups with an Intel HD Graphics 530 for low power usage, and an nvidia 960M for when more GPU power is needed.

My Ubuntu setup might be stuck with using the Intel GPU only. I tried switching it to using the nvida at all times, and ended up with a black QEMU window (plus warnings a QEMU context reset due to a hung GPU).

So, something's not working right on my system. The Intel GPU should still be more than fast enough, but who knows what else is wrong.

Regardless, it's good enough for me to finish working on the driver.

Hans

@Hans

OK. In that case, I won't disturb or clutter the thread.
Have a successful work and completion of the driver.
I wish you a nice day

@Hans A humble suggestion from a non-development expert.
Have you tried to simulate an usb-mouse?
https://qemu-project.gitlab.io/qemu/system/devices/usb.html

@vagappc
USB vs. PS/2 mouse is not likely to make a difference because apart from how they appear to the guest OS they are both reporting relative movements. The issue is probably that guest has some mouse acceleretion settings (that if you move the mouse farther it advances faster) but if that does not match the host's settings then the host and guest pointer can get out of sync which results in the pointer jumping around to catch up with the guest position os just show on screen somewhere else than the guest thinks it should be. The solution is to either use same settings in guest and hosts for mouse acceleration, disable host cursor and draw it according to guest coordinates (this is guest_hwcursor=true option for ati-vga but other display devices don't have that so may not be an option; also it may couse the mouse pointer to freeze if the guest is busy so not as smooth as host side cursor) or to use an absolute pointing device that returns absolute coordinates not relative movement such as usb-tablet but that needs a guest driver to recognise and use it.

@Hans
Quote:
I did not mean to lecture you, sorry if it came across like that. English is not my native language so maybe I lack some politeness and usually say things in a direct way.

What I wanted to say is that the best way to ask questions about QEMU internals or discuss these with developers is to write to the qemu-devel list where somebody may remember something or point you to the right direction. The worst that could happen is that you get no answer but as long as it's on topic for QEMU then it's OK to use that list to discuss problems you get during QEMU related development.

Commenting on the QEMU bug tracker also helps but I'm not sure how many people will see that and if anything would be done with those reports other than keeping them to record known problems. Before migrating to gitlab, bug tickets were also sent to the mailing list but now they aren't so for example I won't know about those and maybe some others on the list are the same so that way is less effective to get help. I think there are some maintainers who might check bug reports but the UI part is lacking people so it's unlikely somebody would fix those bugs unless there's a patch submitted to the list by those interested in fixing them. I understand your focus is elsewhere so reporting bugs and recording your findings in the bug tracker helps but raising the topic on the list may get more people's attention and some of them might do something about it when it's discussed on the list rather than just accumulating bug tickets on the subject.

Those who are paid to work on QEMU are paid to work on those parts that their employer is interested in which is mainly running virtual servers with KVM in enterprise setting so the UI and old/niche hardware emulation is not a main focus but the project is welcoming for those too but it needs contributors to advance those areas and cannot expect some QEMU people to do the work as they usually don't have free time for that.

@Hans
Quote:

I don't know Ubuntu but I think there are two ways to use NVidia GPU: using the binary driver from NVidia which may work better for new cards and may be faster but may be less integrated with Linux so might have some problems. Or using the open-source Nouveau driver that may not support newest cards or have less features but may be better integrated with Linux so could have other problems than the binary driver. That means if you're using one of these then you could try the other one and see if that works better. But if it works stable with just the Intel GPU then that could also be enough just to reduce the complexity and have less things that could cause issues.

@Hans

Yesterday there was a patch that fixes some mouse problems especially under Qemu with Virtio GPU support.

https://patchwork.kernel.org/project/q ... tyeshwar.singh@intel.com/

So they are working on that too, so if they submit issues there is a good chance they will be fixed quickly. As mentioned, there is still some time until Qemu 9.0 and they can still get some issues fixed before then.

In addition, the large ppc Patch series I told you about is included in Qemu Master and the Sam460 engine has made great progress, execution is now very fast, but there are problems with direct access to memory that leads to mouse hangs and the SmartFileSystem cannot be used at the moment.

I just wanted to let you know that.