Bug 496106 - OpenOffice.org does not render its menus properly
OpenOffice.org does not render its menus properly
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-intel (Show other bugs)
11
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Jonathan Blandford
Fedora Extras Quality Assurance
card_945GM
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-04-16 12:54 EDT by Tom "spot" Callaway
Modified: 2013-04-02 00:22 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-11-07 19:20:15 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Screenshot of broken oocalc (26.32 KB, image/png)
2009-04-16 12:55 EDT, Tom "spot" Callaway
no flags Details
Xorg.0.log from dual screen X on Intel 945GM with KMS enabled (92.58 KB, text/plain)
2009-05-05 08:51 EDT, Tom "spot" Callaway
no flags Details

  None (edit)
Description Tom "spot" Callaway 2009-04-16 12:54:52 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?
Comment 1 Tom "spot" Callaway 2009-04-16 12:55:35 EDT
Created attachment 339873 [details]
Screenshot of broken oocalc
Comment 2 Caolan McNamara 2009-04-16 15:28:55 EDT
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 ?
Comment 3 Tom "spot" Callaway 2009-04-16 15:36:02 EDT
Nope. No combination of changing the theme and exporting SAL_GTK_USE_PIXMAPPAINT make any difference.
Comment 4 Caolan McNamara 2009-04-16 16:04:07 EDT
gimme
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...
export SAL_DISABLE_CAIROTEXT=1

C.
Comment 5 Tom "spot" Callaway 2009-04-16 16:27:44 EDT
[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. :/
Comment 6 Caolan McNamara 2009-04-16 18:38:45 EDT
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 ?
Comment 7 David Tardon 2009-04-17 04:17:04 EDT
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.
Comment 8 David Tardon 2009-04-17 04:45:41 EDT
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...
Comment 9 Tom "spot" Callaway 2009-04-17 09:52:17 EDT
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?
Comment 10 Adam Jackson 2009-04-23 16:04:22 EDT
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.
Comment 11 Caolan McNamara 2009-05-01 07:49:59 EDT
caolanm->ajax: Is there any way for spot to verify that this is or isn't a Render issue vs an OOo one ?
Comment 12 Tom "spot" Callaway 2009-05-02 14:43:08 EDT
(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.
Comment 13 Matěj Cepl 2009-05-04 10:56:10 EDT
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.
Comment 14 Tom "spot" Callaway 2009-05-04 12:23:28 EDT
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.
Comment 15 Tom "spot" Callaway 2009-05-05 08:51:32 EDT
Created attachment 342452 [details]
Xorg.0.log from dual screen X on Intel 945GM with KMS enabled
Comment 16 Matěj Cepl 2009-05-05 13:24:23 EDT

*** This bug has been marked as a duplicate of bug 495323 ***
Comment 17 Kristian Høgsberg 2009-05-28 09:31:42 EDT
Not a duplicate.
Comment 18 Tom "spot" Callaway 2009-05-28 09:44:09 EDT
Kristian, if you want to see this in action, feel free to come by my desk.
Comment 19 Bug Zapper 2009-06-09 09:56:41 EDT
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:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 20 Adam Hough 2009-06-22 16:35:14 EDT
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.
Comment 22 Matěj Cepl 2009-11-05 13:26:34 EST
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.]
Comment 23 Tom "spot" Callaway 2009-11-05 14:22:06 EST
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.
Comment 24 Matěj Cepl 2009-11-07 19:20:15 EST
Hmm, so that's either INSUFFICIENT_DATA or CURRENTRELEASE.

Thank you for letting us know.

Note You need to log in before you can comment on or make changes to this bug.