This is not a drakconf bug...

Source RPM: drakconf-13.10-1-mga6 => x11-driver-video-intel, gtk+3.0
Assignee: mageiatools => bugsquad
Summary: MCC has empty right panel with invisible tools, for any tool group that's chosen on the left., on old laptop with intel Gfx => MCC has empty right panel with invisible tools on old laptop with intel i855 (unless 'option "DRI" "false"' is set)
CC: (none) => thierry.vignaud

I experienced a problem like that, but on a VirtualBox VM based on x86_64 installation

CC: (none) => anaselli

BTW anyone cares to add a screenshot?
The issue is that gtksocket & gtkplug aren't really supported anymore by gtk+ devs, despite being widely used (mcc, xfce, ...)
See also bug #11969 where the embedded content was all black.

Also we'll have an issue with Wayland as gtk+ devs didn't try making gtkplug/socket works on Wayland...

CC: (none) => olav

Created attachment 8849 [details]
no visible starters in right MCC panel

(In reply to Thierry Vignaud from comment #3)
> BTW anyone cares to add a screenshot?

Attaching now :-)

Though the later could probably solved by using "GDK_BACKEND=x11"..?
By any chances, were the reporters using wayland?

(In reply to Thierry Vignaud from comment #5)
> Though the later could probably solved by using "GDK_BACKEND=x11"..?
> By any chances, were the reporters using wayland?

Not me, not even when I saw it on Gnome. I only managed to start Gnome once on that hardware, using "GNOME on Xorg" (and the 32bit Live Gnome iso that Martin uploaded last Friday)

I'm not sure this is the right place to add my comment but I'm experiencing this bug too and I'm using x11-driver-video-sis (and not x11-driver-video-intel). But this is a 32 bit install too (Mageia 6). Also, setting the "DRI" option doesn't make any difference here (the MCC right panel is always empty). This started happening before the big May update and is happening now too, after the update. But on a fresh Mageia 6 install (without updating) everything is OK. Maybe this bug is not related to x11-driver-video-intel? I'm just guessing.

CC: (none) => storage

Still valid on Cauldron/Mageia 8?
i.e try 8RC Live ISO very soon released.

CC: (none) => fri

Regarding my previous comment, it seems that in my case the empty MCC was caused by the SSE-enabled gtk stuff that came in starting with Mageia 6.1 (actually between 6 and 6.1) and, since my CPU is old, it lacks the SSE flag. Probably a fix would be to compile gtk without SSE for the 32 bit arch but I don't know if people would agree with that. Also, it seems that my problem isn't related to this bug, I hope I didn't hijack this thread.

Best wishes.

(In reply to Omnio Torr from comment #9)
> Regarding my previous comment, it seems that in my case the empty MCC was
> caused by the SSE-enabled gtk stuff that came in starting with Mageia 6.1
> (actually between 6 and 6.1) and, since my CPU is old, it lacks the SSE
> flag. Probably a fix would be to compile gtk without SSE for the 32 bit arch
> but I don't know if people would agree with that. Also, it seems that my
> problem isn't related to this bug, I hope I didn't hijack this thread.
> 
> Best wishes.

are you sure you hit sse codepath on i586? it should not be enabled on 32bit as the base arch i586 that does require sse support.

we have patched it out in other places to ...

Thomas, hi,

No, I was just guessing because that was a common problem on my hardware but I have good news, I've just tried Mageia 8 rc and MCC seems to work fine, the right panel has now visible tools. Thank you very much.

Yep, we did a deep review of rust 1.37.2|1.37 in 2019 to use only i586 instructions, to avoid bug https://bugs.mageia.org/show_bug.cgi?id=24694, so there shouldn't be any SSE, SSE2 and MMX instructions used by default in i586 arch (except those objects dl-opened on demand once verified such instructions are supported). Instructions allowed are those shown by "gcc -march=i586 -Q --help=target".

If you hit a case, just to be sure, you might try to objdump the binaries involved, seeking for SSE, SSE2 or MMX instructions, using for instance

objdump -d <binaries> | grep movsd

where movsd is one of the SSE instruction set for instance. For instance this command, would check all the libraries:

find /usr/lib -type f -name '*.so.*' -exec sh -c "objdump -d {} | grep -B3 -m1 movsd && rpm -qf {} && echo -e {} \"\n-------\""  \;

and for /usr/bin binaries:

find /usr/bin -type f -exec sh -c "objdump -d {} | grep -B3 -m1 movsd && rpm -qf {} && echo -e {} \"\n-------\""  \;

Indeed I tried on a 32bit installation (it checks only the installed packages, there might be other packages uninstalled to be affected), and here is the result of the above commands (first is shown the package, then the library containing SSE instructions):

librsvg2_2-2.50.3-1.mga8:/usr/lib/librsvg-2.so.2.47.0 
libvpx6-1.9.0-1.mga8:/usr/lib/libvpx.so.6.3.0 
libgfortran5-10.2.1-0.20210130.1.mga8:/usr/lib/libgfortran.so.5.0.0 
libbabl0.1_0-0.1.84-1.mga8:/usr/lib/libbabl-0.1.so.0.183.1 
libswresample3-4.3.1-6.mga8:/usr/lib/libswresample.so.3.7.100 
libgraphene1.0_0-1.10.2-1.mga8:/usr/lib/libgraphene-1.0.so.0.1000.2 
libavfilter7-4.3.1-6.mga8:/usr/lib/libavfilter.so.7.85.100 
libavutil56-4.3.1-6.mga8:/usr/lib/libavutil.so.56.51.100 
libgstreamer-plugins-base1.0_0-1.18.3-1.mga8/usr/lib/libgstaudio-1.0.so.0.1803.0 
libavcodec58-4.3.1-6.mga8:/usr/lib/libavcodec.so.58.91.100 
libqt5core5-5.15.2-4.mga8:/usr/lib/sse2/libQt5Core.so.5.15.2 
libopenal1-1.21.0-1.mga8:/usr/lib/libopenal.so.1.21.0 
libsoxr0-0.1.3-5.mga8:/usr/lib/libsoxr.so.0.1.2
gcc-10.2.1-0.20210130.1.mga8:/usr/bin/lto-dump  (this contain just a call to a function with _sse2_movsd in name)
flac-1.3.3-3.mga8:/usr/bin/flac 

apparently should be normal for ffmpeg libraries, but seems we hit again SSE instructions for librsvg-2.so.2.47.0. Also it's ok for /usr/lib/sse2/libQt5Core.so.5.15.2, because it's in /usr/lib/sse2/, but there are problems for some others which need to be reviewed, including flac, and gfortran. I think we need to review these.

CC: (none) => ghibomgx

Assuming fixed, since the last user here who reported having this issue, used Mageia 6 and we have Mageia 8 now

Status: NEW => RESOLVED
Resolution: (none) => FIXED