From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:57231) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RplWd-00005c-57 for qemu-devel@nongnu.org; Tue, 24 Jan 2012 13:55:24 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RplWY-0006u2-63 for qemu-devel@nongnu.org; Tue, 24 Jan 2012 13:55:23 -0500 Received: from moutng.kundenserver.de ([212.227.126.171]:59373) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RplWX-0006ty-P3 for qemu-devel@nongnu.org; Tue, 24 Jan 2012 13:55:18 -0500 Message-ID: <4F1EFEA0.2090708@rdsoftware.de> Date: Tue, 24 Jan 2012 19:55:28 +0100 From: Erik Rull MIME-Version: 1.0 References: <0N3oon-1SLIfp2hzg-00ckUZ@icpu819.kundenserver.de> <4F1EE930.40002@rdsoftware.de> <4F1EF639.8000108@siemens.com> In-Reply-To: <4F1EF639.8000108@siemens.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] git bisect results List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: "qemu-devel@nongnu.org" 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