Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 339988 - x11-base/xorg-server-1.9.0.901 causing keyboard layout problem
Summary: x11-base/xorg-server-1.9.0.901 causing keyboard layout problem
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: x86 Linux
: High major with 2 votes (vote)
Assignee: Gentoo X packagers
URL:
Whiteboard:
Keywords: InVCS
Depends on:
Blocks:
 
Reported: 2010-10-06 21:35 UTC by Mamadou Babaei
Modified: 2010-11-04 01:31 UTC (History)
23 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
patch for xorg-server-1.9.1.ebuild to illustrate my previous comment (xorg-server-1.9.1.ebuild.patch,867 bytes, patch)
2010-10-30 05:12 UTC, Chris Coleman
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Mamadou Babaei 2010-10-06 21:35:44 UTC
Last night I ran 
# emerge --update --deep --newuse --ask world
and x11-base/xorg-server-1.9.0.901 update pulled in by portage. And after turning on the machine on evening I noticed that I can't change my keyboard layout anymore (even other keyboard layouts from other countries).

According to this bug that I've submitted sometime ago:
http://bugs.gentoo.org/show_bug.cgi?id=329527

I downgrade from x11-misc/xkeyboard-config-2.0 to x11-misc/xkeyboard-config-1.7.

But the problem still remains. The only workaround that I found is to downgrade from x11-base/xorg-server-1.9.0.901 to x11-base/xorg-server-1.9.0-r2.

* Note that this bug is different from the bug above that I mentioned, because on that situation I just couldn't use Persian Layout. But now I can use nothing other than US Layout.



Reproducible: Always

Steps to Reproduce:
1. Just Upgrade to x11-base/xorg-server-1.9.0.901
2.
3.

Actual Results:  
Changing keyboard layout is not possible!

Expected Results:  
Keyboard Layout must changed by cliking on either it's icon on XFCE Panel or using the key that I have assigned to change layout option in XFCE Keyboard Layout.


