Re: [Qemu-devel] bad USB tablet update rate on qemu-1.0

Re: [Qemu-devel] bad USB tablet update rate on qemu-1.0

[erik.rull]

Hi all,

I'm really sorry, but the bisectioning does not work for the versions that
I want to test.

I get a bunch of errors when bisectioning.

e.g. continuosly:
erik@debian:~/qemu-test/qemu-kvm$ make
  CC    x86_64-softmmu/monitor.o
In file included from /home/erik/qemu-test/qemu-kvm/qmp-commands.h:19,
                 from /home/erik/qemu-test/qemu-kvm/monitor.c:3145:
/home/erik/qemu-test/qemu-kvm/qapi-types.h:19:34: error:
qapi/qapi-types-core.h: No such file or directory
In file included from /home/erik/qemu-test/qemu-kvm/qmp-commands.h:19,
                 from /home/erik/qemu-test/qemu-kvm/monitor.c:3145:
/home/erik/qemu-test/qemu-kvm/qapi-types.h:21: error: expected expression
before 'typedef'
make[1]: *** [monitor.o] Error 1

Additionally there seem to be differences between the 1.0 version in git
and the 1.0 version for download - there it compiles... *argh*

Please help.
I tried several git bisect skip but that didn't help.
The commit that was tested is:
Bisecting: a merge base must be tested
[2d2339f995d7176dcb2de10d162aed323a1ffbf3] Merge commit
'f487d6278f75f84378833b8c3a67443346d639dc' into upstream-merge

I thought that only working/compiling stuff gets committed?

Btw. the master does not compile either!

Best regards,

Erik

[Qemu-devel] git bisect results (was: Re: bad USB tablet update rate on qemu-1.0)

[Erik Rull]

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.

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).

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.

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.

Thanks.

Best regards,

Erik

Re: [Qemu-devel] git bisect results

[Jan Kiszka]

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?

> 
> 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.

> 
> 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

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Re: [Qemu-devel] git bisect results

[Erik Rull]

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

Re: [Qemu-devel] git bisect results

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 3829 bytes --]

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



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]