These shortcuts are provided by gnome-settings-daemon, not gnome-shell/mutter.

Corrected the report, thanks Jasper.

Affects me too

Okay I have narrowed down the packages that are part of the problem.

If these packages are downgraded to their previous versions, the keyboard shortcuts work again.

[2012-10-13 14:03] upgraded xf86-input-evdev (2.7.3-1 -> 2.7.3-2) https://www.archlinux.org/packages/extra/x86_64/xf86-input-evdev/
[2012-10-13 14:03] upgraded xf86-input-synaptics (1.6.2-1 -> 1.6.2-2)
https://www.archlinux.org/packages/extra/x86_64/xf86-input-synaptics/
[2012-10-13 14:03] upgraded xf86-video-intel (2.20.9-1 -> 2.20.9-2)
https://www.archlinux.org/packages/extra/i686/xf86-video-intel/
[2012-10-13 14:03] upgraded xorg-server-common (1.12.4-1 -> 1.13.0-2)
https://www.archlinux.org/packages/extra/i686/xorg-server-common/
[2012-10-13 14:03] upgraded xorg-server (1.12.4-1 -> 1.13.0-2) https://www.archlinux.org/packages/extra/i686/xorg-server/

The packages are somewhat codependent.  If you don't upgrade xf86-input-evdev and xorg-server at the same time, the keyboard doesn't work at all. The mouse doesn't work if you don't upgrade xf86-input-synaptics and xorg-server at the same time, and nothing works if you don't upgrade xf86-video-intel when you upgrade xorg-server X won't start at all.

The bug reports in the arch bug tracker seem to indicate that in only happens with gnome and gnome derivatives, cinnamon, so it seems to be a gnome problem not an X problem, but I am not nearly knowledgeable enough to make that call for sure.  It could be an X problem that is just not effecting other display managers openly yet.

I linked the Arch linux packages since those are the versions of the software that I know are directly connected to the issue.

Let me know if you need any further information from me.

I am affected as well

Affected too. Is it possible, that a new build against the new Xorg-Headers maybe fix this?

I am also affected by this bug. FN keys and keyboard shortcuts do not work in GNOME 3.4.2 with Xorg 1.13.x but I'm not sure if it works after rebuilding GNOME against the new version of Xorg. It would be nice if the GNOME developers can tell us what exact packages should we recompile against the new Xorg in order to get FN keys and shourtcuts working again. I think it could be just "gnome-settings-daemon" but I'm not sure. Please, clarify this to us. Thank you.

As akira86 reported on the arch forums, a recompile seem not to fix the issue.

I'm affected too after upgrading my ArchLinux yesterday on a Thinkpad x100e.

