the weird thing is that I don't have the evdev module loaded (I guess that the keyboard driver is supplied through usbhid or something like that), so for now I'm refraining to set that bug back to confirmed
but it doesn't work (it's for the italian layout if you need it)
If I remember correctly, some time ago I also tried to put a script in /etc/acpi/resume.sh (now probably it should go into /etc/pm/sleep.d/ ) to no avail
if __name__ == '__main__':
try:
if args.t in ("added", "present") and args.i == "10": call(["xmodmap", expanduser("~/.Xmodmap")])
#EOF
(I also added some error checking when debugging it, and 10 is the XID obtained from xinput)
and I added it to g-s-d with
gsettings set org.gnome.settings-daemon.peripherals.input-devices hotplug-command '/path/to/mac_keyboard_fix.py'
but apparently, gnome-settings-daemon receives a device-added signal, only for device #11(touchpad) and #14(unknown)
(so, this seems to be denying the hypothesis that the problem is due to the driver loading the keyboard as a completely different keyboard)
right now, I'm not sure why, but when doing a suspend/resume, if I previously applied the xmodmap, the change retains... but in the meanwhile I removed the python script, deactivated the .desktop startup item, and nothing else should be able to change the behaviour after-resume without also changing it after bootup, so I'm quite baffled
I get fed up by this issue every few months, and I try to find a workaround that works once and for all (unless something makes the xmodmap script working, that is)... but now I've spent too much time on this, I just hope that something/somebody will improve the situation in the next months
I'm affected by this problem as well, but the hid_apple fix didn't work for me
this is weird, since I'm using the hid_apple.conf already to use the special keys as default:
> cat /etc/modprobe. d/hid_apple. conf
options hid_apple iso_layout=0 fnmode=1
I tried all of the 3 alternatives that have been written here: wiki.debian. org/InstallingD ebianOn/ Apple/PageFragm entKeyboard
http://
but not even setting it from GRUB is working
I cannot use the xmodmap setting for a different reason, it seems that I'm affected by this bug: /bugs.launchpad .net/ubuntu/ +source/ xserver- xorg-input- evdev/+ bug/289781
https:/
the weird thing is that I don't have the evdev module loaded (I guess that the keyboard driver is supplied through usbhid or something like that), so for now I'm refraining to set that bug back to confirmed
I also tried to use this file for startup:
> cat .config/ autostart/ xmodmap. desktop Autostart- enabled= false
[Desktop Entry]
Type=Application
Exec=xmodmap -e "keycode 49 = 0x3c 0x3e" -e "keycode 94 = 0x5c 0x7c"
Hidden=false
NoDisplay=false
X-GNOME-
Name=remap < and \
Comment=
but it doesn't work (it's for the italian layout if you need it)
If I remember correctly, some time ago I also tried to put a script in /etc/acpi/resume.sh (now probably it should go into /etc/pm/sleep.d/ ) to no avail
and finally, sebastien bacher suggested me to use a gnome-settings- daemon hook: git.gnome. org/browse/ gnome-settings- daemon/ commit/ ?id=2ec0fbd38cd 9d787fc3ad003f4 62c537ea795890
http://
I wrote this small script
#! /usr/bin/env python3
import argparse
from subprocess import check_call as call
from os.path import expanduser
parser = argparse. ArgumentParser( ) add_argument( '-t') add_argument( '-i') add_argument( 'name')
parser.
parser.
parser.
args = parser.parse_args()
if __name__ == '__main__':
call( ["xmodmap" , expanduser( "~/.Xmodmap" )])
try:
if args.t in ("added", "present") and args.i == "10":
#EOF
(I also added some error checking when debugging it, and 10 is the XID obtained from xinput)
and I added it to g-s-d with
gsettings set org.gnome. settings- daemon. peripherals. input-devices hotplug-command '/path/ to/mac_ keyboard_ fix.py'
but apparently, gnome-settings- daemon receives a device-added signal, only for device #11(touchpad) and #14(unknown)
(so, this seems to be denying the hypothesis that the problem is due to the driver loading the keyboard as a completely different keyboard)
right now, I'm not sure why, but when doing a suspend/resume, if I previously applied the xmodmap, the change retains... but in the meanwhile I removed the python script, deactivated the .desktop startup item, and nothing else should be able to change the behaviour after-resume without also changing it after bootup, so I'm quite baffled
I get fed up by this issue every few months, and I try to find a workaround that works once and for all (unless something makes the xmodmap script working, that is)... but now I've spent too much time on this, I just hope that something/somebody will improve the situation in the next months