1906 2012-01-16 21:08:10 +0000 [QEMU]loses focus in qemux86-64 terminal When I press key [CTRL+L] 2012-05-08 08:15:38 +0000 1 1 7 Build System, Metadata & Runtime OE-Core core 1.2 x86 x86_64 VERIFIED FIXED Patch our for review on mailing list Medium normal 1.2.1 1 ningx.ma edwin.zhai jessica.zhang jiajun.xu meta.mr.watcher meta.watcher nitin.a.kamble raj.khem richard.purdie scott.a.garman yilongx.y.sun --- --- --- oldest_to_newest 18172 0 ningx.ma 2012-01-16 21:08:10 +0000 Tree/Branch: Poky/1.2_M2 Commit: 0f4d99d207b224bb9ce23de00a48f795ae20b3a0 with 20120111-3 images for qemux86-64, boot system successful and then launch the Terminal, loses focus When I press key [CTRL+L] or set the cursor on the bottom of the terminal and press [ENTER] key. This problem does not exist with qemux86 image. 20120111-3 qemux86-64 image URL: http://autobuilder.yoctoproject.org/pub/nightly/20120113-1/machines/qemu/qemux86-64/ 18484 1 edwin.zhai 2012-02-05 17:55:22 +0000 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? 18486 2 yilongx.y.sun 2012-02-05 18:37:52 +0000 In this case, the cursor will disappear, you can't type command in this terminal. 18684 3 edwin.zhai 2012-02-21 22:39:57 +0000 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. 19687 4 ningx.ma 2012-03-30 07:56:57 +0000 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/ 20680 5 richard.purdie 2012-04-18 20:53:21 +0000 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, 20681 6 richard.purdie 2012-04-18 20:58:58 +0000 Just to make this clearer, the definition of CLAMP: #define CLAMP(x, low, high) (((x) > (high)) ? (high) : (((x) < (low)) ? (low) : (x))) 20682 7 raj.khem 2012-04-18 21:29:35 +0000 what happens of you change gdouble oval = value->data[0].v_double; to volatile gdouble oval = value->data[0].v_double; in that function 20683 8 nitin.a.kamble 2012-04-18 21:45:08 +0000 also changing the CLAMP statement as follows will make compiler's work simpler. value->data[0].v_double = CLAMP (oval, dspec->minimum, dspec->maximum); 20687 9 richard.purdie 2012-04-18 22:54:14 +0000 (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. 20688 10 richard.purdie 2012-04-18 22:59:46 +0000 (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 20692 11 raj.khem 2012-04-19 01:12:05 +0000 (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. 20703 12 raj.khem 2012-04-19 06:20:22 +0000 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> 20708 13 richard.purdie 2012-04-19 07:35:03 +0000 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. 20980 14 richard.purdie 2012-05-02 14:04:11 +0000 Fixed in http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=a4d913d925ce7fcd6d18ee68e4cd6741b4c3eb7c 21170 15 yilongx.y.sun 2012-05-08 08:15:38 +0000 This issue is fixed and verified. Tree/Branch: Poky/master Commit: 38da655788361e949d605bebfab45cf5830df613