Bug 18842 - Very strange behavior related to keyboard when not using a config, but fixed when a blank xorg.conf exists
Summary: Very strange behavior related to keyboard when not using a config, but fixed ...
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Server/General (show other bugs)
Version: 7.4 (2008.09)
Hardware: x86 (IA32) Linux (All)
: medium normal
Assignee: Xorg Project Team
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-12-01 18:03 UTC by Teran McKinney
Modified: 2008-12-02 17:42 UTC (History)
0 users

See Also:
i915 platform:
i915 features:

Attachments

Description Teran McKinney 2008-12-01 18:03:27 UTC 
Sorry for the vague summary; this is a rather odd problem that has been pesting me for a few days, but has an even stranger work-around.

Historical details set asside, I am running a Xorg 7.4+ish setup, with xorg-server 1.5.3, and a few beta protos for 7.5. On multiple hardware setups, when not using a xorg.conf, the keyboard would seem to stay partially in X, and partially in the TTYs (I launched from a TTY, no login managers involved). In X, I could alt+arrow to move to another TTY, and pressing enter then ctrl+c (usually it would not work on its own) would kill X, just like switching to the TTY X was launched from and pressing ctrl+c for a SIGINT normally would. Fairly consistently, the second time starting X (after it had been killed like that), after one or multiple key presses, X would completely lock up. The input devices had no effect at all, and I could not switch to a TTY (unfortunately, I currently do not have the magic sysrq key enabled in my kernel yet).

After a few days of rebuilding X packages, downgrading packages, downgrading the kernel, fiddling with DBus and HAL, I decided to test with a configuration file. My other installs with configuration files worked fine, but I had not tested it in the past few days. With a config file I did not experience these issues, but for some reason I tried with a completely *blank* xorg.conf, instead of none at all (as in echo > /etc/X11/xorg.conf). X autoconfigured as if the config wasn't there, and did not have the oddities with the keyboard! I was rather overjoyed at finding a work-around, but know that there is a strange bug lurking somewhere; I would presume in X itself. I did not have any mysterious crashes after key presses, and no locking up. I have yet to verify the work-around on other hardware, but presume it would work.

I have not heard of anyone having this problem before, and #xorg on Freenode wasn't very responsive (though eliasp did comment on it).

Anyways, X is working *perfectly* without a config (er, with a blank one) now, and I'm really pleased. You guys have sure done a good job :-).

Cheers, and thanks.

PS: This is on my Arch Linux fork, Icadyptes. Build scripts can be found at <ftp://icadyptes.go-beyond.org/icadyptes/abs>, if you need to take a look at them.
Comment 1 Peter Hutterer 2008-12-01 21:33:17 UTC 
You need to cherry-pick 0b56b44addc323a00eb7cd86240cb0dd4275bcf8.
Comment 2 Teran McKinney 2008-12-02 05:06:20 UTC 
(In reply to comment #1)
> You need to cherry-pick 0b56b44addc323a00eb7cd86240cb0dd4275bcf8.
> 

Thanks for the quick reply, but I've had no luck cherry-picking that commit onto 1.5.3.

I am certainly no git expert, but figured I should clone xserver then checkout xorg-server-1.5.3. When cherry-picking, I get:

[pkgbuild@silentgnu xserver]$ git cherry-pick 0b56b44addc323a00eb7cd86240cb0dd4275bcf8
Auto-merged hw/xfree86/common/xf86Globals.c
CONFLICT (content): Merge conflict in hw/xfree86/common/xf86Globals.c
Automatic cherry-pick failed.  After resolving the conflicts,
mark the corrected paths with 'git add <paths>' or 'git rm <paths>' and commit the result.
When commiting, use the option '-c 0b56b44' to retain authorship and message.

What should I do?

I also don't understand why this wasn't added to the 1.5 branch, since the patch is from 2008-10-22, and 1.5.3 was released in November; was this manifestation of the bug not known before?

Thanks.
Comment 3 Peter Hutterer 2008-12-02 16:56:07 UTC 
http://cvs.fedoraproject.org/viewvc/rpms/xorg-x11-server/F-10/xserver-1.5.3-AEI-on-by-default.patch?revision=1.1&view=markup

this one should apply cleanly.

> I also don't understand why this wasn't added to the 1.5 branch, since the
> patch is from 2008-10-22, and 1.5.3 was released in November; was this
> manifestation of the bug not known before?

It was, but missed out on the cherry pick for no reason other than
forgetfulness on my behalf.
Comment 4 Teran McKinney 2008-12-02 17:42:12 UTC 
The patch works perfectly. Thanks :-).

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.