Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.

Bug 496106

Summary: OpenOffice.org does not render its menus properly
Product: [Fedora] Fedora Reporter: Tom "spot" Callaway <tcallawa>
Component: xorg-x11-drv-intelAssignee: Jonathan Blandford <jrb>
Status: CLOSED INSUFFICIENT_DATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 11CC: ajax, caolanm, ddumas, dtardon, mcepl, mcepl, scottt.tw, xgl-maint
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard: card_945GM
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-11-08 00:20:15 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Screenshot of broken oocalc
none
Xorg.0.log from dual screen X on Intel 945GM with KMS enabled none

Description Tom "spot" Callaway 2009-04-16 16:54:52 UTC
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 16:55:35 UTC
Created attachment 339873 [details]
Screenshot of broken oocalc

Comment 2 Caolan McNamara 2009-04-16 19:28:55 UTC
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 19:36:02 UTC
Nope. No combination of changing the theme and exporting SAL_GTK_USE_PIXMAPPAINT make any difference.

Comment 4 Caolan McNamara 2009-04-16 20:04:07 UTC
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 20:27:44 UTC
[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 22:38:45 UTC
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 08:17:04 UTC
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 08:45:41 UTC
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 13:52:17 UTC
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 20:04:22 UTC
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 11:49:59 UTC
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 18:43:08 UTC
(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 14:56:10 UTC
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 16:23:28 UTC
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 12:51:32 UTC
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 17:24:23 UTC

*** This bug has been marked as a duplicate of bug 495323 ***

Comment 17 Kristian Høgsberg 2009-05-28 13:31:42 UTC
Not a duplicate.

Comment 18 Tom "spot" Callaway 2009-05-28 13:44:09 UTC
Kristian, if you want to see this in action, feel free to come by my desk.

Comment 19 Bug Zapper 2009-06-09 13:56:41 UTC
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 20:35:14 UTC
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 18:26:34 UTC
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 19:22:06 UTC
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-08 00:20:15 UTC
Hmm, so that's either INSUFFICIENT_DATA or CURRENTRELEASE.

Thank you for letting us know.