Re: [Qemu-devel] git bisect results

Re: [Qemu-devel] git bisect results

[erik.rull]

Hi Jan,

This little change fixes my problem with the usb-tablet update rate.

Can you please verify if this has some side effects?

If not, can you post a real patch?
I don't know how to handle the whole patching and committing stuff exactly.

Thanks.

Erik

-- 

diff --git a/ui/sdl.c b/ui/sdl.c
index 8cafc44..ecd70db 100644
--- a/ui/sdl.c
+++ b/ui/sdl.c
@@ -769,7 +769,7 @@ static void handle_mousemotion(DisplayState *ds,
SDL_Event *ev)
 {
     int max_x, max_y;

-    if (is_graphic_console() &&
+/*    if (is_graphic_console() &&
         (kbd_mouse_is_absolute() || absolute_enabled)) {
         max_x = real_screen->w - 1;
         max_y = real_screen->h - 1;
@@ -782,7 +782,7 @@ static void handle_mousemotion(DisplayState *ds,
SDL_Event *ev)
             ev->motion.y > 0 && ev->motion.y < max_y)) {
             sdl_grab_start();
         }
-    }
+    }*/
     if (gui_grab || kbd_mouse_is_absolute() || absolute_enabled) {
         sdl_send_mouse_event(ev->motion.xrel, ev->motion.yrel, 0,
                              ev->motion.x, ev->motion.y, ev->motion.state);

Re: [Qemu-devel] git bisect results

[Jan Kiszka]

On 2012-01-25 12:48, erik.rull@rdsoftware.de wrote:
> Hi Jan,

You should CC me then... :)

> 
> This little change fixes my problem with the usb-tablet update rate.
> 
> Can you please verify if this has some side effects?

Surely as it disables in general valid code, namely the auto-grabbing
feature. You should notice the difference.

> 
> If not, can you post a real patch?
> I don't know how to handle the whole patching and committing stuff exactly.

We need to understand the problem first anyway, and as I cannot
reproduce it, I will need you help:

Can you instrument the code, e.g. with printf, to find out which of the
disabled branches is taken when, specifically how often? Can you also
check if values like max_x/max_y or the ev->motion content make sense
for your setup?

Thanks,
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-25 12:48, erik.rull@rdsoftware.de wrote:
>> Hi Jan,
>
> You should CC me then... :)

I will do that for upcoming emails.

>>
>> This little change fixes my problem with the usb-tablet update rate.
>>
>> Can you please verify if this has some side effects?
>
> Surely as it disables in general valid code, namely the auto-grabbing
> feature. You should notice the difference.
>
>>
>> If not, can you post a real patch?
>> I don't know how to handle the whole patching and committing stuff exactly.
>
> We need to understand the problem first anyway, and as I cannot
> reproduce it, I will need you help:
>
> Can you instrument the code, e.g. with printf, to find out which of the
> disabled branches is taken when, specifically how often? Can you also
> check if values like max_x/max_y or the ev->motion content make sense
> for your setup?
>
> Thanks,
> Jan
>

Yes, I will add some counters and dump them in discrete timeslots to see 
what's the difference between the fullscreen and the windowed mode.

Maybe the removed code parts do not affect my main application where the 
window is resized to fullscreen. But for maintenance it is definitively 
windowed where I haven't had any problems with the grabbing / releasing up 
to now.

Best regards,

Erik

Re: [Qemu-devel] git bisect results

[Erik Rull]

[-- Attachment #1: Type: text/html, Size: 6960 bytes --]

Re: [Qemu-devel] git bisect results

[Jan Kiszka]

On 2012-01-30 12:34, Erik Rull wrote:
> Hi Jan,
> 
> I'm sorry, but this does not solve my issue. I applied the patch and 
> crosschecked that the resulting file looks fine.
> 
> The final function looks like:
> 
> static void sdl_grab_start(void)
> {
> /*
> * If the application is not active, do not try to enter grab state. This
> * prevents 'SDL_WM_GrabInput(SDL_GRAB_ON)' from blocking all the
> * application (SDL bug).
> */
> if (!(SDL_GetAppState() & SDL_APPINPUTFOCUS)) {
> return;
> }
> if (guest_cursor) {
> SDL_SetCursor(guest_sprite);
> if (!kbd_mouse_is_absolute() && !absolute_enabled)
> SDL_WarpMouse(guest_x, guest_y);
> } else
> sdl_hide_cursor();
> SDL_WM_GrabInput(SDL_GRAB_ON);
> gui_grab = 1;
> sdl_update_caption();
> }

That makes no sense as gui_grab must be 1 now. Please retry your
previous instrumentation.

Thanks,
Jan

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

Re: [Qemu-devel] git bisect results

[Erik Rull]

On January 30, 2012 at 12:52 PM Jan Kiszka <jan.kiszka@siemens.com> wrote:

> On 2012-01-30 12:34, Erik Rull wrote:
> > Hi Jan,
> >
> > I'm sorry, but this does not solve my issue. I applied the patch and
> > crosschecked that the resulting file looks fine.
> >
> > The final function looks like:
> >
> > static void sdl_grab_start(void)
> > {
> > /*
> > * If the application is not active, do not try to enter grab state.
This
> > * prevents 'SDL_WM_GrabInput(SDL_GRAB_ON)' from blocking all the
> > * application (SDL bug).
> > */
> > if (!(SDL_GetAppState() & SDL_APPINPUTFOCUS)) {
> > return;
> > }
> > if (guest_cursor) {
> > SDL_SetCursor(guest_sprite);
> > if (!kbd_mouse_is_absolute() && !absolute_enabled)
> > SDL_WarpMouse(guest_x, guest_y);
> > } else
> > sdl_hide_cursor();
> > SDL_WM_GrabInput(SDL_GRAB_ON);
> > gui_grab = 1;
> > sdl_update_caption();
> > }
>
> That makes no sense as gui_grab must be 1 now. Please retry your
> previous instrumentation.
>
> Thanks,
> Jan
>

You're right. So I added the instrumentation again.

Still looks strange.

So I added into the sdl_grab_start() a printf.
Wow - a lot of output!
This pointed me to all other sdl_grab_start() calls (and in additon to that
all sdl_grab_end() calls).

And here are the results of the qemu voting :-)

I already assigned a usable name to the printf output that is directly one
line above the corresponding sdl_grab_*() call, so you should be able to
find this easily in your code as well.

The huge number of recurring printf's are:

sdl_grab_start() called from absolute_mouse_grab()
sdl_grab_end() called from handle_activation()
sdl_grab_start() called from absolute_mouse_grab()
sdl_grab_end() called from handle_activation()
sdl_grab_start() called from absolute_mouse_grab()
sdl_grab_end() called from handle_activation()
sdl_grab_start() called from absolute_mouse_grab()
sdl_grab_end() called from handle_activation()
sdl_grab_start() called from absolute_mouse_grab()
sdl_grab_end() called from handle_activation()
sdl_grab_start() called from absolute_mouse_grab()
sdl_grab_end() called from handle_activation()
sdl_grab_start() called from absolute_mouse_grab()
sdl_grab_end() called from handle_activation()

Any idea how to proceed?

Maybe the first two if-statements in handle_activation() cause the problem?
Because there the two given functions are called in sequence if both
if-clauses are valid one after the other. Maybe the first one sets the
state so that the second if is valid, too. Maybe a simple else if solves
the issue? I'm not familiar with the variables that are checked here, so
it's just a guess.

Best regards,

Erik

Re: [Qemu-devel] git bisect results

[Jan Kiszka]

On 2012-01-30 14:17, Erik Rull wrote:
> 
> 
> 
> On January 30, 2012 at 12:52 PM Jan Kiszka <jan.kiszka@siemens.com> wrote:
> 
>> On 2012-01-30 12:34, Erik Rull wrote:
>>> Hi Jan,
>>>
>>> I'm sorry, but this does not solve my issue. I applied the patch and
>>> crosschecked that the resulting file looks fine.
>>>
>>> The final function looks like:
>>>
>>> static void sdl_grab_start(void)
>>> {
>>> /*
>>> * If the application is not active, do not try to enter grab state.
> This
>>> * prevents 'SDL_WM_GrabInput(SDL_GRAB_ON)' from blocking all the
>>> * application (SDL bug).
>>> */
>>> if (!(SDL_GetAppState() & SDL_APPINPUTFOCUS)) {
>>> return;
>>> }
>>> if (guest_cursor) {
>>> SDL_SetCursor(guest_sprite);
>>> if (!kbd_mouse_is_absolute() && !absolute_enabled)
>>> SDL_WarpMouse(guest_x, guest_y);
>>> } else
>>> sdl_hide_cursor();
>>> SDL_WM_GrabInput(SDL_GRAB_ON);
>>> gui_grab = 1;
>>> sdl_update_caption();
>>> }
>>
>> That makes no sense as gui_grab must be 1 now. Please retry your
>> previous instrumentation.
>>
>> Thanks,
>> Jan
>>
> 
> You're right. So I added the instrumentation again.
> 
> Still looks strange.
> 
> So I added into the sdl_grab_start() a printf.
> Wow - a lot of output!
> This pointed me to all other sdl_grab_start() calls (and in additon to that
> all sdl_grab_end() calls).
> 
> And here are the results of the qemu voting :-)
> 
> I already assigned a usable name to the printf output that is directly one
> line above the corresponding sdl_grab_*() call, so you should be able to
> find this easily in your code as well.
> 
> The huge number of recurring printf's are:
> 
> sdl_grab_start() called from absolute_mouse_grab()
> sdl_grab_end() called from handle_activation()
> sdl_grab_start() called from absolute_mouse_grab()
> sdl_grab_end() called from handle_activation()
> sdl_grab_start() called from absolute_mouse_grab()
> sdl_grab_end() called from handle_activation()
> sdl_grab_start() called from absolute_mouse_grab()
> sdl_grab_end() called from handle_activation()
> sdl_grab_start() called from absolute_mouse_grab()
> sdl_grab_end() called from handle_activation()
> sdl_grab_start() called from absolute_mouse_grab()
> sdl_grab_end() called from handle_activation()
> sdl_grab_start() called from absolute_mouse_grab()
> sdl_grab_end() called from handle_activation()
> 
> Any idea how to proceed?
> 
> Maybe the first two if-statements in handle_activation() cause the problem?
> Because there the two given functions are called in sequence if both
> if-clauses are valid one after the other. Maybe the first one sets the
> state so that the second if is valid, too. Maybe a simple else if solves
> the issue?