Portage 2.1.9.13 (default/linux/x86/10.0, gcc-4.4.4, glibc-2.12.1-r1, 2.6.35.7 i686)
=================================================================
System uname: Linux-2.6.35.7-i686-Intel-R-_Core-TM-2_Duo_CPU_T9300_@_2.50GHz-with-gentoo-2.0.1
Timestamp of tree: Tue, 05 Oct 2010 23:00:01 +0000
app-shells/bash:     4.1_p7
dev-java/java-config: 2.1.11
dev-lang/python:     2.6.5-r3, 3.1.2-r4
dev-util/cmake:      2.8.1-r2
sys-apps/baselayout: 2.0.1
sys-apps/openrc:     0.6.3
sys-apps/sandbox:    2.3-r1
sys-devel/autoconf:  2.13, 2.68
sys-devel/automake:  1.6.3, 1.7.9-r2, 1.9.6-r3, 1.10.3, 1.11.1
sys-devel/binutils:  2.20.1-r1
sys-devel/gcc:       4.4.4-r2
sys-devel/gcc-config: 1.4.1
sys-devel/libtool:   2.2.10
sys-devel/make:      3.81-r2
virtual/os-headers:  2.6.35 (sys-kernel/linux-headers)
ACCEPT_KEYWORDS="x86 ~x86"
ACCEPT_LICENSE="* -@EULA Q3AEULA Nero-EULA-US PUEL vmware dlj-1.1 skype-eula AdobeFlash-10.1"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-O2 -march=core2 -mtune=core2 -pipe -msse4.1 -fomit-frame-pointer"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/share/config"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c"
CXXFLAGS="-O2 -march=core2 -mtune=core2 -pipe -msse4.1 -fomit-frame-pointer"
DISTDIR="/usr/portage/distfiles"
FEATURES="assume-digests binpkg-logs ccache distlocks fixlafiles fixpackages news parallel-fetch protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch"
GENTOO_MIRRORS="http://mirrors.kernel.org/gentoo/distfiles/ http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo http://mirror.csclub.uwaterloo.ca/gentoo-distfiles/ ftp://mirror.csclub.uwaterloo.ca/gentoo-distfiles/"
LANG="en_US.utf8"
LDFLAGS="-Wl,-O1 -Wl,--as-needed"
LINGUAS="en_US fa_IR en fa"
MAKEOPTS="-j3"
PKGDIR="/usr/portage/packages"
PORTAGE_CONFIGROOT="/"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="X a52 aac aalib acl acpi alsa amr aspell avahi bash-completion battery berkdb bluetooth branding bzip2 cairo cdr cleartype cli corefonts cracklib crypt cxx dbus dri dvd dvdr exif fbcon ffmpeg flac fontconfig fontforge fortran gdbm gif glitz gpm graphicsmagick gtk gtk2 hal hddtemp hdri hfs iconv id3tag ieee1394 imagemagick ipod ipv6 irda isight jbig joystick jpeg jpeg2k lcms libnotify lirc lm_sensors lzma lzo macbook matroska md5sum mesa midi mjpeg mmx mmxext mng modules mp3 mpeg mudflap ncurses nls nptl nptlonly nvidia ogg openal openexr opengl openmp pam pcre perl png pulseaudio python q32 qt3support qt4 rar raw readline reflection rle samba scanner sdl session smp sqlite sqlite3 sse sse2 sse3 sse4 sse4.1 ssl ssse3 svg sysfs tcpd theora tiff timidity truetype unicode usb v4l v4l2 vorbis wavpack webkit wifi wmf wxwidgets x264 x86 xcb xfce xml xorg xvid zlib" ALSA_CARDS="hda-intel" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx" INPUT_DEVICES="keyboard mouse synaptics evdev joystick" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en_US fa_IR en fa" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="nvidia vesa v4l fbdev" XFCE_PLUGINS="brightness menu trash" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" 
Unset:  CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY
Comment 1 Fabio Cavallo 2010-10-07 05:21:56 UTC
I have the same problem
Comment 2 Sergey 2010-10-07 06:27:19 UTC
I have the same with gnome. They say layout switches fine on WMs. Is it affects gnome and xfce only?
Comment 3 Sławek Wernikowski 2010-10-07 09:51:37 UTC
I can confirm that exactly the same problem appeared on my x86_64.
Comment 4 Javier Pérez 2010-10-09 05:09:54 UTC
I'm experiencing this issue in Gnome, I can change the keyboard layout using setxkbmap, however neither the applet nor the hot keys are working.
Comment 5 Jouni Rinne 2010-10-10 19:12:29 UTC
Yeah, the same problem with my Gnome laptop... Will downgrade to 1.9.0-r2
Comment 6 Ooblick 2010-10-16 08:04:37 UTC
Keyboard still not being set in xorg-server-1.9.0.902.
Comment 7 llex1234 2010-10-16 17:08:24 UTC
I've the same issue with xorg-server-1.9.0.902 and GNOME. setxkbmap definitely fixes it. After executing this command switching is possible again. Also there is no "evdev (or event, don't remember)" entry in the list of keyboard's models.
Comment 8 Krzysztof Magusiak 2010-10-26 18:15:02 UTC
Same problem for me with 1.9.1.
The last working version was 1.9.0-r2
Comment 9 Tolga Dalman 2010-10-27 10:54:00 UTC
Is this an upstream bug in xorg or Gentoo specific ? I have the same issues btw.
Comment 10 MZ 2010-10-27 13:32:20 UTC
me help change in /etc/X11/xorg.conf:

Section "InputClass"
	Identifier  "Keyboard0"
	Driver      "evdev"
	Option    "XkbModel" "hpdv5"
	Option    "XkbLayout" "us,cz"
	Option    "XkbVariant"    "altgr-intl,qwerty"
	Option     "XkbOptions" "terminate:ctrl_alt_bksp, grp:ctrl_shift_toggle"
	MatchIsKeyboard "yes"
EndSection

inspired: http://forums.gentoo.org/viewtopic-t-848365-highlight-xorg.html
Comment 11 Mamadou Babaei 2010-10-27 14:22:01 UTC
Confirm the problem with 1.9.1 :-S
Comment 12 Mike Auty (RETIRED) gentoo-dev 2010-10-30 02:45:56 UTC
Interestingly, the output to setxkbmap -print is identical before and after running "setxkbmap -layout gb", (so setxkbmap -print reports that gb symbols are in use).  However, after running the layout command the quotes and @ symbols do get set correctly.

Also has anyone experienced this with anything other than Gnome (or systems that use parts of Gnome such as XCFE)?  It seems to be a common theme running throughout this bug...

I've tried a rebuild of xf86-input-evdev after installation of xorg-server-1.9.1, but that didn't seem to have any effect.
Comment 13 Chris Coleman 2010-10-30 05:11:19 UTC
This is happening because xorg-server-1.9* ebuilds are failing to autoreconf properly. Add `eautoreconf` to the ebuild and this bug goes away.

