From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040626 Firefox/0.9.1 Description of problem: 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. Discussion: 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. Solution: Add 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): xorg-x11-6.7.0-2 How reproducible: Always 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. Additional info: I did a fresh install of Fedora 2, and I have all available updates installed.
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 be investigated. 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 internally. 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.
Mike, OOo does _not_ rely on the contents of the config file. The upstream developer says: "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.
Mike, 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 effect of // this is _very_ noticable lag when drawing menus. The file menu, for example, // 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 change anything. Can you strace/ltrace to see what's happening for both cases and compare? That might point us in the right direction. TIA
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 the default. 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.