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
I have the same problem
I have the same with gnome. They say layout switches fine on WMs. Is it affects gnome and xfce only?
I can confirm that exactly the same problem appeared on my x86_64.
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.
Yeah, the same problem with my Gnome laptop... Will downgrade to 1.9.0-r2
Keyboard still not being set in xorg-server-1.9.0.902.
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.
Same problem for me with 1.9.1. The last working version was 1.9.0-r2
Is this an upstream bug in xorg or Gentoo specific ? I have the same issues btw.
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
Confirm the problem with 1.9.1 :-S
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.
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.
Created attachment 252541 [details, diff] patch for xorg-server-1.9.1.ebuild to illustrate my previous comment
(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.
(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.
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.
(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.
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.
(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.
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...
(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
Here's the upstream bug report. https://bugs.freedesktop.org/show_bug.cgi?id=31238
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
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
Problem fixed in 1.9.1-r1 ebuild. @Chris: thanks for such good investigation and problem description.
This has been fixed in xorg-server-1.9.2 which is now available.
(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.
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).
tnx guys!! :) finally got it to work.
(In reply to comment #26) > @Chris: thanks for such good investigation and problem description. Thanks for saying that, Tomáš.