Bug 1906

What do you mean by "lose focus"? Can you gain the focus again? What focus? focus for windows in side qemu? Can you see "Press Ctrl-Alt to exit mouse grab" in qemu title bar?

In this case, the cursor will disappear, you can't type command in this terminal.

This bug is caused by the broken scrollbar in vte. The culprit is:

commit 6eadb8494797e44910b86b5e101823cf527c04e1
Author: Kristian Høgsberg <krh@bitplanet.net>
Date:   Thu Jul 15 09:07:51 2010 -0400

    Use accessors for setting adjustment
    
    We use g_object_freeze_notify() to emit the same amount of ::changed
    signals.

It seems that "changed" signal was not emitted with the new method. But don't know the root cause. I have created a bug in gnome's bugzilla and send out a patch to revert this commit to poky master.

This issue still exist in poky 1.2_M4 testing.

Tree/Branch: Poky/1.2_M4
Poky Commit id:4d9f4d6ac25f39fe6d5491d05c7a26195bab648b

20120328-1 qemux86-64 image URL:
http://autobuilder.yoctoproject.org/pub/nightly/20120328-1/machines/qemu/qemux86-64/

This is a compiler optimization problem showing itself up in glib. If I change gparamspecs.c to read:


static gboolean
param_double_validate (GParamSpec *pspec,
		       GValue     *value)
{
  GParamSpecDouble *dspec = G_PARAM_SPEC_DOUBLE (pspec);
  gdouble oval = value->data[0].v_double;
  
  value->data[0].v_double = CLAMP (value->data[0].v_double, dspec->minimum, dspec->maximum);

  printf("Here %f %f %f %f\n", value->data[0].v_double, oval, dspec->minimum, dspec->maximum);
  
  return value->data[0].v_double != oval;
}

then I see things like:

Here -179769313486231570814527423731704356798070567525844996598917476803157260780028538760589558632766878171540458953514382464234321326889464182768467546703537516986049910576551282076245490090389328944075868508455133942304583236903222948165808559332123348274797826204144723168738177180919299881250404026184124858368.000000 30.000000 -179769313486231570814527423731704356798070567525844996598917476803157260780028538760589558632766878171540458953514382464234321326889464182768467546703537516986049910576551282076245490090389328944075868508455133942304583236903222948165808559332123348274797826204144723168738177180919299881250404026184124858368.000000 179769313486231570814527423731704356798070567525844996598917476803157260780028538760589558632766878171540458953514382464234321326889464182768467546703537516986049910576551282076245490090389328944075868508455133942304583236903222948165808559332123348274797826204144723168738177180919299881250404026184124858368.000000

so its taking the value of dspec->minimum which is clearly lower than 30.

If I change it to:

static gboolean
param_double_validate (GParamSpec *pspec,
		       GValue     *value)
{
  GParamSpecDouble *dspec = G_PARAM_SPEC_DOUBLE (pspec);
  gdouble oval = value->data[0].v_double;
  
  value->data[0].v_double = CLAMP (value->data[0].v_double, dspec->minimum, dspec->maximum);

  if (oval < dspec->minimum)
      printf("Here 1 %f %f %f %f\n", value->data[0].v_double, oval, dspec->minimum, dspec->maximum);
  else
      printf("Here 2 %f %f %f %f\n", value->data[0].v_double, oval, dspec->minimum, dspec->maximum);
  
  return value->data[0].v_double != oval;
}

then I see:

Here 2 30.000000 30.000000 -179769313486231570814527423731704356798070567525844996598917476803157260780028538760589558632766878171540458953514382464234321326889464182768467546703537516986049910576551282076245490090389328944075868508455133942304583236903222948165808559332123348274797826204144723168738177180919299881250404026184124858368.000000 179769313486231570814527423731704356798070567525844996598917476803157260780028538760589558632766878171540458953514382464234321326889464182768467546703537516986049910576551282076245490090389328944075868508455133942304583236903222948165808559332123348274797826204144723168738177180919299881250404026184124858368.000000

and as an added bonus the issue reported in this bug goes away as the parameters used by the gtkadjustment start working. Exactly what the issue is remains to be seen but this looks like the right place to start looking for the problem,

