Summary: | x11-base/xorg-server-1.9.0.901 causing keyboard layout problem | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Mamadou Babaei <info> |
Component: | New packages | Assignee: | Gentoo X packagers <x11> |
Status: | RESOLVED FIXED | ||
Severity: | major | CC: | brathering82, christian.kotz, chrmag, chrsclmn, ddemidov, f.apitzsch, fhorse, ford_prefect, gidanmx2, ikelos, jperezq, l33tmmx, llex1234, marcin.deranek, matrix47, maxbritov, mbakhoff, nirbheek, ooblick, PishiSyda, slawek, tdalman, tommaso.pasini |
Priority: | High | Keywords: | InVCS |
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | patch for xorg-server-1.9.1.ebuild to illustrate my previous comment |
Description
Mamadou Babaei
2010-10-06 21:35:44 UTC
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áš. |