No FN keys working :-(

Linux 3.6.2-1-ARCH #1 SMP PREEMPT Fri Oct 12 23:58:58 CEST 2012 x86_64 GNU/Linux

Same here.

# uname -a
Linux thinkpad 3.6.2-1-ARCH #1 SMP PREEMPT Fri Oct 12 23:58:58 CEST 2012 x86_64 GNU/Linux

# paman -Q | grep gnome-shell
gnome-shell 3.4.2-1


Fn keys stopped working with updates on 2012-10-13:

# cat /var/log/pacman.log | grep -o .*2012-10-13\ 09.*upgraded.*
[2012-10-13 09:49] upgraded libglapi (8.0.4-3 -> 9.0-1)
[2012-10-13 09:49] upgraded libgl (8.0.4-3 -> 9.0-1)
[2012-10-13 09:49] upgraded ati-dri (8.0.4-3 -> 9.0-1)
[2012-10-13 09:49] upgraded gegl (0.2.0-3 -> 0.2.0-4)
[2012-10-13 09:49] upgraded glew (1.8.0-1 -> 1.8.0-2)
[2012-10-13 09:49] upgraded gnome-games (3.4.2-1 -> 3.4.2-2)
[2012-10-13 09:49] upgraded gnutls (3.1.2-1 -> 3.1.3-1)
[2012-10-13 09:49] upgraded imagemagick (6.7.9.8-1 -> 6.7.9.8-2)
[2012-10-13 09:49] upgraded jasper (1.900.1-7 -> 1.900.1-8)
[2012-10-13 09:49] upgraded kdebase-runtime (4.9.2-1 -> 4.9.2-2)
[2012-10-13 09:49] upgraded kdelibs (4.9.2-1 -> 4.9.2-2)
[2012-10-13 09:49] upgraded khrplatform-devel (8.0.4-3 -> 9.0-1)
[2012-10-13 09:49] upgraded systemd (194-1 -> 194-3)
[2012-10-13 09:49] upgraded libgbm (8.0.4-3 -> 9.0-1)
[2012-10-13 09:49] upgraded libegl (8.0.4-3 -> 9.0-1)
[2012-10-13 09:49] upgraded libreoffice-en-US (3.6.2-1 -> 3.6.2-2)
[2012-10-13 09:49] upgraded libreoffice-common (3.6.2-1 -> 3.6.2-2)
[2012-10-13 09:49] upgraded libreoffice-base (3.6.2-1 -> 3.6.2-2)
[2012-10-13 09:49] upgraded libreoffice-calc (3.6.2-1 -> 3.6.2-2)
[2012-10-13 09:49] upgraded libreoffice-draw (3.6.2-1 -> 3.6.2-2)
[2012-10-13 09:49] upgraded libreoffice-gnome (3.6.2-1 -> 3.6.2-2)
[2012-10-13 09:49] upgraded libreoffice-impress (3.6.2-1 -> 3.6.2-2)
[2012-10-13 09:49] upgraded libreoffice-math (3.6.2-1 -> 3.6.2-2)
[2012-10-13 09:49] upgraded libreoffice-writer (3.6.2-1 -> 3.6.2-2)
[2012-10-13 09:49] upgraded mesa (8.0.4-3 -> 9.0-1)
[2012-10-13 09:49] upgraded sysvinit-tools (2.88-8 -> 2.88-9)
[2012-10-13 09:49] upgraded systemd-sysvcompat (194-1 -> 194-3)
[2012-10-13 09:49] upgraded xf86-input-evdev (2.7.3-1 -> 2.7.3-2)
[2012-10-13 09:49] upgraded xf86-input-synaptics (1.6.2-1 -> 1.6.2-2)
[2012-10-13 09:49] upgraded xf86-video-ati (1:6.14.6-1 -> 1:6.14.6-2)
[2012-10-13 09:49] upgraded xorg-server-common (1.12.4-1 -> 1.13.0-2)
[2012-10-13 09:49] upgraded xorg-server (1.12.4-1 -> 1.13.0-2)


Got the Fn keys working again after the following downgrades:

#cat /var/log/pacman.log | grep -o .*2012-10-13\ 16.*upgraded.*
[2012-10-13 16:34] upgraded xf86-input-evdev (2.7.3-2 -> 2.7.3-1)
[2012-10-13 16:37] upgraded xf86-video-ati (1:6.14.6-2 -> 1:6.14.6-1)
[2012-10-13 16:37] upgraded xorg-server-common (1.13.0-2 -> 1.12.4-1)
[2012-10-13 16:38] upgraded xorg-server (1.13.0-2 -> 1.12.4-1)
[2012-10-13 16:49] upgraded xf86-input-synaptics (1.6.2-2 -> 1.6.2-1)


Then the Fn stopped working again with updates on 2012-10-16,as follows:

#cat /var/log/pacman.log | grep -o .*2012-10-16\ 12:1.*upgraded.*
[2012-10-16 12:14] upgraded curl (7.27.0-1 -> 7.28.0-1)
[2012-10-16 12:14] upgraded gtk-vnc (0.5.0-1 -> 0.5.1-1)
[2012-10-16 12:14] upgraded hwids (20120922-1 -> 20121012-1)
[2012-10-16 12:14] upgraded libldap (2.4.32-1 -> 2.4.33-1)
[2012-10-16 12:15] upgraded linux (3.5.6-1 -> 3.6.2-1)
[2012-10-16 12:15] upgraded lirc-utils (1:0.9.0-30 -> 1:0.9.0-31)
[2012-10-16 12:15] upgraded pam (1.1.5-4 -> 1.1.6-1)
[2012-10-16 12:15] upgraded util-linux (2.22-7 -> 2.22.1-1)
[2012-10-16 12:15] upgraded whois (5.0.19-1 -> 5.0.20-1)
[2012-10-16 12:15] upgraded wpa_supplicant (1.0-1 -> 1.0-2)
[2012-10-16 12:15] upgraded xterm (283-1 -> 284-1)

I released the previously downgraded packages (see above) to see if that made any difference, and it did not.

Happy to provide any additional information that may help, here or elsewhere.

--Matt

I do not know if it can help, but, interestingly, many Fn+Key work perfectly. In my case for instance: Fn+LEFT_ARROW (i.e. Home), Fn+F11 (i.e. switch wifi on/off) and others work. 
I have got a System76's "gazelle professional".
--Quentin

Quentin are you on xorg-server 1.13.0, gnome-shell 3.4.2, and gnome-settings-daemon 3.4.2?

-D

Sorry,

I have:

xorg-server 1.13.0-2
gnome-shell  3.4.2-1
gnome-settings-daemon  3.4.2-1

Also, I am running Arch Linux.
Just let me know if you need any additional infos.
--Quentin

I have the same arch linux environment and included gnome-settings-daemon --debug in my gnome-session (with gnome-session-properties). Now i get debug messages in .xsession-errors:

(gnome-settings-daemon:10144): media-keys-plugin-DEBUG: No Xinput2 support, disabling plugin

The Fn-Keys are sometimes still working, because the work in the background is sometimes done by the BIOS/UEFI itself if "not captured" by the host system.

Good example for this are normally all ThinkPads, thats also the reason why a lot of stuff work out-of-the-box with them.

(In reply to comment #14)
> I have the same arch linux environment and included gnome-settings-daemon
> --debug in my gnome-session (with gnome-session-properties). Now i get debug
> messages in .xsession-errors:
> 
> (gnome-settings-daemon:10144): media-keys-plugin-DEBUG: No Xinput2 support,
> disabling plugin

This sounds very much like an X server bug, which is why it broke after upgrade. Maybe the Arch people accidentally compiled it without XInput2 support?

(In reply to comment #16)
> (In reply to comment #14)
> > I have the same arch linux environment and included gnome-settings-daemon
> > --debug in my gnome-session (with gnome-session-properties). Now i get debug
> > messages in .xsession-errors:
> > 
> > (gnome-settings-daemon:10144): media-keys-plugin-DEBUG: No Xinput2 support,
> > disabling plugin
> 
> This sounds very much like an X server bug, which is why it broke after
> upgrade. Maybe the Arch people accidentally compiled it without XInput2
> support?

Jasper, I will try and follow up with this information with the people at Arch.  Your conclusion makes sense, since it was the xorg upgrade that started the issue, but wouldn't we see this issue in other Desktop Environments, like KDE, if it was an xorg bug?  There were a few reports of something similar happening in XFCE, but others using gnome 3.6 packages from an unstable repo don't seem to be effected?  What are you thoughts?

X is giant. XFCE or KDE might not tweak all the same knobs on X that we do, and they can still make it work.

I am affected as well.

(In reply to comment #16)
> 
> This sounds very much like an X server bug, which is why it broke after
> upgrade. Maybe the Arch people accidentally compiled it without XInput2
> support?

It's very unlikely:

$ xinput --version
xinput version 1.6.0
XI version on server: 2.2

So xserver supports XI2.

http://git.gnome.org/browse/gnome-settings-daemon/tree/plugins/common/gsd-input-helper.c#n121

This is the exact check that's used to check for XI2 support. It first checks for the "XInputExtension" extension, and then goes and queries the XInput extension version. Would you mind consolidating that into a binary, and make sure to call gtk_init() before you query for anything?

What should I pass as opcode?

The opcode is an output parameter. You can just pass in something and ignore that.

Created attachment 226748 [details] [review]
Patch to make gsd-3.4.2 work with xi-2.2

I've just noticed that this function is a bit different for gsd-3.4.2, and it does not check for xi-2.2. Copy-pasted it from git master version and voila - it works again.

http://git.gnome.org/browse/gnome-settings-daemon/log/?h=gnome-3-4
http://git.gnome.org/browse/gnome-settings-daemon/commit/?h=gnome-3-4&id=9d23fac4ce927cd27964323aa4cf8138e5128ba0

It looks like this patch was committed to the 3.4 branch way back in May (2 days after the 3.4.2 release actually).  But there obviously hasn't been another release since then.

Interestingly enough, XInput 2.2 was released in Xorg Server 1.12.  This bug just seems to be having much more impact in 1.13.  Even though I downgraded to 1.12, my brightness keys still don't work, although my volume keys do.  In 1.13, neither work.

FYI, Arch is not going to fix this before they release Gnome 3.6:
https://bugs.archlinux.org/task/32047

But someone did put together a patched version of gnome-settings-daemon that I can confirm is working for me (my brightness keys work again!).  You can get it here:
https://bbs.archlinux.org/viewtopic.php?pid=1177846#p1177846

Can we get an ETA for an new upstream bugfix?
btw. Status should be changed from "UNCONFIRMED" to "CONFIRMED"

Installing/Waiting for Gnome 3.6 is embarrassing (dangerous, needs much time, big effort) to fix a bug, major releases should'nt abused to fix regular bugs.

There is going to be no more upstream 3.4 release. Arch maintainers may do whatever they want at this point.

(In reply to comment #27)
> Can we get an ETA for an new upstream bugfix?
> btw. Status should be changed from "UNCONFIRMED" to "CONFIRMED"

We don't use the "UNCONFIRMED" status.

Well. You've used that before on this task.
The issue was fixed some days after Gnome 3.4.2 release. And now you tell me, that Gnome is not even supporting six months old releases? Pure Debian.

Ridiculous. Honestly. Nobody would cry if that was one year or more, but defacto no distribution has switched to Gnome 3.6 in a stable officiall release. Debian even doesn't have switched to 3.4!

I'm simply saying that 3.4.2 is the last of stable releases for the 3.4 timeframe. Distros are certainly allowed to (and encouraged to, in some cases) pull in patches from the gnome-3-4 branch when building packages for users.

(In reply to comment #30)
> Well. You've used that before on this task.

I phrased it poorly. I meant "we don't distinguish between UNCONFIRMED and CONFIRMED/NEW statuses". The default state of every bug is "UNCONFIRMED".

*sigh*
Thanks. I'will try to persuade the responsible maintainers. I know that the chances are bad, becauces bug should be fixed upstream and not downstream.

The bug was fixed upstream.

*edit* The bug was fixed upstream but never released in the 3.4 series.

Chronologically:

2012-03-05 - X.Org Server 1.12 released with XInput 2.2 - http://www.phoronix.com/scan.php?page=news_item&px=MTA2NjE

2012-03-28 - Gnome 3.4 released - no XInput 2.2 support - http://www.gnome.org/news/2012/03/gnome-3-4-released/

2012-05-15 - Gnome 3.4.2 released - still no XInput 2.2 support - http://git.gnome.org/browse/gnome-settings-daemon/log/?h=gnome-3-4

2012-05-17 - Patch for XInput 2.2 support finally applied to Gnome 3.4 branch - http://git.gnome.org/browse/gnome-settings-daemon/commit/?h=gnome-3-4&id=9d23fac4ce927cd27964323aa4cf8138e5128ba0

2012-09-05 - X.Org Server 1.13 released - still no XInput 2.2 support in an official Gnome release - http://www.phoronix.com/scan.php?page=news_item&px=MTE3Njg

2012-09-26 - Gnome 3.6 released - finally has XInput 2.2 support - http://www.gnome.org/news/2012/09/gnome-3-6-released/

That's 6 months and 21 days that Gnome did not have an official release that supported XInput 2.2, which, IMO, is pretty poor.  Sure, this one is moot now that 3.6 is out, but I think we'd both like to see better official release support in the future.  I'm honestly surprised Arch users didn't jump on this one much earlier (I just recently switched to Arch 2 weeks ago).

This is not "supported XInput 2.2" -- this is a workaround for a bug in the X server. You can see the history in the bug report linked in the commit message:

https://bugzilla.gnome.org/show_bug.cgi?id=673964

Thanks for clarifying, Jasper.  Although it kinda sounds like a he said/she said sort of thing...

X server says "The first call to XIQueryVersion defines the server behaviour. Once cached, always return that version number to any clients. Unless a client requests a version lower than the first defined one, then a BadValue must be returned to be protocol-compatible." - http://cgit.freedesktop.org/xorg/xserver/commit/?id=ea51e9b2877df60135edaf2a8f88d0f2a2b41060

Gnome says "We want you to return the same value all the time and we think you're buggy, but we'll patch Gnome anyway."

Personally, I'd agree with Gnome's side in this, but I definitely don't have any knowledge of the X server code and what's required on their side in order for things to be "protocol-compatible".

Regardless, thanks for clarifying what the issue actually is.