The below commit causes icons to never show up. This not a duplicate of 1082, but new behavior due to the below commit. At this point, I've narrowed down the problem to the recipes-sato/matchbox-desktop part(s) of the commit. Reverting the commit causes the icons to reappear. > This '100%' loss of icon is due to the below commit. Reverting it should bring > back the icons. > > commit d39c6738df4b7e8ef22f2a7154274c1d08b1d51f > Author: Zhai Edwin <edwin.zhai@intel.com> > Date: Mon Sep 26 19:55:47 2011 +0800 > > matchbox: Upgrade SRCREV to reflect recent accpeted patches by upstream > > (From OE-Core rev: 33a1a05ef988c69f8ff8e38c6723922082e5d1aa) In other words, this isn't the same bug, though it has a similar but more sever e symptom. A separate new bug should be opened for it
Duplicate *** This bug has been marked as a duplicate of bug 1587 ***
(In reply to comment #1) > Duplicate > > *** This bug has been marked as a duplicate of bug 1587 *** Marking this as a duplicate doesn't seem correct. Please expand on why.
(In reply to comment #2) > (In reply to comment #1) > > Duplicate > > > > *** This bug has been marked as a duplicate of bug 1587 *** > > Marking this as a duplicate doesn't seem correct. Please expand on why. Agree with Tom, they are different bugs. 1687 exists for a long time in a random way, while 1689 comes recently after a new patch in upstream. We can't verify 1687 until fix 1689.
The blank screen of matchbox-desktop comes from wrong parameter of "_NET_WORKAREA" create_desktop => x_monitor_workarea => net_workarea_changed, which will: 1. get the _NET_WORKAREA atom via XGetWindowProperty 2. use these 4 parameters to call workarea_changed for screen refresh later The good parameter should be 0,0,640,432(on qemux86), but we get something like 0,640,0,0. This atom is set by matchbox-window-manager: wm_init_existing => ewmh_update_rects, which will: 1. get the right parameters 2. set the atom via XChangeProperty The issue is we get right parameter as 0,0,640,432, but XChangeProperty always set something like 0,640.... Root cause is the parameter parsing, doc of XChangeProperty said "If the specified format is 32, the property data must be a long array". But CARD32 is used instead of long. So 0,0,640,432 is parsed by libX11 as 0|0, 640|432. Patch will be out soon.
*** Bug 1687 has been marked as a duplicate of this bug. ***
(In reply to comment #3) > (In reply to comment #2) > > (In reply to comment #1) > > > Duplicate > > > > > > *** This bug has been marked as a duplicate of bug 1587 *** > > > > Marking this as a duplicate doesn't seem correct. Please expand on why. > > Agree with Tom, they are different bugs. 1687 exists for a long time in a > random way, while 1689 comes recently after a new patch in upstream. We can't > verify 1687 until fix 1689. 1687 & 1689 should be duplicated bugs. 1082 is the long time bug that depends on 1689.
When update SRCREV for matchbox-desktop, one patch to fix bug 658 is taken place of by a new one. But this old fix (http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=a4c6bcb895cb7888b5045ed76f96f056acd7b4ab) can serve as one work around for bug 1689, so removing it expose this hidden bug.
Got fixed @ http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=40fe6457d5ca49fe113bc26c60d5add59d85b34f