Installed OpenSuSE 13.1 as a fresh install and the keyboard’s ALT and Meta keys are not working. The Control key is working as expected. Xev picks up the individual keys plus these keys work as expected in OpenSuSE 12.3 and OS X. Where would I begin to look to find out why 13.1 seems to have an issue with this keyboard?
I am perplexed. Google searches show little results as 13.1 is rather new to date.
Thanks in advance.
I assume you are aware of he fact that not many people have the same problem, else these forums would have been swamped with threads about it. Thus it must be more or less unique for you. Thus it may have something to do with your hardware. Thus it might be nice if you told more about your system and specialy about the keyboard.
Yes, that would be logical, and apologies for not providing that info before.
OpenSuSE 13.1 is installed as the only OS on an Apple iMac 12,1 (quad-core i5, AMD HD6750M GPU) from July 2011. The keyboard being used is a USB Apple Extended Macintosh keyboard that shipped with iMacs and Power Macs of the 2002 vintage. OS X Mavericks and OpenSuSE 12.3 are installed on their own external hard drives, each capable of booting the iMac on their own. Both OpenSuSE versions, using kinfo, and OS X, using System Profiler, show this keyboard to be of a Mitsumi type but no other model info is available. Prior to installing OpenSuSE 13.1, the 12.3 version was the primary OS on the iMac’s internal drive.
Currently, the keyboard works flawlessly with both OpenSuSE 12.3 and OS X Mavericks. The Shift, Control, Option/Alt, and Command/Windows keys, on both the right and left sides of the board work as expected for all keyboard shortcut combinations. However, when booted into OpenSuSE 13.1, only the Shift and Control keys on both sides of the board function correctly, the Option/Alt and Command/Windows keys on both sides are seemingly ignored.
By ignored, I mean that using those keyboard shortcuts needing those keys, like switching to virtual consoles for example, does not work.
Using Xev in both 12.3 and 13.1 shows identical key code presses for those keys.
I thought that since the home directory being used on 13.1 is a clone of what I created under 12.3, there might be an incompatible hidden file of some sort that is causing this. I looked but did not see anything that stood out as a potential target. This issue is present no matter what window manager or desktop environment I use: iceWM, Enlightenment, XFCE, or KDE Plasma are the four currently installed.
I realize this may be a “fringe” system… running OpenSuSE natively on a recent iMac… but OpenSuSE has worked very well as a nearly perfect drop-in replacement OS for this machine. OpenSuSE’s EFI works well with the Apple EFI; something that no other linux distro seems to do. Despite these keys on the keyboard not currently working, 13.1 is otherwise working with no other issue.
Like you, I am waiting now for some time for someone being able to start helping you. In vain.
While I do not know if very many people having your situation (hardware) are watching here, I suggest we change the title of this to something like:
OpenSuSE 13.1 on Apple iMac: Keyboard’s Alt and Meta keys not working
To have a better advert to your case.
Hey there. I am having a similar problem with my macbook pro 13" '12 since my upgrade to opensuse 13.1 yesterday. I have been triple booting since I first got my laptop, it is not too bad. But opensuse is definitely the best OS to do this out there, and my choice for almost a year now.
But i digress. Unlike your problem, it is only my alt key which misbehaves on my computer. Although presses to the alt key are registered by xev, they do not function on the desktop. It is not misinterpreted as another key, it is simply ignored by the system (although x apparently knows these are presses to key alt).
I can also say that this is not about the keyboards themselves: my laptop’s onboard keyboard does not solve the problem, and neither does a logitech usb (pc) keyboard. Your case eliminates another native keyboard.
Of course, one can remap shortcuts, but that is no solution. I will keep following this thread, and also inform you if i find out anything useful.
Cheers
Having a similar problem: None of the number keys work on the number pad (NumLk on or off). Enter key works. “0” causes application to lock up and won’t respond to ESC. Arrow keys work. Alt and Ctl work fine. Very annoying.
Lenovo AMD Athlon II x4, openSUSE 13.1, 64-bit
This is not similar. You are not even using a Mac and the rest of the description is also different.
When you want people to help you with this, then please start a new thread, give it a title that tells people in short what it is about and give a good description of the problem. That will give youthe best chance that people will see your problem. As it is now, it is hidden inside some other problem. Ba advertisement for your problem.
Okay, I have solved my problem, let’s see if it helps you too.
First and foremost, my claim that “x knows it is the alt key” was not completely true. I did not inspect the xev output properly. Here is the sample output after pressing left alt and right alt, respectively:
KeyPress event, serial 40, synthetic NO, window 0x5400001,
root 0xa2, subw 0x0, time 88340, (67,-15), root:(821,8),
state 0x10, keycode 64 (keysym 0xfe03, ISO_Level3_Shift), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
KeyRelease event, serial 40, synthetic NO, window 0x5400001,
root 0xa2, subw 0x0, time 88436, (67,-15), root:(821,8),
state 0x90, keycode 64 (keysym 0xfe03, ISO_Level3_Shift), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False
KeyPress event, serial 40, synthetic NO, window 0x5400001,
root 0xa2, subw 0x0, time 89884, (67,-15), root:(821,8),
state 0x10, keycode 108 (keysym 0xfe03, ISO_Level3_Shift), same_screen YES,
XKeysymToKeycode returns keycode: 64
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
KeyRelease event, serial 40, synthetic NO, window 0x5400001,
root 0xa2, subw 0x0, time 89956, (67,-15), root:(821,8),
state 0x90, keycode 108 (keysym 0xfe03, ISO_Level3_Shift), same_screen YES,
XKeysymToKeycode returns keycode: 64
XLookupString gives 0 bytes:
XFilterEvent returns: False
As one can see, neither are really recognized as proper alt keys but as 3rd level shortcut triggers (ISO_Level3_Shift). I missed this the first time because I was only looking at keycodes, which of course return different results for different keys, regardless of the mapping. So, both my alt keys were mapped to ISO_Level3_Shift… That reminded me of a setting in the keyboard settings at kde control module.
I navigated to “KDE Control Module->Keyboard”, and in “Layouts” tab, I saw that my 3rd level shortcuts are assigned to “Any Alt key”, and subsequently there was no binding that was functionally Alt_L or Alt_R! I cleared that option to “None” to see what happens, and voila! I have my alt key back. Now xev reports this for my left and right alt keys:
KeyPress event, serial 40, synthetic NO, window 0x5a00001,
root 0xa2, subw 0x0, time 1138019, (-114,637), root:(640,660),
state 0x10, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
KeyRelease event, serial 40, synthetic NO, window 0x5a00001,
root 0xa2, subw 0x0, time 1138083, (-114,637), root:(640,660),
state 0x18, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False
KeyPress event, serial 40, synthetic NO, window 0x5a00001,
root 0xa2, subw 0x0, time 1139307, (-114,637), root:(640,660),
state 0x10, keycode 108 (keysym 0xffea, Alt_R), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
KeyRelease event, serial 40, synthetic NO, window 0x5a00001,
root 0xa2, subw 0x0, time 1139395, (-114,637), root:(640,660),
state 0x18, keycode 108 (keysym 0xffea, Alt_R), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False
I don’t know if this problem exists for non-Macs, but I doubt it. Otherwise these pages would be overflowing with desperate people.
This solved my problem, and perhaps it can at least alleviate the alt-key portion of your problem. Good luck!
PS: Can you perhaps the output of xev when you press your alt and meta keys? Perhaps there is something you are missing there, like I was missing in mine. Also, I agree with the other poster that you should change the title to include that this is probably a Mac thing. As I, and the other poster, have said, otherwise this thread would be pages long by now.
Good analysing. Must be satisfactory you found it. And thanks for reporting back for the benifit of other users.
I changed the Title (I hope this is done correctly).
Thank you to all who had input into my original problem. I have since returned to an all OS X system and no longer have the keyboard issue. Even the KDE fix posted earlier was not a fix for me so I am just chalking this up to an oddity with the particular model of Mac keyboard I was using at the time.
I’ve found a different solution for my old Macbook on openSUSE 13.1
In /etc/X11/xorg.conf.d/90-keytable.conf you’ll find the following line:
Option "XkbOptions" "altwin:swap_lalt_lwin,lv3:alt_switch"
Either remove it, or replace it with something sane like:
Option "XkbOptions" "compose:rwin"
Afterwards, restart your X server. e.g. rebooting, or hitting Ctrl+Alt+Backspace, or running:
/etc/init.d/xdm restart; exit
in the console.
Now your keys should work as they should.
Te compose:rwin trick actually lets you type special characters easily on Linux. You can type € by hitting rwin, E, = sequentally for example. ß by hitting rwin, s, s. The XbkOptions have the same effect as the advanced keyboard settings in KDE. The only difference this, this works system-wide for all users.