ev->active.gain makes both clauses mutually exclusive - unless someone
messes with the memory of the event object.

> I'm not familiar with the variables that are checked here, so
> it's just a guess.

So handle_activation() is called directly after absolute_mouse_grab(),
and the reported event contains

state = SDL_APPINPUTFOCUS
gain = 0
(please validate!)

That would mean we are constantly losing the input focus again after
trying to gain it via SDL_WM_GrabInput. Weird.

What's the call chain for absolute_mouse_grab()?

Jan

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

Re: [Qemu-devel] git bisect results

[Erik Rull]

On January 30, 2012 at 2:48 PM Jan Kiszka <jan.kiszka@siemens.com> wrote:

> On 2012-01-30 14:17, Erik Rull wrote:
> >
> >
> >
> > On January 30, 2012 at 12:52 PM Jan Kiszka <jan.kiszka@siemens.com>
wrote:
> >
> >> On 2012-01-30 12:34, Erik Rull wrote:
> >>> Hi Jan,
> >>>
> >>> I'm sorry, but this does not solve my issue. I applied the patch and
> >>> crosschecked that the resulting file looks fine.
> >>>
> >>> The final function looks like:
> >>>
> >>> static void sdl_grab_start(void)
> >>> {
> >>> /*
> >>> * If the application is not active, do not try to enter grab state.
> > This
> >>> * prevents 'SDL_WM_GrabInput(SDL_GRAB_ON)' from blocking all the
> >>> * application (SDL bug).
> >>> */
> >>> if (!(SDL_GetAppState() & SDL_APPINPUTFOCUS)) {
> >>> return;
> >>> }
> >>> if (guest_cursor) {
> >>> SDL_SetCursor(guest_sprite);
> >>> if (!kbd_mouse_is_absolute() && !absolute_enabled)
> >>> SDL_WarpMouse(guest_x, guest_y);
> >>> } else
> >>> sdl_hide_cursor();
> >>> SDL_WM_GrabInput(SDL_GRAB_ON);
> >>> gui_grab = 1;
> >>> sdl_update_caption();
> >>> }
> >>
> >> That makes no sense as gui_grab must be 1 now. Please retry your
> >> previous instrumentation.
> >>
> >> Thanks,
> >> Jan
> >>
> >
> > You're right. So I added the instrumentation again.
> >
> > Still looks strange.
> >
> > So I added into the sdl_grab_start() a printf.
> > Wow - a lot of output!
> > This pointed me to all other sdl_grab_start() calls (and in additon to
that
> > all sdl_grab_end() calls).
> >
> > And here are the results of the qemu voting :-)
> >
> > I already assigned a usable name to the printf output that is directly
one
> > line above the corresponding sdl_grab_*() call, so you should be able
to
> > find this easily in your code as well.
> >
> > The huge number of recurring printf's are:
> >
> > sdl_grab_start() called from absolute_mouse_grab()
> > sdl_grab_end() called from handle_activation()
> > sdl_grab_start() called from absolute_mouse_grab()
> > sdl_grab_end() called from handle_activation()
> > sdl_grab_start() called from absolute_mouse_grab()
> > sdl_grab_end() called from handle_activation()
> > sdl_grab_start() called from absolute_mouse_grab()
> > sdl_grab_end() called from handle_activation()
> > sdl_grab_start() called from absolute_mouse_grab()
> > sdl_grab_end() called from handle_activation()
> > sdl_grab_start() called from absolute_mouse_grab()
> > sdl_grab_end() called from handle_activation()
> > sdl_grab_start() called from absolute_mouse_grab()
> > sdl_grab_end() called from handle_activation()
> >
> > Any idea how to proceed?
> >
> > Maybe the first two if-statements in handle_activation() cause the
problem?
> > Because there the two given functions are called in sequence if both
> > if-clauses are valid one after the other. Maybe the first one sets the
> > state so that the second if is valid, too. Maybe a simple else if
solves
> > the issue?
>
> ev->active.gain makes both clauses mutually exclusive - unless someone
> messes with the memory of the event object.
>
> > I'm not familiar with the variables that are checked here, so
> > it's just a guess.
>
> So handle_activation() is called directly after absolute_mouse_grab(),
> and the reported event contains
>
> state = SDL_APPINPUTFOCUS
> gain = 0
> (please validate!)
>
> That would mean we are constantly losing the input focus again after
> trying to gain it via SDL_WM_GrabInput. Weird.
>
> What's the call chain for absolute_mouse_grab()?
>
> Jan
>
> --
> Siemens AG, Corporate Technology, CT T DE IT 1
> Corporate Competence Center Embedded Linux


Here the results:

Handle Activation 0: at function start (before the first if)
Handle Activation 1: between the first and the second if
Handle Activation 2: after the second if

The output is formatted like:
printf("Handle Activation 0: %d %d %d %d\n",gui_grab,(ev->active.state ==
SDL_APPINPUTFOCUS),ev->active.gain,gui_fullscreen);

Handle Activation 0: 0 1 1 0
Handle Activation 1: 0 1 1 0
absolute_mouse_grab() called from handle_activation()
sdl_grab_start() called from absolute_mouse_grab()
Handle Activation 2: 1 1 1 0
Handle Activation 0: 1 1 0 0
sdl_grab_end() called from handle_activation()
Handle Activation 1: 0 1 0 0
Handle Activation 2: 0 1 0 0
Handle Activation 0: 0 1 1 0
Handle Activation 1: 0 1 1 0
absolute_mouse_grab() called from handle_activation()
sdl_grab_start() called from absolute_mouse_grab()
Handle Activation 2: 1 1 1 0
Handle Activation 0: 1 1 0 0
sdl_grab_end() called from handle_activation()
Handle Activation 1: 0 1 0 0
Handle Activation 2: 0 1 0 0
Handle Activation 0: 0 1 1 0
Handle Activation 1: 0 1 1 0
absolute_mouse_grab() called from handle_activation()
sdl_grab_start() called from absolute_mouse_grab()
Handle Activation 2: 1 1 1 0

The gain seems to toggle between the successive calls of
handle_activation...
Next steps?

Best regards,

Erik

Re: [Qemu-devel] git bisect results

[Jan Kiszka]

