qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] git bisect results


From: Erik Rull
Subject: Re: [Qemu-devel] git bisect results
Date: Tue, 24 Jan 2012 19:55:28 +0100
User-agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0.1) Gecko/20111221 Firefox/9.0.1 SeaMonkey/2.6.1

Jan Kiszka wrote:
On 2012-01-24 18:24, Erik Rull wrote:
Hi all,

I assume that I found a possible source of the bad usbtablet update rate.

I did some git bisectioning but I didn't get a usable result due to too
many merges (or maybe my little knowledge to git), so I proceeded with some
manual bisectioning by manually selecting commits and tested them.

The problem was that the usbtablet update-rate in qemu-kvm-1.0 was really
bad compared to qemu-kvm-0.15.0.

Did you bisect qemu or qemu-kvm?

qemu-kvm.

The first commit where the cursor worked but the update rate was bad is
7cb78eec5cdf6e4131613c64cc1a29476f327242

Before this commit the usbtablet didn't work (no grabbing was possible).

That's a merge. Can you dig into the merged patches to find the one that
resolved the grabbing issue? Might be 21635e121a. Then that can be
backported while bisecting the tree for the other issue.

How can I do that (digging into the merge)? I'm not too familiar with git, I see only the whole merge as one commit. Or do you mean digging manually in the single diffs that are in the patch and try each of them? How does the backport work? If I change something during bisecting, git complains that it cannot proceed due to changed files.

But in 0.15.0 it worked. So I continued searching for interesting points
between these versions.

One point was the SDL commit done 2011-08-05 by Jan Kiszka.
There I found changes that affected the -full-screen option.

So I took the version from the commit above and just started with the
-full-screen option.
And everything was fine (qemu-kvm-1.0 as well)! The update rate is very
good with this option.

If you go full-screen there is constant grabbing. But I do not see the
correlation with the update rate when in windowed mode.


But I was not able to find the real change that caused the bad update rate.

Jan - is it possible to track down with this information the cause of the
bad update rate? It seems to be related to SDL - the VNC option is working
fine without -full-screen.
I would like to work without the -full-screen option.

I still cannot follow, specifically as I have XP with tablet running
here. Haven't noticed any problems so far, just rechecked against
qemu-kvm head.

Jan


Which CPU do you have on your host? I have a Core2Duo T6800 and the guest running on one core. There the update rate is significant worse than on another system with a Core i7 (guest on a single core as well), on the faster system it is still visible. Maybe its related to the onboard graphics? I don't know, I just see the significant differences between fullscreen and windowed mode.

Thanks for your help.

Best regards,

Erik



reply via email to

[Prev in Thread] Current Thread [Next in Thread]