Red Hat Bugzilla – Bug 127180
openoffice extremely slow due to missing xkbrules line in xorg.conf
Last modified: 2007-11-30 17:10:45 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7)
Description of problem:
When running Openoffice (openoffice.org-1.1.1-4), everything is
extremely sluggish, and it takes many seconds just to redraw the
window. Completely unusable. This was not the case in Fedora 1.
Surfing for solutions I found
http://qa.openoffice.org/issues/show_bug.cgi?id=6044, and comparing
the /etc/X11/xorg.conf which was generated (by pyx86config, according
to a comment in the file) when installing Fedora 2 with my old
/etc/X11/XF86Config from Fedora 1, I discovered that the "XkbRules"
line from my old config was missing.
Option "XkbRules" "xorg"
to the InputDevice section for Keyboard0, restart X, and shazam!,
openoffice is responsive again!
Future: please fix pyx86config (or whichever program creates the
xorg.conf) to include the XkbRules line!
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Run Xorg without the "XkbRules" line in xorg.conf
2. Start ooffice, open a file, switch windows.
Actual Results: It takes many seconds for openoffice to even redraw
the window, let alone using menus etc.
Expected Results: I expect openoffice to be rather snappy on my 2GHz
Dell Latitude C640 with 512M memory - at least as snappy as in Fedora 1.
I did a fresh install of Fedora 2, and I have all available updates
Potentially fixable in OO.org as well.
Related to #120858, see also how Than fixed that one for KDE.
This sounds like a bug, but it's not a bug in X.Org X11. The
X server config file intentionally does not have an xkbrules
line, and it should not ever have one. In previous releases,
it was placed there for no good reason, and hard coded to
"XFree86". However, now that we are no longer using XFree86,
having it in the config file breaks the X server because X.Org's
xkbrules file is named "xorg". Any application that explicitly
relies on a specific xkbrules rules file is broken and needs to
be fixed, or else it wont ever work with anything but XFree86
correctly (since it hard codes XFree86).
The correct xkbrules file, is "xorg", which is what the X server
defaults to, so no configuration is necessary. Putting anything
else into the X server config file will actually break every
XKB using application that looks at the rules file.
I'm assuming since this bug is filed concerning a problem in
openoffice, that it is possibly an openoffice bug which should
Reassigning to the openoffice component.
The "main" bug is surely in openoffice.org, but since the workaround
is to simply add the line
Option "XkbRules" "xorg"
(NOTE "xorg"), it may also be a bug in xorg? Unless openoffice.org
really looks at the X config explicitly? Otherwise it seems like the
line really has some observable effect, although it should, as you
write, be the default?
Which component you assign it to doesn't matter to me, as long as the
problem is fixed. It's a real show stopper for Openoffice.
No application should ever touch the X server config file for any
purpose except the X server config tool and the X server. If
an application is parsing the X server config file to try and find
out how the server is configured, I would consider that a very
seriously broken application. I do not know if openoffice is
actually doing such, but it definitely should not be doing so.
The X server defaults to the XkbRules file "xorg" so there is no
reason to put it in the config file by default. A major number
of the Xkbrules related bug reports we have been receiving for
Fedora Core 2 are actually the result of our config tool previously
putting the Option "xkbrules" line in the X server config when
it shouldn't have as it was never needed.
We've intentionally changed the config tool to not put redundant
lines in the config file in order to future-proof things. Since
the XkbRules filename will be changing again in the very near
future, hard coding "xorg" in the config file will just cause
people to experience the same problems again in 6-12 months time.
>Which component you assign it to doesn't matter to me, as long as the
>problem is fixed. It's a real show stopper for Openoffice.
I agree with you 100%, that we need to fix the real problem.
Openoffice should not rely on the contents of the X server config
file, and it shouldn't hard code a particular xkbrules filename
Dan: If you can track down the problem here, I'd be happy to help
try and find a solution that gets openoffice working for everyone
in a clean way. Just let me know how I can help.
Thanks again for the report.
OOo does _not_ rely on the contents of the config file. The upstream
"OOo tries to get the real keyboard name (that is e.g. "Ctrl" on an
english keyboard, "Strg" on a german one) for a key, so it can print
them as the accelarator key in a menu. The XKB extension is used to
achieve this. If the keyboard configuration is broken it should be fixed."
So if you have xkb issues, and xkbcomp has problems, OOo might have
problems too. His solution was to only have it fail the first time,
and not retry after that. That was merged back for 1.1 last year
though, so I'm unsure what's going on here exactly.
Note that for Mac OS X, we had this problem:
// XDarwin doesn't yet have very good support for the Xkeyboard extension.
// When we call XkbGetKeyboard(), the XServer throws a message up in the
// console about xkbcomp and files for geometry include. The side
// this is _very_ noticable lag when drawing menus. The file menu,
// takes about 1s to come down on my G4/450 DP and you can see it draw.
Ok, thats good, however... If openoffice menus are slow when
"xorg" is the XkbRules file, but isn't slow when "xfree86" is the
rules file by making symlinks between the two, it stands to reason
that it is an openoffice keyboard handling bug of some kind because
the files on the X server side would be identical in both cases,
so shouldn't show any behaviorial differences.
I agree that if the keyboard configuration is broken, it should
be fixed, but changing the X.Org server to use the XFree86 xkbrules
file by making a symlink to the xorg file (thus not actually changing
anything in the file) is not the correct solution. It doesn't
Can you strace/ltrace to see what's happening for both cases and
compare? That might point us in the right direction.
Minor clarification: on my machine (x86, not Mac), openoffice is
extremely slow when there is *no XkbRules line* in xorg.conf, but
quite OK with the "xorg" variant of the XkbRules line. So it doesn't
seem to be related to the "xfree86" situation.
I'll see if I find time to strace/ltrace, but I'm on vacation and
don't have much time for hacking. If someone else does it I'd be happy.
That doesn't make much sense however, because the X server defaults
to an Xkbrules file "xorg". Specifying the option in the config
file as "xorg" should have no visible effect, as it's already
Running "xprop |grep XKB" in both cases should result in the
same output. Could you test that?
Bjorn, can you run "xprop | grep XKB" when there is _no_ XkbRules line
and report what it says?
Indeed "xprop -root | grep XKB" gives the same result with the
original xorg.conf and the one with my added XkbRules line:
_XKB_RULES_NAMES(STRING) = "xorg", "pc105", "us", "", ""
And strangely, ooffice isn't slow anymore with the original file. I
feel silly, but I'm quite sure that fix was all I did to stop its
slowness, originally. I've no idea what else may have changed between
then and now. I could possibly try with a virgin system and see if I
can repeat the behaviour - unless you have already verified the behaviour?
somebody please test this with 1.1.2-5 in rawhide.
Is this still an issue ? No reproducibility info since Sep last year so I'll
hazard that its gone. Someone can reopen if they can still reproduce this,
especially with >= 1.9.83.