The 1.8 ebuilds did this correctly by setting XORG_EAUTORECONF="yes" _before_ inheriting xorg-2.eclass. The 1.9 ebuilds are setting XORG_EAUTORECONF="yes" _after_ inheriting xorg-2.eclass where it has no effect.
Comment 14 Chris Coleman 2010-10-30 05:12:52 UTC
Created attachment 252541 [details, diff]
patch for xorg-server-1.9.1.ebuild to illustrate my previous comment
Comment 15 Chris Coleman 2010-10-30 05:19:59 UTC
(In reply to comment #13)
> The 1.8 ebuilds did this correctly by setting XORG_EAUTORECONF="yes" _before_
> inheriting xorg-2.eclass. The 1.9 ebuilds are setting XORG_EAUTORECONF="yes"
> _after_ inheriting xorg-2.eclass where it has no effect.
> 

And XORG_EAUTORECONF was not being set anyway on my system because I don't have "tslib" in my USE flags.
Comment 16 Chris Coleman 2010-10-30 05:27:21 UTC
(In reply to comment #13)
> The 1.9 ebuilds are setting XORG_EAUTORECONF="yes"
> _after_ inheriting xorg-2.eclass where it has no effect.
> 

Actually that's not true. It does have an effect even if you set it after inheriting. But then some variables will not be set.

The problem is really this:

if use kdrive && use tslib; then
        XORG_EAUTORECONF=yes
fi

The XORG_EAUTORECONF=yes needs to unconditional and before inheriting xorg-2.eclass.
Comment 17 Javier Pérez 2010-10-30 06:53:56 UTC
Nice catch, Chris, I was looking in all the wrong places, it seems.
Both setting the tslib USE flag (so that use kdrive && use tslib is true) or applying your patch fix this issue for me.
tslib is unnecessary in my system since I don't use a touchscreen so not knowing the reasoning behind the conditional in the ebuild I have to agree that XORG_EAUTORECONF should be set unconditionally.
Comment 18 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2010-10-30 07:39:27 UTC
(In reply to comment #12)
> Also has anyone experienced this with anything other than Gnome (or systems
> that use parts of Gnome such as XCFE)?  It seems to be a common theme running
> throughout this bug...

I think I had experienced a similar problem with git versions and xfce some time ago. I made so many changes then that I'm not sure whether an upgrade fixed it or some configuration mangling. I might have removed my xfce keyboard configs too and set it from scratch.

(In reply to comment #17)
> tslib is unnecessary in my system since I don't use a touchscreen so not
> knowing the reasoning behind the conditional in the ebuild I have to agree that
> XORG_EAUTORECONF should be set unconditionally.

That's the reasoning. Most users don't use tslib nor kdrive and upstream doesn't support them anymore. We don't see a reason why should we force autoreconf to all xorg-server users while it is only necessary for a very small group of tslib users who will no longer have the opportunity to use it soon.

If you apply a patch which requires autoreconf, you're responsible for forcing it yourself.
Comment 19 Chris Coleman 2010-10-30 08:04:35 UTC
If forcing XORG_EAUTORECONF=yes is not acceptable, then I'll continue to try to find the root cause of this problem when I have time.

There is apparently a crucial difference between the output of autotools on our Gentoo systems and the output of autotools on the system used to make the release tarballs.
Comment 20 Chris Coleman 2010-10-30 13:11:18 UTC
(In reply to comment #19)
> There is apparently a crucial difference between the output of autotools on our
> Gentoo systems and the output of autotools on the system used to make the
> release tarballs.
> 

I've found the difference. CFLAGS. When using upstream's configure script, CWARNFLAGS contains -Wstrict-aliasing=2. After autoreconf, this is replaced with -fno-strict-aliasing. Weird, huh?

So without autoreconf you're building with strict aliasing enabled (presuming -O2 or -O3). But with autoreconf, you're building with strict aliasing disabled.

CWARNFLAGS is defined in xorg-macros.m4 which is provided by x11-misc/util-macros. It comes into play here when running autoconf to generate the configure script.

So I think upstream are building their releases with a version of xorg-macros.m4 that doesn't correspond to any tagged version in git. Every version since util-macros-1.2.0 has -fno-strict-aliasing.

And upstream's disabling of strict aliasing is definitely deliberate:

http://www.mail-archive.com/xorg-devel@lists.x.org/msg05057.html

So this bug could be fixed by adding -fno-strict-aliasing to CFLAGS. But it should be there anyway. So I think I need to take this upstream.

Any thoughts? Am I correct about this? Have I made a mistake? I'd appreciate your input before I contact upstream.
Comment 21 Mike Auty (RETIRED) gentoo-dev 2010-10-30 13:36:14 UTC
Well, I can confirm that manually adding -fno-strict-aliasing does solve the problem.

Yes, I'd file an upstream bug (and once you do, please paste the bug URL here so that others can follow along). 

However, since this version isn't likely to get fixed until they roll aa new version, and because xorg-server-1.9.0 has now been removed from the tree (meaning some people could be stuck with a non-working keyboard layout), perhaps it's enough reason to add XORG_EAUTORECONF=yes back unconditionally?  Or at least patch the offending CWARNFLAGS.

We really should try and get his fixed as soon as possible...
Comment 22 Chris Coleman 2010-10-30 14:13:24 UTC
(In reply to comment #21) 
> Yes, I'd file an upstream bug (and once you do, please paste the bug URL here
> so that others can follow along). 

Ok, I'll do that.

I've been searching through existing bug reports. A patch was submitted just before the release of 1.3.0 to add -Wstrict-aliasing=2 to CWARNFLAGS. But it was never committed.

https://bugs.freedesktop.org/show_bug.cgi?id=22939#c7
Comment 23 Chris Coleman 2010-10-30 15:00:38 UTC
Here's the upstream bug report.

https://bugs.freedesktop.org/show_bug.cgi?id=31238
Comment 24 Chris Coleman 2010-10-30 22:23:22 UTC
From: Jeremy Huddleston <jeremyhu@freedesktop.org>
Subject: [PATCH] configure.ac: Add -fno-strict-aliasing to CFLAGS
Date: Sat, 30 Oct 2010 15:02:42 -0700
Message-id: <B62DC0DC-9348-4C9F-87B6-1DFDD9B644FB@freedesktop.org>
Cc: Gaetan Nadon <memsize@videotron.ca>, chrsclmn@gmail.com
To: xorg-devel Development <xorg-devel@lists.x.org>
X-Mailer: Apple Mail (2.1082)
X-Brightmail-Tracker: AAAAAA==

This should address https://bugs.freedesktop.org/show_bug.cgi?id=31238 in the short term, although I'd much rather see a fix for:

https://bugs.freedesktop.org/show_bug.cgi?id=22939


Signed-off-by: Jeremy Huddleston <jeremyhu@apple.com>
---
 configure.ac |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/configure.ac b/configure.ac
index e8f9473..01c5196 100644
--- a/configure.ac
+++ b/configure.ac
@@ -83,6 +83,12 @@ AC_PROG_SED
 # easier overrides at build time.
 XSERVER_CFLAGS='$(CWARNFLAGS)'
 
+dnl Explicitly add -fno-strict-aliasing since this option should disappear
+dln from util-macros CWARNFLAGS
+if  test "x$GCC" = xyes ; then
+    XSERVER_CFLAGS="$XSERVER_CFLAGS -fno-strict-aliasing"
+fi
+
 dnl Check for dtrace program (needed to build Xserver dtrace probes)
 dnl Also checks for <sys/sdt.h>, since some Linux distros have an 
 dnl ISDN trace program named dtrace
-- 
1.5.6.6
Comment 25 Jouni Rinne 2010-10-31 11:25:07 UTC
And WHY xorg-server-1.9.0 is removed from portage??? It should not be removed until this issue has been fixed properly. I had to resort to copying 1.9.0-r2 to my local overlay and using it; anything newer makes my laptop's keyboard unusable 
Comment 26 Tomáš Chvátal (RETIRED) gentoo-dev 2010-10-31 11:48:43 UTC
Problem fixed in 1.9.1-r1 ebuild.
@Chris: thanks for such good investigation and problem description.
Comment 27 Chris Coleman 2010-11-01 03:20:16 UTC
This has been fixed in xorg-server-1.9.2 which is now available.
Comment 28 Chris Coleman 2010-11-01 03:29:27 UTC
(In reply to comment #27)
> This has been fixed in xorg-server-1.9.2 which is now available.
> 

Additionally, it was fixed in util/macros on the build server, not with any patch.
Comment 29 Chris Coleman 2010-11-01 14:59:36 UTC
As upstream are now using the correct version of util/macros, the following comment should be removed from xorg-server-1.9.2.ebuild:

# They generate the configure.ac with wrong version of util-macros
# see bug #339988

And the unconditional XORG_EAUTORECONF=yes is not absolutely necessary since the death of this bug, but if you decide to remove it you may need to re-add this?:

if use kdrive && use tslib; then
        XORG_EAUTORECONF=yes
fi

Ideally, though, XORG_EAUTORECONF=yes, if it's set at all, should be set before inheriting xorg-2.eclass so that it can pull in dependencies and set WANT_AUTO(CONF|MAKE).
Comment 30 Mamadou Babaei 2010-11-01 15:20:25 UTC
tnx guys!! :)
finally got it to work.
Comment 31 Chris Coleman 2010-11-04 01:31:18 UTC
(In reply to comment #26)
> @Chris: thanks for such good investigation and problem description.

Thanks for saying that, Tomáš.