Just to make this clearer, the definition of CLAMP:

#define CLAMP(x, low, high)  (((x) > (high)) ? (high) : (((x) < (low)) ? (low) : (x)))

what happens of you change

gdouble oval = value->data[0].v_double;

to 

volatile gdouble oval = value->data[0].v_double;

in that function

also changing the CLAMP statement as follows will make compiler's work simpler.

value->data[0].v_double = CLAMP (oval, dspec->minimum,
dspec->maximum);

(In reply to comment #7)
> what happens of you change
> 
> gdouble oval = value->data[0].v_double;
> 
> to 
> 
> volatile gdouble oval = value->data[0].v_double;
> 
> in that function

It doesn't help, things still break.

(In reply to comment #8)
> also changing the CLAMP statement as follows will make compiler's work simpler.
> 
> value->data[0].v_double = CLAMP (oval, dspec->minimum,
> dspec->maximum);

This helps only if oval is also marked as volatile

(In reply to comment #9)
> (In reply to comment #7)
> > what happens of you change
> > 
> > gdouble oval = value->data[0].v_double;
> > 
> > to 
> > 
> > volatile gdouble oval = value->data[0].v_double;
> > 
> > in that function
> 
> It doesn't help, things still break.

hmmm interesting I wonder if we are looking at right place. Can you post preprocessed file somewhere ?
(In reply to comment #9)
> (In reply to comment #7)
> > what happens of you change
> > 
> > gdouble oval = value->data[0].v_double;
> > 
> > to 
> > 
> > volatile gdouble oval = value->data[0].v_double;
> > 
> > in that function
> 
> It doesn't help, things still break.

OK then my next question would be does it happen on real hardware ?
just to get qemu out of being an issue here
I will look at the gcc output once I get the preprocessed
file.

I looked at the disassembly of both with and without printf addition. One difference I saw is that in case when if else printf code is not there
optimizer finds a usecase for maxsd instruction and AFAICT code is correct
 
      movsd   8(%rsi), %xmm1
        movsd   80(%rdi), %xmm0
        ucomisd %xmm0, %xmm1
        ja      .L82
        movsd   72(%rdi), %xmm0
        maxsd   %xmm1, %xmm0
.L82:
        xorl    %edx, %edx
        movl    $1, %eax
        movsd   %xmm0, 8(%rsi)
        ucomisd %xmm1, %xmm0
        setp    %dl
        cmove   %edx, %eax
        ret




so I tried to see if qemu is emulating maxsd correctly
groking though the qemu sources I found an interesting commit which explained the problem clearly to me. So please backport the below patch into qemu
and retry


http://git.qemu.org/?p=qemu.git;a=commitdiff;h=a4d1f142542935b90d2eb30f3aead4edcf455fe6;hp=9841aee16f1e68f5a9063589c898c40b44473add


here is the detailed log message

commit a4d1f142542935b90d2eb30f3aead4edcf455fe6
Author: Aurelien Jarno <aurelien@aurel32.net>
Date:   Sat Jan 7 15:20:11 2012 +0100

    target-i386: fix {min,max}{pd,ps,sd,ss} SSE2 instructions
    
    minpd, minps, minsd, minss and maxpd, maxps, maxsd, maxss SSE2
    instructions have been broken when switching target-i386 to softfloat.
    It's not possible to use comparison instructions on float types anymore
    to softfloat, so use the floatXX_lt function instead, as the
    float_XX_min and float_XX_max functions can't be used due to the Intel
    specific behaviour.
    
    As it implements the correct NaNs behaviour, let's remove the
    corresponding entry from the TODO.
    
    It fixes GDM screen display on Debian Lenny.
    
    Thanks to Peter Maydell and Jason Wessel for their analysis of the
    problem.
    
    Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>

Nice catch Khem, that does indeed solve the problem (and at least one other issue, files not being displayed in pcmanfm)! :)

I'll send out a patch for this.

Fixed in http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=a4d913d925ce7fcd6d18ee68e4cd6741b4c3eb7c

This issue is fixed and verified.

Tree/Branch: Poky/master
Commit: 38da655788361e949d605bebfab45cf5830df613