You are not logged in.
Got it working! gsd-3.4.2 does not check for xi-2.2 after xi-2.0 check fails, here's source package:
https://www.dropbox.com/s/s1squ7nzk0845 … src.tar.gz
Offline
Can anyone else confirm the patched version is working?
Entia non sunt multiplicanda praeter necessitatem
Offline
I can confirm that anarsoul's version is working. I even got back my brightness keys, which weren't working in xorg-server 1.12 either.
FYI, this isn't going to be fixed by Arch officially. They're waiting for Gnome 3.6:
https://bugs.archlinux.org/task/32047
Offline
thx mate, could you please do this in the aur?
Offline
We should push to get gnome 3.6 in stable. It is not just this bug, there are other bugs that will not be fixed until then.
Entia non sunt multiplicanda praeter necessitatem
Offline
FYI, this isn't going to be fixed by Arch officially. They're waiting for Gnome 3.6:
https://bugs.archlinux.org/task/32047
Oh, c'mon, they can't just update a single package? Why should we wait for gnome-3.6 if there's a fix for 3.4?
Offline
Can anyone else confirm the patched version is working?
YES! I confirm too that anarsoul's version is working. Thanks a lot!
EDIT: Intel Pentium Dual-Core CPU E6300, so x86, i915 Intel video card. Gnome 3.4 vanilla.
Last edited by i18nde (2012-10-19 13:05:43)
Strawberry fields forever!
Offline
Using arch x86_64 and gnome 3.4, both the multimedia keys and keyboard shortcuts are working, so thanks anarsoul !
Offline
Works for me, too: Arch x86_64 and Gnome 3.4. Thanks a lot!
Offline
Got it working! gsd-3.4.2 does not check for xi-2.2 after xi-2.0 check fails, here's source package:
https://www.dropbox.com/s/s1squ7nzk0845 … src.tar.gz
I can confirm also that anarsoul's PKGBUILD is working. All of my keyboard shortcuts and media keys are working again after installing his gnome-settings-deamon changes and rebooting. The only substantive changes he made are in the following file as far as I can see (abs vs. anarsoul):
diff -r abs/extra/gnome-settings-daemon/src/gnome-settings-daemon-3.4.2/plugins/common/gsd-input-helper.c anarsoul/gnome-settings-daemon/src/gnome-se
ttings-daemon-3.4.2/plugins/common/gsd-input-helper.c
129,130c129
<
< if (XIQueryVersion (GDK_DISPLAY_XDISPLAY (gdk_display_get_default ()), &major, &minor) != Success) {
---
> if (XIQueryVersion (GDK_DISPLAY_XDISPLAY (gdk_display_get_default ()), &major, &minor) != Success) {
132c131,138
< return FALSE;
---
> /* try for 2.2, maybe gtk has already announced 2.2 support */
> gdk_error_trap_push ();
> major = 2;
> minor = 2;
> if (XIQueryVersion (GDK_DISPLAY_XDISPLAY (gdk_display_get_default ()), &major, &minor) != Success) {
> gdk_error_trap_pop_ignored ();
> return FALSE;
> }
Hope that helps.
Last edited by vsingleton (2012-10-19 13:34:42)
Offline
And what about poor xfce users?
Offline
And what about poor xfce users?
Try to use the patched gnome-settings-daemon - it might be compatible.
Last edited by Thomas_Do (2012-10-19 14:09:12)
Offline
anarsoul's patch work also for me (toshiba z830, arch x86_64 and of course gnome 3.4).
Thank's to anarsoul
Offline
Got it working! gsd-3.4.2 does not check for xi-2.2 after xi-2.0 check fails, here's source package:
https://www.dropbox.com/s/s1squ7nzk0845 … src.tar.gz
Work for me. Thank you!
Offline
Nice one Anarsol - works for me too Wouldn't have known where to even start looking myself :-O
Offline
Gnome 3.6 hit testing, so it seems like it wasn't that distant after all.
Offline
jbirdjavi wrote:FYI, this isn't going to be fixed by Arch officially. They're waiting for Gnome 3.6:
https://bugs.archlinux.org/task/32047Oh, c'mon, they can't just update a single package? Why should we wait for gnome-3.6 if there's a fix for 3.4?
It is not the philosophy of Archlinux, to fix bugs "downstream". The bug is caused by Gnome (this is upstream), and not by Archlinux (this is downstream, e.g. configure, make, packaging, dependencies or own code: pacman, filesystem, installer and so on).
http://www.archlinux.org/about/
Other distributors fix bugs own there own (Debian, Ubuntu, Fedora). But this makes communication, sync and proper solutions for upstream harder. If Fedora fixes a bug, the users of Fedora don't face this bug and stop reporting the bug to upstream. But all others are still suffering this bug. Also, the Fedora people doesn't know the internals of $FOO, in wort case there bugfix can lead to other problems in $BAR, which leads to new bug and bug reports to upstream who will try to fix something what is NOT_BROKEN. Also fixing bugs downstream need much resources (humand resources) and more testing and lead to "double work".
A good example is the Linux kernel:
If you developed a feature for the Kernel and ask for a upstream merge, it is very likely that your code will be not merged if you found and written workarounds for other bugs of the kernel in your own code. Thats not the way of FREE_LIBRE_OPEN_SOURCE, you should instead immediately report your issuses which will lead to a global fix for everyone. Especially, your workaround will be maybe break your own code if the bugfix will be merged upstream.
Of course: If your face a major bug, a real show stopper (not function at all, dangerous, damages, security...) you can and must fix the bug temporary downstream!
Counter example:
The Debian people want stay at version $AIR_DRIED_OLD_STUFF_TESTED_FOR_YEARS, even if upstream doesn't support this anymore. You know, the rockstable and nevery changing thing of Debian. Which lead to the fact, that Debian people fix and patch bugs in very old Firefox releases (long before the new version hopping thing has started). But this means patching and modifing source code. Sadly the Mozilla Foundation doesn't allow to use the Firefox-Logo if any line of code is changed. Thats caused not by rationale reasons of Mozilla, the marketing department is crazy itself. This damages communication from downstream to upstream and the reason why Firefox is named "Iceweasel" by the Debian people. This a example for the worst case
Solution for us:
If Archlinux decidecd that this is a real worse major bug and the fix is simple, maybe the will release a new package with the fix. It is better, much better, that Gnome officially releases a patched version of Gnome 3.4.x! Because upgrading major versions for simple fix is not a secure and sance way to fix things, it is likley to face new bugs and will add more time lag.
Last edited by hoschi (2012-10-20 13:26:06)
Offline
// edit
Haha! Read below
Last edited by hoschi (2012-10-20 15:43:42)
Offline
The Gnome people doesn't want fix that! Well, they have fixed that. But they don't want release a new version. For a six month old release their is no more support? But no distribution uses Gnome 3.6 in its stable branch at writing of this. Not Arch, not Gentoo, not Fedora, not Ubuntu (Unity + Nautilus 3.4) and finally Debian even not moved to 3.4 in its stable release. If would be perfectly fine if this would be bug in the one year old Gnome 3.2 (well, or not: Fedora is still using it). But if a Gnome developer ask me, why nearly everyone keeps beating on them, their is the answer: They don't care about the users. I really appreciate their work and don't want blame somebody for his/her work. But if you put so much work and love in something, you would also care about it?
Ridiculous? Can we beg for mercy from Wonder, for a fix in the Arch packages?
// edit
https://bugs.archlinux.org/task/32033
Maybe. But putting the responsibility to Archlinux itself is not correct in my opinion.
Last edited by hoschi (2012-10-20 16:17:48)
Offline
I'm not surprised. Gnome's stable branch doesn't even compile usually.
Offline
Posts cannot contain only capital letters.
Take that forum. A lower case "p":
Offline
Thanks anarsoul! Fixed all the shortcuts on my x86_64 desktop.
Registered Linux user #436067
Offline
anarsoul! Thanks so much! That fixed worked perfectly
Offline
Does anyone know what the upgrade
xorg-server (1.12.4-1 => 1.13.0-3)
changes? Does it fix our issues?
Offline
Does anyone know what the upgrade
xorg-server (1.12.4-1 => 1.13.0-3)
changes? Does it fix our issues?
Search the website: go to www.archlinux.org/packages, search for xorg-server, and go to View Changes.
Without error there can be no brilliancy. ― Emanuel Lasker
Offline