On 2012-01-30 15:17, Erik Rull wrote:
> 
> 
> 
> On January 30, 2012 at 2:48 PM Jan Kiszka <jan.kiszka@siemens.com> wrote:
> 
>> On 2012-01-30 14:17, Erik Rull wrote:
>>>
>>>
>>>
>>> On January 30, 2012 at 12:52 PM Jan Kiszka <jan.kiszka@siemens.com>
> wrote:
>>>
>>>> On 2012-01-30 12:34, Erik Rull wrote:
>>>>> Hi Jan,
>>>>>
>>>>> I'm sorry, but this does not solve my issue. I applied the patch and
>>>>> crosschecked that the resulting file looks fine.
>>>>>
>>>>> The final function looks like:
>>>>>
>>>>> static void sdl_grab_start(void)
>>>>> {
>>>>> /*
>>>>> * If the application is not active, do not try to enter grab state.
>>> This
>>>>> * prevents 'SDL_WM_GrabInput(SDL_GRAB_ON)' from blocking all the
>>>>> * application (SDL bug).
>>>>> */
>>>>> if (!(SDL_GetAppState() & SDL_APPINPUTFOCUS)) {
>>>>> return;
>>>>> }
>>>>> if (guest_cursor) {
>>>>> SDL_SetCursor(guest_sprite);
>>>>> if (!kbd_mouse_is_absolute() && !absolute_enabled)
>>>>> SDL_WarpMouse(guest_x, guest_y);
>>>>> } else
>>>>> sdl_hide_cursor();
>>>>> SDL_WM_GrabInput(SDL_GRAB_ON);
>>>>> gui_grab = 1;
>>>>> sdl_update_caption();
>>>>> }
>>>>
>>>> That makes no sense as gui_grab must be 1 now. Please retry your
>>>> previous instrumentation.
>>>>
>>>> Thanks,
>>>> Jan
>>>>
>>>
>>> You're right. So I added the instrumentation again.
>>>
>>> Still looks strange.
>>>
>>> So I added into the sdl_grab_start() a printf.
>>> Wow - a lot of output!
>>> This pointed me to all other sdl_grab_start() calls (and in additon to
> that
>>> all sdl_grab_end() calls).
>>>
>>> And here are the results of the qemu voting :-)
>>>
>>> I already assigned a usable name to the printf output that is directly
> one
>>> line above the corresponding sdl_grab_*() call, so you should be able
> to
>>> find this easily in your code as well.
>>>
>>> The huge number of recurring printf's are:
>>>
>>> sdl_grab_start() called from absolute_mouse_grab()
>>> sdl_grab_end() called from handle_activation()
>>> sdl_grab_start() called from absolute_mouse_grab()
>>> sdl_grab_end() called from handle_activation()
>>> sdl_grab_start() called from absolute_mouse_grab()
>>> sdl_grab_end() called from handle_activation()
>>> sdl_grab_start() called from absolute_mouse_grab()
>>> sdl_grab_end() called from handle_activation()
>>> sdl_grab_start() called from absolute_mouse_grab()
>>> sdl_grab_end() called from handle_activation()
>>> sdl_grab_start() called from absolute_mouse_grab()
>>> sdl_grab_end() called from handle_activation()
>>> sdl_grab_start() called from absolute_mouse_grab()
>>> sdl_grab_end() called from handle_activation()
>>>
>>> Any idea how to proceed?
>>>
>>> Maybe the first two if-statements in handle_activation() cause the
> problem?
>>> Because there the two given functions are called in sequence if both
>>> if-clauses are valid one after the other. Maybe the first one sets the
>>> state so that the second if is valid, too. Maybe a simple else if
> solves
>>> the issue?
>>
>> ev->active.gain makes both clauses mutually exclusive - unless someone
>> messes with the memory of the event object.
>>
>>> I'm not familiar with the variables that are checked here, so
>>> it's just a guess.
>>
>> So handle_activation() is called directly after absolute_mouse_grab(),
>> and the reported event contains
>>
>> state = SDL_APPINPUTFOCUS
>> gain = 0
>> (please validate!)
>>
>> That would mean we are constantly losing the input focus again after
>> trying to gain it via SDL_WM_GrabInput. Weird.
>>
>> What's the call chain for absolute_mouse_grab()?
>>
>> Jan
>>
>> --
>> Siemens AG, Corporate Technology, CT T DE IT 1
>> Corporate Competence Center Embedded Linux
> 
> 
> Here the results:
> 
> Handle Activation 0: at function start (before the first if)
> Handle Activation 1: between the first and the second if
> Handle Activation 2: after the second if
> 
> The output is formatted like:
> printf("Handle Activation 0: %d %d %d %d\n",gui_grab,(ev->active.state ==
> SDL_APPINPUTFOCUS),ev->active.gain,gui_fullscreen);
> 
> Handle Activation 0: 0 1 1 0
> Handle Activation 1: 0 1 1 0
> absolute_mouse_grab() called from handle_activation()
> sdl_grab_start() called from absolute_mouse_grab()
> Handle Activation 2: 1 1 1 0
> Handle Activation 0: 1 1 0 0
> sdl_grab_end() called from handle_activation()
> Handle Activation 1: 0 1 0 0
> Handle Activation 2: 0 1 0 0
> Handle Activation 0: 0 1 1 0
> Handle Activation 1: 0 1 1 0
> absolute_mouse_grab() called from handle_activation()
> sdl_grab_start() called from absolute_mouse_grab()
> Handle Activation 2: 1 1 1 0
> Handle Activation 0: 1 1 0 0
> sdl_grab_end() called from handle_activation()
> Handle Activation 1: 0 1 0 0
> Handle Activation 2: 0 1 0 0
> Handle Activation 0: 0 1 1 0
> Handle Activation 1: 0 1 1 0
> absolute_mouse_grab() called from handle_activation()
> sdl_grab_start() called from absolute_mouse_grab()
> Handle Activation 2: 1 1 1 0
> 
> The gain seems to toggle between the successive calls of
> handle_activation...
> Next steps?

Try this:

diff --git a/ui/sdl.c b/ui/sdl.c
index 73e5839..c3fe80d 100644
--- a/ui/sdl.c
+++ b/ui/sdl.c
@@ -828,10 +828,6 @@ static void handle_mousebutton(DisplayState *ds, SDL_Event *ev)
 
 static void handle_activation(DisplayState *ds, SDL_Event *ev)
 {
-    if (gui_grab && ev->active.state == SDL_APPINPUTFOCUS &&
-        !ev->active.gain && !gui_fullscreen) {
-        sdl_grab_end();
-    }
     if (!gui_grab && ev->active.gain && is_graphic_console() &&
         (kbd_mouse_is_absolute() || absolute_enabled)) {
         absolute_mouse_grab();

I'm wondering what this code is branch should do anyway. If we grabbed
the input we can't unwillingly lose it. But that's just a theory for
now.

Jan

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

Re: [Qemu-devel] git bisect results

[Erik Rull]

On January 30, 2012 at 3:48 PM Jan Kiszka <jan.kiszka@siemens.com> wrote:

> On 2012-01-30 15:17, Erik Rull wrote:
> >
> >
> >
> > On January 30, 2012 at 2:48 PM Jan Kiszka <jan.kiszka@siemens.com>
wrote:
> >
> >> On 2012-01-30 14:17, Erik Rull wrote:
> >>>
> >>>
> >>>
> >>> On January 30, 2012 at 12:52 PM Jan Kiszka <jan.kiszka@siemens.com>
> > wrote:
> >>>
> >>>> On 2012-01-30 12:34, Erik Rull wrote:
> >>>>> Hi Jan,
> >>>>>
> >>>>> I'm sorry, but this does not solve my issue. I applied the patch
and
> >>>>> crosschecked that the resulting file looks fine.
> >>>>>
> >>>>> The final function looks like:
> >>>>>
> >>>>> static void sdl_grab_start(void)
> >>>>> {
> >>>>> /*
> >>>>> * If the application is not active, do not try to enter grab state.
> >>> This
> >>>>> * prevents 'SDL_WM_GrabInput(SDL_GRAB_ON)' from blocking all the
> >>>>> * application (SDL bug).
> >>>>> */
> >>>>> if (!(SDL_GetAppState() & SDL_APPINPUTFOCUS)) {
> >>>>> return;
> >>>>> }
> >>>>> if (guest_cursor) {
> >>>>> SDL_SetCursor(guest_sprite);
> >>>>> if (!kbd_mouse_is_absolute() && !absolute_enabled)
> >>>>> SDL_WarpMouse(guest_x, guest_y);
> >>>>> } else
> >>>>> sdl_hide_cursor();
> >>>>> SDL_WM_GrabInput(SDL_GRAB_ON);
> >>>>> gui_grab = 1;
> >>>>> sdl_update_caption();
> >>>>> }
> >>>>
> >>>> That makes no sense as gui_grab must be 1 now. Please retry your
> >>>> previous instrumentation.
> >>>>
> >>>> Thanks,
> >>>> Jan
> >>>>
> >>>
> >>> You're right. So I added the instrumentation again.
> >>>
> >>> Still looks strange.
> >>>
> >>> So I added into the sdl_grab_start() a printf.
> >>> Wow - a lot of output!
> >>> This pointed me to all other sdl_grab_start() calls (and in additon
to
> > that
> >>> all sdl_grab_end() calls).
> >>>
> >>> And here are the results of the qemu voting :-)
> >>>
> >>> I already assigned a usable name to the printf output that is
directly
> > one
> >>> line above the corresponding sdl_grab_*() call, so you should be able
> > to
> >>> find this easily in your code as well.
> >>>
> >>> The huge number of recurring printf's are:
> >>>
> >>> sdl_grab_start() called from absolute_mouse_grab()
> >>> sdl_grab_end() called from handle_activation()
> >>> sdl_grab_start() called from absolute_mouse_grab()
> >>> sdl_grab_end() called from handle_activation()
> >>> sdl_grab_start() called from absolute_mouse_grab()
> >>> sdl_grab_end() called from handle_activation()
> >>> sdl_grab_start() called from absolute_mouse_grab()
> >>> sdl_grab_end() called from handle_activation()
> >>> sdl_grab_start() called from absolute_mouse_grab()
> >>> sdl_grab_end() called from handle_activation()
> >>> sdl_grab_start() called from absolute_mouse_grab()
> >>> sdl_grab_end() called from handle_activation()
> >>> sdl_grab_start() called from absolute_mouse_grab()
> >>> sdl_grab_end() called from handle_activation()
> >>>
> >>> Any idea how to proceed?
> >>>
> >>> Maybe the first two if-statements in handle_activation() cause the
> > problem?
> >>> Because there the two given functions are called in sequence if both
> >>> if-clauses are valid one after the other. Maybe the first one sets
the
> >>> state so that the second if is valid, too. Maybe a simple else if
> > solves
> >>> the issue?
> >>
> >> ev->active.gain makes both clauses mutually exclusive - unless someone
> >> messes with the memory of the event object.
> >>
> >>> I'm not familiar with the variables that are checked here, so
> >>> it's just a guess.
> >>
> >> So handle_activation() is called directly after absolute_mouse_grab(),
> >> and the reported event contains
> >>
> >> state = SDL_APPINPUTFOCUS
> >> gain = 0
> >> (please validate!)
> >>
> >> That would mean we are constantly losing the input focus again after
> >> trying to gain it via SDL_WM_GrabInput. Weird.
> >>
> >> What's the call chain for absolute_mouse_grab()?
> >>
> >> Jan
> >>
> >> --
> >> Siemens AG, Corporate Technology, CT T DE IT 1
> >> Corporate Competence Center Embedded Linux
> >
> >
> > Here the results:
> >
> > Handle Activation 0: at function start (before the first if)
> > Handle Activation 1: between the first and the second if
> > Handle Activation 2: after the second if
> >
> > The output is formatted like:
> > printf("Handle Activation 0: %d %d %d %d\n",gui_grab,(ev->active.state
==
> > SDL_APPINPUTFOCUS),ev->active.gain,gui_fullscreen);
> >
> > Handle Activation 0: 0 1 1 0
> > Handle Activation 1: 0 1 1 0
> > absolute_mouse_grab() called from handle_activation()
> > sdl_grab_start() called from absolute_mouse_grab()
> > Handle Activation 2: 1 1 1 0
> > Handle Activation 0: 1 1 0 0
> > sdl_grab_end() called from handle_activation()
> > Handle Activation 1: 0 1 0 0
> > Handle Activation 2: 0 1 0 0
> > Handle Activation 0: 0 1 1 0
> > Handle Activation 1: 0 1 1 0
> > absolute_mouse_grab() called from handle_activation()
> > sdl_grab_start() called from absolute_mouse_grab()
> > Handle Activation 2: 1 1 1 0
> > Handle Activation 0: 1 1 0 0
> > sdl_grab_end() called from handle_activation()
> > Handle Activation 1: 0 1 0 0
> > Handle Activation 2: 0 1 0 0
> > Handle Activation 0: 0 1 1 0
> > Handle Activation 1: 0 1 1 0
> > absolute_mouse_grab() called from handle_activation()
> > sdl_grab_start() called from absolute_mouse_grab()
> > Handle Activation 2: 1 1 1 0
> >
> > The gain seems to toggle between the successive calls of
> > handle_activation...
> > Next steps?
>
> Try this:
>
> diff --git a/ui/sdl.c b/ui/sdl.c
> index 73e5839..c3fe80d 100644
> --- a/ui/sdl.c
> +++ b/ui/sdl.c
> @@ -828,10 +828,6 @@ static void handle_mousebutton(DisplayState *ds,
SDL_Event *ev)
> 
>  static void handle_activation(DisplayState *ds, SDL_Event *ev)
>  {
> -    if (gui_grab && ev->active.state == SDL_APPINPUTFOCUS &&
> -        !ev->active.gain && !gui_fullscreen) {
> -        sdl_grab_end();
> -    }
>      if (!gui_grab && ev->active.gain && is_graphic_console() &&
>          (kbd_mouse_is_absolute() || absolute_enabled)) {
>          absolute_mouse_grab();
>
> I'm wondering what this code is branch should do anyway. If we grabbed
> the input we can't unwillingly lose it. But that's just a theory for
> now.
>
> Jan
>
> --
> Siemens AG, Corporate Technology, CT T DE IT 1
> Corporate Competence Center Embedded Linux


That's it. Fine from my side now!

Best regards,

Erik

Re: [Qemu-devel] git bisect results

[Erik Rull]

[-- Attachment #1: Type: text/html, Size: 27387 bytes --]

Re: [Qemu-devel] git bisect results

[Jan Kiszka]

On 2012-01-26 14:10, Erik Rull wrote:
> Hi Jan,
> 
> 
> 
> here the results of the sdl printfs.
> 
> 
> 
> First of all the modified code:
> 
> 
> 
> #include <sys/time.h>
> 
> #define NO_DEBUG_PATHS 3
> int paths[NO_DEBUG_PATHS] = {0,0,0};
> int last_sec = 0;
> struct timeval tv;
> 
> static void handle_mousemotion(DisplayState *ds, SDL_Event *ev)
> {
>     int max_x, max_y;
> 
>     if (is_graphic_console() &&
>         (kbd_mouse_is_absolute() || absolute_enabled)) {
>         paths[0]++;
>         max_x = real_screen->w - 1;
>         max_y = real_screen->h - 1;
>         if (gui_grab && (ev->motion.x == 0 || ev->motion.y == 0 ||
>             ev->motion.x == max_x || ev->motion.y == max_y)) {
>             printf("Status1: %d %d %d %d %d\n",gui_grab,ev->motion.x,ev->motion.y,max_x,max_y);
>             sdl_grab_end();
>             paths[1]++;
>         }
>         if (!gui_grab && SDL_GetAppState() & SDL_APPINPUTFOCUS &&
>             (ev->motion.x > 0 && ev->motion.x < max_x &&
>             ev->motion.y > 0 && ev->motion.y < max_y)) {
>             printf("Status2: %d %d %d %d %d %d\n",gui_grab,ev->motion.x,ev->motion.y,max_x,max_y,(SDL_GetAppState() & SDL_APPINPUTFOCUS));
>             sdl_grab_start();
>             paths[2]++;
>         }
>     }
> 
>     gettimeofday(&tv, 0);
>     if (tv.tv_sec != last_sec)
>     {
>       int i=0;
>       for (i=0;i<NO_DEBUG_PATHS;i++)
>       {
>         printf("Path %d: %d ",i,paths[i]);
>       }
>       printf("\n");
>       last_sec = tv.tv_sec;
>     }
> 
>     if (gui_grab || kbd_mouse_is_absolute() || absolute_enabled) {
>         sdl_send_mouse_event(ev->motion.xrel, ev->motion.yrel, 0,
>                              ev->motion.x, ev->motion.y, ev->motion.state);
>     }
> }
> 
> 
> 
> Now the results for this printf for the windowed mode - I just moved the mouse around for several seconds:
> 
> 
> 
> Status2: 0 514 394 1023 767 2
> Path 0: 1 Path 1: 0 Path 2: 1
> Status2: 0 426 402 1023 767 2
> Status2: 0 415 403 1023 767 2
> Status2: 0 421 405 1023 767 2
> Status2: 0 565 401 1023 767 2
> Status2: 0 705 367 1023 767 2
> Status2: 0 941 143 1023 767 2
> Status2: 0 539 6 1023 767 2
> Status2: 0 445 96 1023 767 2
> Status2: 0 437 346 1023 767 2
> Status2: 0 667 644 1023 767 2
> Status2: 0 725 434 1023 767 2
> Status2: 0 549 234 1023 767 2
> Status2: 0 373 308 1023 767 2
> Status2: 0 331 510 1023 767 2
> Status2: 0 467 546 1023 767 2
> Status2: 0 503 438 1023 767 2
> Status2: 0 457 276 1023 767 2
> Status2: 0 343 210 1023 767 2
> Status2: 0 317 410 1023 767 2
> Path 0: 71 Path 1: 0 Path 2: 20
> Status2: 0 509 384 1023 767 2
> Status2: 0 471 228 1023 767 2
> Status2: 0 373 174 1023 767 2
> Status2: 0 195 172 1023 767 2
> Status2: 0 121 274 1023 767 2
> Status2: 0 375 400 1023 767 2
> Status2: 0 611 296 1023 767 2
> Status2: 0 495 168 1023 767 2
> Status2: 0 391 140 1023 767 2
> Status2: 0 231 242 1023 767 2
> Status2: 0 245 396 1023 767 2
> Status2: 0 385 484 1023 767 2
> Status2: 0 489 484 1023 767 2
> Status2: 0 577 356 1023 767 2
> Status2: 0 459 234 1023 767 2
> Status2: 0 305 246 1023 767 2
> Status2: 0 255 376 1023 767 2
> Status2: 0 353 540 1023 767 2
> Status2: 0 437 564 1023 767 2
> Status2: 0 593 518 1023 767 2
> Path 0: 142 Path 1: 0 Path 2: 40
> Status2: 0 535 298 1023 767 2
> Status2: 0 363 274 1023 767 2
> Status2: 0 279 362 1023 767 2
> Status2: 0 277 464 1023 767 2
> Status2: 0 313 506 1023 767 2
> Status2: 0 425 514 1023 767 2
> Status2: 0 447 430 1023 767 2
> Status2: 0 383 304 1023 767 2
> Status2: 0 378 305 1023 767 2
> Status2: 0 371 311 1023 767 2
> Status2: 0 377 314 1023 767 2
> Path 0: 175 Path 1: 0 Path 2: 51
> Status2: 0 485 268 1023 767 2
> Status2: 0 603 148 1023 767 2
> Status2: 0 479 74 1023 767 2
> Status2: 0 355 120 1023 767 2
> Status2: 0 217 240 1023 767 2
> Status2: 0 259 302 1023 767 2
> Status2: 0 399 306 1023 767 2
> Status2: 0 553 236 1023 767 2
> Status2: 0 575 188 1023 767 2
> Status2: 0 501 102 1023 767 2
> Status2: 0 351 124 1023 767 2
> Path 0: 218 Path 1: 0 Path 2: 62
> Status2: 0 281 164 1023 767 2
> Status2: 0 233 208 1023 767 2
> Status2: 0 195 300 1023 767 2
> Status2: 0 283 378 1023 767 2
> Status2: 0 525 386 1023 767 2
> Status2: 0 599 348 1023 767 2
> Status2: 0 549 296 1023 767 2
> Status2: 0 441 274 1023 767 2
> Status2: 0 383 274 1023 767 2
> Status2: 0 265 320 1023 767 2
> Status2: 0 235 388 1023 767 2
> Status2: 0 419 494 1023 767 2
> Status2: 0 573 448 1023 767 2
> Status2: 0 533 348 1023 767 2
> Status2: 0 439 296 1023 767 2
> Status2: 0 351 278 1023 767 2
> Status2: 0 303 282 1023 767 2
> Status2: 0 249 302 1023 767 2
> Status2: 0 239 316 1023 767 2
> Status2: 0 239 314 1023 767 2
> Path 0: 280 Path 1: 0 Path 2: 82
> Status2: 0 249 300 1023 767 2
> Status2: 0 257 298 1023 767 2
> Status2: 0 268 296 1023 767 2
> Path 0: 291 Path 1: 0 Path 2: 85
> Status2: 0 292 320 1023 767 2
> Path 0: 293 Path 1: 0 Path 2: 86
> Status2: 0 350 360 1023 767 2
> Status2: 0 514 398 1023 767 2
> Status2: 0 606 332 1023 767 2
> Status2: 0 496 236 1023 767 2
> Status2: 0 300 232 1023 767 2
> Status2: 0 232 276 1023 767 2
> Status2: 0 228 354 1023 767 2
> Status2: 0 364 366 1023 767 2
> Status2: 0 462 334 1023 767 2
> Status2: 0 482 316 1023 767 2
> Status2: 0 456 260 1023 767 2
> Status2: 0 342 296 1023 767 2
> Status2: 0 336 390 1023 767 2
> Status2: 0 470 404 1023 767 2
> Status2: 0 590 312 1023 767 2
> Status2: 0 480 246 1023 767 2
> Status2: 0 420 274 1023 767 2
> Path 0: 364 Path 1: 0 Path 2: 103
> Status2: 0 415 317 1023 767 2
> Status2: 0 429 312 1023 767 2
> Status2: 0 447 284 1023 767 2
> Status2: 0 453 284 1023 767 2
> Status2: 0 467 295 1023 767 2
> Status2: 0 587 327 1023 767 2
> Status2: 0 659 325 1023 767 2
> Status2: 0 677 297 1023 767 2
> Status2: 0 605 251 1023 767 2
> Status2: 0 505 253 1023 767 2
> Status2: 0 417 345 1023 767 2
> Status2: 0 447 433 1023 767 2
> Status2: 0 589 431 1023 767 2
> Status2: 0 665 393 1023 767 2
> Status2: 0 685 369 1023 767 2
> Status2: 0 689 358 1023 767 2
> Status2: 0 663 328 1023 767 2
> Path 0: 414 Path 1: 0 Path 2: 120
> Status2: 0 533 270 1023 767 2
> Status2: 0 461 266 1023 767 2
> Status2: 0 343 314 1023 767 2
> Status2: 0 359 416 1023 767 2
> Status2: 0 469 478 1023 767 2
> Status2: 0 631 474 1023 767 2
> Status2: 0 703 434 1023 767 2
> Status2: 0 741 348 1023 767 2
> Status2: 0 671 270 1023 767 2
> Status2: 0 511 250 1023 767 2
> Status2: 0 437 308 1023 767 2
> Status2: 0 413 380 1023 767 2
> Status2: 0 505 462 1023 767 2
> Status2: 0 715 446 1023 767 2
> Status2: 0 767 366 1023 767 2
> Status2: 0 533 278 1023 767 2
> Status2: 0 383 328 1023 767 2
> Status2: 0 373 428 1023 767 2
> Status2: 0 453 486 1023 767 2
> Status2: 0 529 498 1023 767 2
> Path 0: 486 Path 1: 0 Path 2: 140
> Status2: 0 795 450 1023 767 2
> Status2: 0 825 396 1023 767 2
> Status2: 0 713 304 1023 767 2
> Status2: 0 597 264 1023 767 2
> Status2: 0 407 296 1023 767 2
> Status2: 0 377 372 1023 767 2
> Status2: 0 383 438 1023 767 2
> Status2: 0 457 506 1023 767 2
> Status2: 0 617 494 1023 767 2
> Status2: 0 691 436 1023 767 2
> Status2: 0 709 384 1023 767 2
> Status2: 0 531 244 1023 767 2
> Status2: 0 273 222 1023 767 2
> Status2: 0 205 340 1023 767 2
> Status2: 0 263 432 1023 767 2
> Status2: 0 305 462 1023 767 2
> Status2: 0 581 424 1023 767 2
> Status2: 0 673 345 1023 767 2
> Status2: 0 575 267 1023 767 2
> Status2: 0 445 245 1023 767 2
> Path 0: 559 Path 1: 0 Path 2: 160
> Status2: 0 339 279 1023 767 2
> Status2: 0 317 357 1023 767 2
> Status2: 0 339 395 1023 767 2
> Status2: 0 443 441 1023 767 2
> Status2: 0 523 437 1023 767 2
> Status2: 0 587 405 1023 767 2
> Status2: 0 603 347 1023 767 2
> Status2: 0 439 361 1023 767 2
> Status2: 0 419 463 1023 767 2
> Status2: 0 519 495 1023 767 2
> Status2: 0 569 487 1023 767 2
> Status2: 0 635 425 1023 767 2
> Status2: 0 575 355 1023 767 2
> Status2: 0 499 379 1023 767 2
> Status2: 0 483 393 1023 767 2
> Status2: 0 447 443 1023 767 2
> Status2: 0 459 497 1023 767 2
> Status2: 0 561 513 1023 767 2
> Status2: 0 671 457 1023 767 2
> Status2: 0 695 384 1023 767 2
> Status2: 0 567 338 1023 767 2
> Path 0: 631 Path 1: 0 Path 2: 181
> Status2: 0 467 356 1023 767 2
> Status2: 0 463 498 1023 767 2
> Status2: 0 601 518 1023 767 2
> Status2: 0 697 416 1023 767 2
> Status2: 0 595 312 1023 767 2
> Status2: 0 453 302 1023 767 2
> Status2: 0 403 338 1023 767 2
> Status2: 0 425 448 1023 767 2
> Status2: 0 523 464 1023 767 2
> Status2: 0 549 417 1023 767 2
> Status2: 0 549 415 1023 767 2
> Status2: 0 550 408 1023 767 2
> Path 0: 676 Path 1: 0 Path 2: 193
> Status2: 0 550 406 1023 767 2
> Status2: 0 556 398 1023 767 2
> Status2: 0 616 376 1023 767 2
> Status2: 0 656 356 1023 767 2
> Status2: 0 800 308 1023 767 2
> Status2: 0 978 302 1023 767 2
> Status1: 1 1023 302 1023 767
> Status2: 0 1015 326 1023 767 2
> Path 0: 701 Path 1: 1 Path 2: 200
> Status2: 0 951 326 1023 767 2
> Status2: 0 905 326 1023 767 2
> Status2: 0 807 326 1023 767 2
> Status2: 0 729 326 1023 767 2
> Status2: 0 647 326 1023 767 2
> Status2: 0 543 326 1023 767 2
> Status2: 0 443 326 1023 767 2
> Status2: 0 402 326 1023 767 2
> Status2: 0 373 330 1023 767 2
> Status2: 0 347 330 1023 767 2
> Status2: 0 327 330 1023 767 2
> Status2: 0 313 331 1023 767 2
> Status2: 0 301 332 1023 767 2
> Status2: 0 291 336 1023 767 2
> Status2: 0 247 372 1023 767 2
> Status2: 0 237 413 1023 767 2
> Status2: 0 253 444 1023 767 2
> Status2: 0 271 444 1023 767 2
> Status2: 0 363 420 1023 767 2
> Status2: 0 393 394 1023 767 2
> Status2: 0 393 390 1023 767 2
> Path 0: 770 Path 1: 1 Path 2: 221
> Status2: 0 396 369 1023 767 2
> Status2: 0 397 366 1023 767 2
> Status2: 0 415 366 1023 767 2
> Status2: 0 501 366 1023 767 2
> Status2: 0 589 366 1023 767 2
> Status2: 0 685 366 1023 767 2
> Status2: 0 903 368 1023 767 2
> Status2: 0 1021 402 1023 767 2
> Path 0: 806 Path 1: 1 Path 2: 229
> Status2: 0 1022 401 1023 767 2
> Path 0: 807 Path 1: 1 Path 2: 230
> Path 0: 836 Path 1: 1 Path 2: 230
> Status2: 0 1022 332 1023 767 2
> Path 0: 852 Path 1: 1 Path 2: 231
> Status2: 0 1016 332 1023 767 2
> Status2: 0 1002 329 1023 767 2
> Path 0: 857 Path 1: 1 Path 2: 233
> Status2: 0 984 329 1023 767 2
> Status2: 0 976 329 1023 767 2
> Status2: 0 956 329 1023 767 2
> Status2: 0 946 329 1023 767 2
> Status2: 0 928 329 1023 767 2
> Status2: 0 920 329 1023 767 2
> Status2: 0 915 331 1023 767 2
> Status2: 0 913 332 1023 767 2
> Path 0: 886 Path 1: 1 Path 2: 241
> Status2: 0 885 334 1023 767 2
> Status2: 0 882 334 1023 767 2
> Status2: 0 872 334 1023 767 2
> Status2: 0 874 334 1023 767 2
> Status2: 0 880 332 1023 767 2
> Status2: 0 881 331 1023 767 2
> Status2: 0 890 330 1023 767 2
> Path 0: 898 Path 1: 1 Path 2: 248
> Status2: 0 940 330 1023 767 2
> Status2: 0 1021 330 1023 767 2
> Path 0: 904 Path 1: 1 Path 2: 250
> Status2: 0 1017 330 1023 767 2
> Status2: 0 1011 330 1023 767 2
> Status2: 0 1007 330 1023 767 2
> Status2: 0 991 330 1023 767 2
> Status2: 0 955 334 1023 767 2
> Status2: 0 931 334 1023 767 2
> Status2: 0 921 336 1023 767 2
> Status2: 0 929 336 1023 767 2
> Path 0: 929 Path 1: 1 Path 2: 258
> Status2: 0 932 336 1023 767 2
> Status2: 0 960 336 1023 767 2
> Status2: 0 1015 340 1023 767 2
> Path 0: 934 Path 1: 1 Path 2: 261
> Status2: 0 965 340 1023 767 2
> Status2: 0 765 308 1023 767 2
> Status2: 0 517 164 1023 767 2
> Status2: 0 411 66 1023 767 2
> Status2: 0 385 14 1023 767 2
> Status1: 1 373 0 1023 767
> Status2: 0 385 1 1023 767 2
> Path 0: 973 Path 1: 2 Path 2: 267
> Status2: 0 385 21 1023 767 2
> Status2: 0 377 39 1023 767 2
> Status2: 0 375 49 1023 767 2
> Status2: 0 373 51 1023 767 2
> Status2: 0 396 2 1023 767 2
> Path 0: 1002 Path 1: 2 Path 2: 272
> Status2: 0 388 32 1023 767 2
> Status2: 0 384 67 1023 767 2
> Status2: 0 380 89 1023 767 2
> Status2: 0 376 125 1023 767 2
> Status2: 0 376 137 1023 767 2
> Status2: 0 376 139 1023 767 2
> Status2: 0 376 141 1023 767 2
> Status2: 0 376 139 1023 767 2
> Status2: 0 376 96 1023 767 2
> Status2: 0 378 12 1023 767 2
> Status1: 1 380 0 1023 767
> Path 0: 1031 Path 1: 3 Path 2: 282
> Status2: 0 414 2 1023 767 2
> Path 0: 1043 Path 1: 3 Path 2: 283
> Status2: 0 412 10 1023 767 2
> Status2: 0 411 13 1023 767 2
> Status2: 0 405 27 1023 767 2
> Status2: 0 402 66 1023 767 2
> Status2: 0 398 120 1023 767 2
> Status2: 0 398 155 1023 767 2
> Status2: 0 398 183 1023 767 2
> Status2: 0 398 301 1023 767 2
> Path 0: 1072 Path 1: 3 Path 2: 291
> Status2: 0 398 405 1023 767 2
> Status2: 0 398 492 1023 767 2
> Status2: 0 398 628 1023 767 2
> Path 0: 1102 Path 1: 3 Path 2: 294
> Status2: 0 454 763 1023 767 2
> Status2: 0 458 758 1023 767 2
> Status2: 0 464 754 1023 767 2
> Status2: 0 473 739 1023 767 2
> Status2: 0 477 712 1023 767 2
> Status2: 0 505 566 1023 767 2
> Status2: 0 509 478 1023 767 2
> Status2: 0 509 417 1023 767 2
> Status2: 0 513 344 1023 767 2
> Status2: 0 513 299 1023 767 2
> Status2: 0 513 287 1023 767 2
> Status2: 0 513 283 1023 767 2
> Path 0: 1142 Path 1: 3 Path 2: 306
> Status2: 0 513 281 1023 767 2
> Status2: 0 491 257 1023 767 2
> Status2: 0 439 277 1023 767 2
> Status2: 0 375 385 1023 767 2
> Status2: 0 397 459 1023 767 2
> Status2: 0 473 457 1023 767 2
> Status2: 0 553 395 1023 767 2
> Status2: 0 603 281 1023 767 2
> Status2: 0 589 235 1023 767 2
> Status2: 0 577 213 1023 767 2
> Status2: 0 497 265 1023 767 2
> Status2: 0 439 343 1023 767 2
> Status2: 0 439 403 1023 767 2
> Status2: 0 461 425 1023 767 2
> Status2: 0 533 407 1023 767 2
> Status2: 0 617 347 1023 767 2
> Status2: 0 633 283 1023 767 2
> Status2: 0 593 247 1023 767 2
> Path 0: 1206 Path 1: 3 Path 2: 324
> Status2: 0 475 239 1023 767 2
> Status2: 0 373 317 1023 767 2
> Status2: 0 361 427 1023 767 2
> Status2: 0 469 455 1023 767 2
> Status2: 0 537 411 1023 767 2
> Status2: 0 567 363 1023 767 2
> Status2: 0 570 354 1023 767 2
> Status2: 0 558 352 1023 767 2
> Status2: 0 522 352 1023 767 2
> Status2: 0 470 360 1023 767 2
> Status2: 0 382 442 1023 767 2
> Status2: 0 380 520 1023 767 2
> Status2: 0 450 526 1023 767 2
> Status2: 0 588 388 1023 767 2
> Status2: 0 550 260 1023 767 2
> Status2: 0 432 208 1023 767 2
> Status2: 0 304 254 1023 767 2
> Status2: 0 228 308 1023 767 2
> Status2: 0 174 396 1023 767 2
> Path 0: 1274 Path 1: 3 Path 2: 343
> Status2: 0 90 572 1023 767 2
> Status2: 0 58 680 1023 767 2
> Status2: 0 46 740 1023 767 2
> Status2: 0 40 756 1023 767 2
> Status1: 1 36 767 1023 767
> Status2: 0 18 766 1023 767 2
> Status2: 0 18 764 1023 767 2
> Status2: 0 19 763 1023 767 2
> Status2: 0 27 761 1023 767 2
> Status2: 0 63 751 1023 767 2
> Status2: 0 151 731 1023 767 2
> Status2: 0 259 727 1023 767 2
> Path 0: 1310 Path 1: 4 Path 2: 354
> Status2: 0 351 719 1023 767 2
> Status2: 0 381 715 1023 767 2
> Status2: 0 385 715 1023 767 2
> Status2: 0 388 714 1023 767 2
> Status2: 0 388 714 1023 767 2
> Status2: 0 385 715 1023 767 2
> Status2: 0 381 715 1023 767 2
> Status2: 0 379 715 1023 767 2
> Status2: 0 319 723 1023 767 2
> Status2: 0 171 727 1023 767 2
> Status2: 0 89 731 1023 767 2
> Path 0: 1345 Path 1: 4 Path 2: 365
> Status2: 0 76 738 1023 767 2
> Status2: 0 46 762 1023 767 2
> Status2: 0 26 765 1023 767 2
> Status2: 0 60 745 1023 767 2
> Status2: 0 106 727 1023 767 2
> Status2: 0 190 711 1023 767 2
> Status2: 0 236 699 1023 767 2
> Status2: 0 244 699 1023 767 2
> Status2: 0 246 699 1023 767 2
> Path 0: 1385 Path 1: 4 Path 2: 374
> Status2: 0 256 703 1023 767 2
> Status2: 0 286 711 1023 767 2
> Status2: 0 306 711 1023 767 2
> Status2: 0 310 711 1023 767 2
> Status2: 0 326 713 1023 767 2
> Status2: 0 329 712 1023 767 2
> Status2: 0 348 674 1023 767 2
> Status2: 0 352 662 1023 767 2
> Status2: 0 352 644 1023 767 2
> Status2: 0 366 620 1023 767 2
> Status2: 0 386 596 1023 767 2
> Status2: 0 410 568 1023 767 2
> Status2: 0 442 520 1023 767 2
> Path 0: 1431 Path 1: 4 Path 2: 387
> Status2: 0 472 460 1023 767 2
> Status2: 0 488 434 1023 767 2
> Status2: 0 488 432 1023 767 2
> Status2: 0 488 424 1023 767 2
> Status2: 0 497 413 1023 767 2
> Status2: 0 503 400 1023 767 2
> Status2: 0 504 399 1023 767 2
> Status2: 0 505 396 1023 767 2
> Status2: 0 506 395 639 479 2
> Path 0: 1453 Path 1: 4 Path 2: 396
> Status2: 0 507 395 639 479 2
> Path 0: 1454 Path 1: 4 Path 2: 397
> Status2: 0 507 396 639 479 2
> Path 0: 1455 Path 1: 4 Path 2: 398
> 
> 
> 
> 
> With -full-screen:
> 
> Path 0: 1 Path 1: 0 Path 2: 0
> Path 0: 2 Path 1: 0 Path 2: 0
> Path 0: 91 Path 1: 0 Path 2: 0
> Path 0: 145 Path 1: 0 Path 2: 0
> Path 0: 164 Path 1: 0 Path 2: 0
> Path 0: 258 Path 1: 0 Path 2: 0
> Path 0: 347 Path 1: 0 Path 2: 0
> Path 0: 438 Path 1: 0 Path 2: 0
> Path 0: 532 Path 1: 0 Path 2: 0
> Status1: 1 1023 496 1023 767
> Status2: 0 1021 496 1023 767 2
> Path 0: 591 Path 1: 1 Path 2: 1
> Status1: 1 0 488 1023 767
> Status2: 0 8 458 1023 767 2
> Status1: 1 1023 306 1023 767
> Path 0: 637 Path 1: 3 Path 2: 2
> Status2: 0 1015 254 1023 767 2
> Status1: 1 805 0 1023 767
> Status2: 0 405 14 1023 767 2
> Status1: 1 193 767 1023 767
> Path 0: 703 Path 1: 5 Path 2: 4
> Status2: 0 2 747 1023 767 2
> Status1: 1 78 0 1023 767
> Status2: 0 168 2 1023 767 2
> Status1: 1 2 767 1023 767
> Path 0: 748 Path 1: 7 Path 2: 6
> Status2: 0 726 755 1023 767 2
> Status1: 1 1023 515 1023 767
> Status2: 0 10 214 1023 767 2
> Status1: 1 1023 574 1023 767
> Status2: 0 1022 666 1023 767 2
> Status1: 1 0 650 1023 767
> Path 0: 819 Path 1: 10 Path 2: 9
> Status2: 0 1002 8 1023 767 2
> Status1: 1 1023 8 1023 767
> Status2: 0 981 569 1023 767 2
> Status1: 1 0 567 1023 767
> Status2: 0 8 207 1023 767 2
> Status1: 1 1023 219 1023 767
> Status2: 0 983 307 1023 767 2
> Status1: 1 0 359 1023 767
> Status2: 0 8 269 1023 767 2
> Status1: 1 1023 255 1023 767
> Path 0: 903 Path 1: 15 Path 2: 14
> Status2: 0 991 378 1023 767 2
> Status1: 1 0 394 1023 767
> Status2: 0 38 282 1023 767 2
> Status1: 1 1023 270 1023 767
> Status2: 0 993 324 1023 767 2
> Status1: 1 0 370 1023 767
> Status2: 0 26 348 1023 767 2
> Status1: 1 1023 330 1023 767
> Path 0: 974 Path 1: 19 Path 2: 18
> Status2: 0 1005 338 1023 767 2
> Status1: 1 0 386 1023 767
> Status2: 0 10 490 1023 767 2
> Status1: 1 1023 470 1023 767
> 
> 
> 
> (I bounced to the screen border with the cursor several times to make the gui_grab toggle)
> 
> I assume from these results that the gui_grab is never set to 1 when having entered the window in windowed mode with the cursor.
> 
> Maybe that's why the sdl_grab_start() is called so often.
> 
> It seems that the condition in sdl_grab_start() (SDL_WM_GrabInput(SDL_GRAB_ON) == SDL_GRAB_ON) is never fulfilled, otherwise the gui_grab would be set to 1. But the cursor is actually grabbed in windowed mode, otherwise I would not be able to click somewhere with the guest-windows-cursor.
> 
> 
> 
> You should be able to reproduce this issue on your side in the windowed mode.
> 

OK, will try my best. Cannot exclude that there are glitches remaining.

Thanks
Jan

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

Re: [Qemu-devel] git bisect results

[Jan Kiszka]

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

On 2012-01-26 14:10, Erik Rull wrote:
> I assume from these results that the gui_grab is never set to 1 when having 
> entered the window in windowed mode with the cursor.
> 
> Maybe that's why the sdl_grab_start() is called so often.
> 
> It seems that the condition in sdl_grab_start() (SDL_WM_GrabInput(SDL_GRAB_ON) 
> == SDL_GRAB_ON) is never fulfilled, otherwise the gui_grab would be set to 1. 
> But the cursor is actually grabbed in windowed mode, otherwise I would not be 
> able to click somewhere with the guest-windows-cursor.

This might be a SDL limitation which does not show up everywhere. Here
it's fine e.g.

The logic dates back to "Handle SDL grabs failing (Mark McLoughlin)",
6bb816031f. Maybe we can solve that issue without relying on the
obviously unreliable return value. Need to reproduce that one as well,
though.

Jan


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

Re: [Qemu-devel] git bisect results

[Jan Kiszka]

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

On 2012-01-27 23:52, Jan Kiszka wrote:
> On 2012-01-26 14:10, Erik Rull wrote:
>> I assume from these results that the gui_grab is never set to 1 when having 
>> entered the window in windowed mode with the cursor.
>>
>> Maybe that's why the sdl_grab_start() is called so often.
>>
>> It seems that the condition in sdl_grab_start() (SDL_WM_GrabInput(SDL_GRAB_ON) 
>> == SDL_GRAB_ON) is never fulfilled, otherwise the gui_grab would be set to 1. 
>> But the cursor is actually grabbed in windowed mode, otherwise I would not be 
>> able to click somewhere with the guest-windows-cursor.
> 
> This might be a SDL limitation which does not show up everywhere. Here
> it's fine e.g.
> 
> The logic dates back to "Handle SDL grabs failing (Mark McLoughlin)",
> 6bb816031f. Maybe we can solve that issue without relying on the
> obviously unreliable return value. Need to reproduce that one as well,
> though.

Please check if

git://git.kiszka.org/qemu.git queues/sdl

fixes the issue for you. Namely reverting the above commit should do the
trick. I obsoleted that fragile patch in my series.

Thanks,
Jan



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

Re: [Qemu-devel] git bisect results

[Erik Rull]

Jan Kiszka wrote:
> On 2012-01-27 23:52, Jan Kiszka wrote:
>> On 2012-01-26 14:10, Erik Rull wrote:
>>> I assume from these results that the gui_grab is never set to 1 when having
>>> entered the window in windowed mode with the cursor.
>>>
>>> Maybe that's why the sdl_grab_start() is called so often.
>>>
>>> It seems that the condition in sdl_grab_start() (SDL_WM_GrabInput(SDL_GRAB_ON)
>>> == SDL_GRAB_ON) is never fulfilled, otherwise the gui_grab would be set to 1.
>>> But the cursor is actually grabbed in windowed mode, otherwise I would not be
>>> able to click somewhere with the guest-windows-cursor.
>>
>> This might be a SDL limitation which does not show up everywhere. Here
>> it's fine e.g.
>>
>> The logic dates back to "Handle SDL grabs failing (Mark McLoughlin)",
>> 6bb816031f. Maybe we can solve that issue without relying on the
>> obviously unreliable return value. Need to reproduce that one as well,
>> though.
>
> Please check if
>
> git://git.kiszka.org/qemu.git queues/sdl
>
> fixes the issue for you. Namely reverting the above commit should do the
> trick. I obsoleted that fragile patch in my series.
>
> Thanks,
> Jan
>
>

Hi Jan,

I will test this on monday. Can you tell me how I can merge that into my 
cloned main qemu repository? I'm quite new to git.

Thanks.

Best regards,

Erik

Re: [Qemu-devel] git bisect results

[Jan Kiszka]

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

On 2012-01-28 13:39, Erik Rull wrote:
> Jan Kiszka wrote:
>> On 2012-01-27 23:52, Jan Kiszka wrote:
>>> On 2012-01-26 14:10, Erik Rull wrote:
>>>> I assume from these results that the gui_grab is never set to 1 when
>>>> having
>>>> entered the window in windowed mode with the cursor.
>>>>
>>>> Maybe that's why the sdl_grab_start() is called so often.
>>>>
>>>> It seems that the condition in sdl_grab_start()
>>>> (SDL_WM_GrabInput(SDL_GRAB_ON)
>>>> == SDL_GRAB_ON) is never fulfilled, otherwise the gui_grab would be
>>>> set to 1.
>>>> But the cursor is actually grabbed in windowed mode, otherwise I
>>>> would not be
>>>> able to click somewhere with the guest-windows-cursor.
>>>
>>> This might be a SDL limitation which does not show up everywhere. Here
>>> it's fine e.g.
>>>
>>> The logic dates back to "Handle SDL grabs failing (Mark McLoughlin)",
>>> 6bb816031f. Maybe we can solve that issue without relying on the
>>> obviously unreliable return value. Need to reproduce that one as well,
>>> though.
>>
>> Please check if
>>
>> git://git.kiszka.org/qemu.git queues/sdl
>>
>> fixes the issue for you. Namely reverting the above commit should do the
>> trick. I obsoleted that fragile patch in my series.
>>
>> Thanks,
>> Jan
>>
>>
> 
> Hi Jan,
> 
> I will test this on monday. Can you tell me how I can merge that into my
> cloned main qemu repository? I'm quite new to git.

# git remote add kiszka git://git.kiszka.org/qemu.git
# git fetch kiszka
# git checkout kiszka/queues/sdl

That way you will have what I have. Or do you need additional patches
for your tests?

Jan


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

Re: [Qemu-devel] git bisect results

[Erik Rull]

Jan Kiszka wrote:
> On 2012-01-28 13:39, Erik Rull wrote:
>> Jan Kiszka wrote:
>>> On 2012-01-27 23:52, Jan Kiszka wrote:
>>>> On 2012-01-26 14:10, Erik Rull wrote:
>>>>> I assume from these results that the gui_grab is never set to 1 when
>>>>> having
>>>>> entered the window in windowed mode with the cursor.
>>>>>
>>>>> Maybe that's why the sdl_grab_start() is called so often.
>>>>>
>>>>> It seems that the condition in sdl_grab_start()
>>>>> (SDL_WM_GrabInput(SDL_GRAB_ON)
>>>>> == SDL_GRAB_ON) is never fulfilled, otherwise the gui_grab would be
>>>>> set to 1.
>>>>> But the cursor is actually grabbed in windowed mode, otherwise I
>>>>> would not be
>>>>> able to click somewhere with the guest-windows-cursor.
>>>>
>>>> This might be a SDL limitation which does not show up everywhere. Here
>>>> it's fine e.g.
>>>>
>>>> The logic dates back to "Handle SDL grabs failing (Mark McLoughlin)",
>>>> 6bb816031f. Maybe we can solve that issue without relying on the
>>>> obviously unreliable return value. Need to reproduce that one as well,
>>>> though.
>>>
>>> Please check if
>>>
>>> git://git.kiszka.org/qemu.git queues/sdl
>>>
>>> fixes the issue for you. Namely reverting the above commit should do the
>>> trick. I obsoleted that fragile patch in my series.
>>>
>>> Thanks,
>>> Jan
>>>
>>>
>>
>> Hi Jan,
>>
>> I will test this on monday. Can you tell me how I can merge that into my
>> cloned main qemu repository? I'm quite new to git.
>
> # git remote add kiszka git://git.kiszka.org/qemu.git
> # git fetch kiszka
> # git checkout kiszka/queues/sdl
>
> That way you will have what I have. Or do you need additional patches
> for your tests?
>
> Jan
>

No I think this will be sufficient. Will this work if I will add it to the 
qemu-kvm-1.0 tagged version? I have further issues when using the current 
master because this version does not boot up Windows XP at the moment. I 
was not able to bisect up to now where this issue was added.

Best regards,

Erik

Re: [Qemu-devel] git bisect results

[Jan Kiszka]

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

On 2012-01-28 14:01, Erik Rull wrote:
> Jan Kiszka wrote:
>> On 2012-01-28 13:39, Erik Rull wrote:
>>> Jan Kiszka wrote:
>>>> On 2012-01-27 23:52, Jan Kiszka wrote:
>>>>> On 2012-01-26 14:10, Erik Rull wrote:
>>>>>> I assume from these results that the gui_grab is never set to 1 when
>>>>>> having
>>>>>> entered the window in windowed mode with the cursor.
>>>>>>
>>>>>> Maybe that's why the sdl_grab_start() is called so often.
>>>>>>
>>>>>> It seems that the condition in sdl_grab_start()
>>>>>> (SDL_WM_GrabInput(SDL_GRAB_ON)
>>>>>> == SDL_GRAB_ON) is never fulfilled, otherwise the gui_grab would be
>>>>>> set to 1.
>>>>>> But the cursor is actually grabbed in windowed mode, otherwise I
>>>>>> would not be
>>>>>> able to click somewhere with the guest-windows-cursor.
>>>>>
>>>>> This might be a SDL limitation which does not show up everywhere. Here
>>>>> it's fine e.g.
>>>>>
>>>>> The logic dates back to "Handle SDL grabs failing (Mark McLoughlin)",
>>>>> 6bb816031f. Maybe we can solve that issue without relying on the
>>>>> obviously unreliable return value. Need to reproduce that one as well,
>>>>> though.
>>>>
>>>> Please check if
>>>>
>>>> git://git.kiszka.org/qemu.git queues/sdl
>>>>
>>>> fixes the issue for you. Namely reverting the above commit should do
>>>> the
>>>> trick. I obsoleted that fragile patch in my series.
>>>>
>>>> Thanks,
>>>> Jan
>>>>
>>>>
>>>
>>> Hi Jan,
>>>
>>> I will test this on monday. Can you tell me how I can merge that into my
>>> cloned main qemu repository? I'm quite new to git.
>>
>> # git remote add kiszka git://git.kiszka.org/qemu.git
>> # git fetch kiszka
>> # git checkout kiszka/queues/sdl
>>
>> That way you will have what I have. Or do you need additional patches
>> for your tests?
>>
>> Jan
>>
> 
> No I think this will be sufficient. Will this work if I will add it to
> the qemu-kvm-1.0 tagged version?

For your test, you can focus on applying

http://git.kiszka.org/?p=qemu.git;a=commitdiff;h=0109c860ca59fddbecb47651be3cbf5135d8e82e

on the target branch.

> I have further issues when using the
> current master because this version does not boot up Windows XP at the
> moment. I was not able to bisect up to now where this issue was added.

Hmm, works here. Which command line?

Jan


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

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