Red Hat Bugzilla – Bug 496106
OpenOffice.org does not render its menus properly
Last modified: 2018-05-03 02:15:16 EDT
Description of problem:
With the latest rawhide, none of the OpenOffice.org applications are rendering their menus properly, rendering them entirely unusable. I have not seen this issue in any other applications, just OOo.
I'm attaching a screenshot to illustrate the problem.
Version of OOo is 3.1.0-9.2.fc11.x86_64.
The only unique thing about my setup is that I am using two monitors with Kernel Modesetting, vertically stacked on top of each other. One monitor is my laptop panel, the other is a widescreen LCD. Both are running at 1680x1050, for a combined desktop of 1680x2100. Maybe openoffice.org is doing something that is triggering an X bug?
Created attachment 339873 [details]
Screenshot of broken oocalc
Look totally f*cked, (and not what I see here of course) does changing your theme and/or using export SAL_GTK_USE_PIXMAPPAINT=true beforehand make any difference ?
Nope. No combination of changing the theme and exporting SAL_GTK_USE_PIXMAPPAINT make any difference.
grep "drivers" /var/log/Xorg.0.log
grep "pixmap format" /var/log/Xorg.0.log >> $filename
We're getting neither text nor graphics, perhaps clipping has gone mad. Just to check if its one type of clipping error, try...
[spot@velociraptor devel]$ grep "drivers" /var/log/Xorg.0.log
(II) Loading /usr/lib64/xorg/modules/drivers//intel_drv.so
(II) Loading /usr/lib64/xorg/modules/drivers//vesa_drv.so
(II) Loading /usr/lib64/xorg/modules/drivers//fbdev_drv.so
(II) Unloading /usr/lib64/xorg/modules/drivers//vesa_drv.so
(II) Unloading /usr/lib64/xorg/modules/drivers//fbdev_drv.so
[spot@velociraptor devel]$ grep "pixmap format" /var/log/Xorg.0.log
(==) Depth 24 pixmap format is 32 bpp
SAL_DISABLE_CAIROTEXT=1 doesn't change anything. :/
Closest I can get is to make a rawhide i386 intel X driver do 1920x2000 with lcd and flatpanel stacked vertically, with no artifacts. It'd be nice if we could rule the multiple-monitor thing in or out with a single monitor setup
caolanm->dtardon: you able to test F-11 with OOo on dual head x86_64 ?
dtardon->caolanm: No problem here, but I cannot try it with Kernel Modesetting--it still doesn't work with my ATI.
dtardon->tcallawa: Could you try it with monitors set up in mirror mode (System->Preferences->Display, switch "Mirror screens" on)? This should be enough to ensure it is/isn't a multihead issue.
I tried it with Kernel Modesetting on in mirror mode (and in non-mirror mode with vertically stacked screens, which works in a way). Still, no problem with fonts...
Well, I can do it one better. I worked from home today, so I don't have the second screen connected. On a fresh boot with the single panel (laptop), the OpenOffice apps render properly, so it seems to be limited to my dual screen case.
I wonder if this isn't a byproduct of my screensize going over the old 2048 limit (2100 vertical). Adam?
I suspect that it is, yes. The 3d engine craps out on surfaces wider than 2k, and Render uses the 3d engine. Might just not be checking aggressively enough for the pitch limit.
caolanm->ajax: Is there any way for spot to verify that this is or isn't a Render issue vs an OOo one ?
(In reply to comment #11)
> caolanm->ajax: Is there any way for spot to verify that this is or isn't a
> Render issue vs an OOo one ?
Well, I'm not ajax, but I think I have conclusively verified that it is a render issue. When I change the Desktops to "Mirrored" rather than a single screen spread across the two monitors, then open OpenOffice.org, it renders properly. Keeping that OOo instance open, when I change the Desktops to the single screen spread across the two monitors, the OOo instance immediately shows the corruption. Flipping back and forth between these settings alternately restores and corrupts the OOo app display.
In addition, there is another bug with the two screen configuration where it hardlocks before finishing setting the background or loading the GNOME panels in runlevel 5 (if I take it to runlevel 3 and startx, it works), so I am very suspicious that there are serious problems in the Intel X driver code.
Thanks for the bug report. We have reviewed the information you have provided above, and there is some additional information we require that will be helpful in our diagnosis of this issue.
Please attach your X server config file (/etc/X11/xorg.conf, if available) and X server log file (/var/log/Xorg.*.log) to the bug report as individual uncompressed file attachments using the bugzilla file attachment link below.
We will review this issue again once you've had a chance to attach this information.
Thanks in advance.
There is no xorg.conf, but I will send along the Xorg.0.log when I'm back in the office (and on the dual monitor configuration) tomorrow.
Created attachment 342452 [details]
Xorg.0.log from dual screen X on Intel 945GM with KMS enabled
*** This bug has been marked as a duplicate of bug 495323 ***
Not a duplicate.
Kristian, if you want to see this in action, feel free to come by my desk.
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.
More information and reason for this action is here:
Okay I am having the same issue on my Lenovo T60 (Intel video). To use dual monitors with this laptop, I use to have to have the screens in a vertical orientation. of the screen. I have gotten use tot hat configuration and so left it after I upgraded to Fedora 11.
Openoffice will not load any of its text or symbols correctly if the screens are in a vertical orientation to each other. However if I turn one fo the screen off or put them in a horizontal orientation then Openoffice will work just fine.
I setup dual monitors using a script that runs when I login to the system that looks for a second monitor and then sets up the displays. The script is just calling xrandr and then using information from xrandr to setup the monitors. Though this problem happens whether I use that script or not.
Since this bugzilla report was filed, there have been several major updates in various components of the Xorg system, which may have resolved this issue. Users who have experienced this problem are encouraged to upgrade their system to the latest version of their packages. For packages from updates-testing repository you can use command
yum upgrade --enablerepo='*-updates-testing'
Alternatively, you can also try to test whether this bug is reproducible with the upcoming Fedora 12 distribution by downloading LiveMedia of F12 Beta available at http://alt.fedoraproject.org/pub/alt/nightly-composes/ . By using that you get all the latest packages without need to install anything on your computer. For more information on using LiveMedia take a look at https://fedoraproject.org/wiki/FedoraLiveCD .
Please, if you experience this problem on the up-to-date system, let us now in the comment for this bug, or whether the upgraded system works for you.
If you won't be able to reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you.
[This is a bulk message for all open Fedora Rawhide Xorg-related bugs. I'm adding myself to the CC list for each bug, so I'll see any comments you make after this and do my best to make sure every issue gets proper attention.]
This bug was still present the last time I booted that laptop, but it has not been tested recently. I've since upgraded hardware to a laptop that uses a newer intel graphics chip, and I have not seen this failure on that hardware.
Hmm, so that's either INSUFFICIENT_DATA or CURRENTRELEASE.
Thank you for letting us know.