On 2012-01-24 19:55, Erik Rull wrote: > 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.
Using qemu would avoid having to step through qemu-kvm merges in addition to the merges in upstream. Specifically if the issue is independent of the tree, upstream is preferred (patch needs to go there anyway). > >>> 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. gitk e.g. nicely visualizes what was merged. Provided you are in upstream, simply checking out (git checkout <hash) a particular commit from the merged branch can help to check the effect of that 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. git reset --hard See also man git-bisect, "automatically bisect with hot-fix" for details on how to apply a fix while walking through the tree. This can, of course, also be done manually if only few commits need to be checked. > >>> 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. I have an i7. So you see an increased host load? So high that the old CPU is at 100%? > Maybe its related to the > onboard graphics? I don't know, I just see the significant differences > between fullscreen and windowed mode. Will check if there is a difference in the load for me. That should be CPU independent. Jan
signature.asc
Description: OpenPGP digital signature
