Voodooprojects
VoodooPS2Controller => Bug Reports => Topic started by: BladeRunner on April 14, 2009, 10:35:37 PM
-
I installed the VoodooPS2Controller kext several days ago and it appeared to be working corectly. That is a good thing because it allowed me to remove the patched versions of ApplePS2Crontroller and ApplePS2nub I had been using.
However I just noticed to day that one of the keys has a new value set from what it had before. In the upper left, the key above the Tab key is labeled and used to produce a back tick or tilde depending on the state of the shift key. Now, however, it produces a § and a ± depending on the shift key.
I looked in the two Info.plist files in the kext contents to see if there was a value there that would correct this - no joy. Does anyone know haw to change the key value back without removing VoodooPS2 controller?
-
I noticed this also. This is more or less what happened to me with the F12 and the Eject key. Now i cannot eject dvds by keeping F12 pressed. And now the back tick or tilde is somewhere else.
-
mine also
the key next to 1 is altered
i had to change the keyboard shortcuts to re-enable the "switch thru windows" cmd
-
I also have the "eject/F12 key" issue, the key at left to 1 does nothing, and my backlight control (Fn + F7/F8) is broken. Adding PNLF in DSDT never helped.
-
I have learned that there are some places where keyboard layouts are placed. One, for the system is placed in /Library/Keyboard Layouts. The other, for an individual user is /Users/your-id/Library/Keyboard Layouts. Both folders exist on my system and both appear to be empty.
This looks like a place to put configuration data, but I never came across the file name or syntax. If anyone knows more about this, could you please provide some pointers?
-
You can use Ukulele for remapping keys (you'll get a *.keylayout file to place in ~/Library/Keybord Layouts. The new layout will appear in the Input Menu (International prefpane).
I use it because I have a french azerty pc keyboard.
I'm not sure it will fix the F12/eject issue though.
EDIT: You can solve the missing "next to the 1 key" with Ukulele but the F12/Eject issue can't be solved this way.
-
Yes, I got a copy of Ukulele and it did fix the problem. It took several attempts to learn how to use the program to swap two key sets, but once I learned that it was easy to get back my ~ and ` characters. Thanks for the pointer.
-
While you can most certainly use Ukelele to fix this this is a bug in the actual kext considering that the ~ key is standard on all 101 key US keyboards and there is not a § key. macgirl has already patched this.
http://forum.voodooprojects.org/index.php/topic,141.msg561.html#msg561
-
I have no explanation for this, but my keyboard has reverted to the starting point. Even though I have the key layout file in "/Library/Keyboard Layouts", it no-longer shows up in the Preferences -> International and the keys are now "§" and "±" inplace of back-tick and tilde.
The layout I made with Ukelele worked just fine for about 3 days and then stopped. ???????? I got the source for VoodooPS2Controller and will try to patch it locally.
-
BladeRunner I have attached my kext that is already patched properly. I like having my Windows key default to the Command key on my keyboards so the kext is also configured that way. If you would rather your alt key be your command key you can change the setting back in the VoodooPS2Keyboard.kext Info.plist
-
Many thanks. I had been experimenting with the Logitech US International layout that came with Ukelele with some success. I will give this one a try. It would be better if the kext worked directly - without the International layouts.
-
There are two US keyboard layouts: the 102 key (I think, I didn't count ;) ) which has the tall return key on the right hand side and moves the pipe and backslash key next to the single and double quote key, and then there's the 101 key keyboard, with a wide return key, that's only a standard key high.
The former of these two has the paragraph sign next to the 1 key, because the left shift key is smaller such that there is space for the backquote/tilde key between it and the z key.
The latter has the backquote/tilde key next to the one key. I attach pictures that show the Mac OS X keyboard viewer's display of both types of keyboard. The kext recognizes the 102 key version, even if what's present is the 101 key version. So what needs to be changed is the detection code, not a patch that returns a different character for the key.
The fact that the wrong keyboard is recognized you can double check by using the keyboard viewer from the input method menu, and you will see that it shows you a 102-key style keyboard.
-
BladeRunner I have attached my kext that is already patched properly. I like having my Windows key default to the Command key on my keyboards so the kext is also configured that way. If you would rather your alt key be your command key you can change the setting back in the VoodooPS2Keyboard.kext Info.plist
What is patched? The keyboard recognition code, or are just the keycodes being hard-swapped?
Because as I have documented in a previous post, the problem is that the wrong type of keyboard is recognized, not that for the type of keyboard that the extension thinks it has it returns the wrong key codes...
I'd love to see this fixed for real, i.e. have the keyboard type recognition being patched...
-
The kext recognizes the 102 key version, even if what's present is the 101 key version. So what needs to be changed is the detection code, not a patch that returns a different character for the key.
The problem is that there isn't any keyboard layout detection feature on PS2Keyboard.kext
Keyboard layout recognition is selected by examining IORegistry's HIDSubinterfaceID
Here is a part of updated VoodooPS2Keboard.cpp
//#define APPLEPS2KEYBOARD_DEVICE_TYPE 205 // Generic ISO keyboard
#define APPLEPS2KEYBOARD_DEVICE_TYPE 3 // Unknown ANSI keyboard
...
UInt32 ApplePS2Keyboard::deviceType() {
OSNumber *xml_handlerID;
UInt32 ret_id;
if ( xml_handlerID = OSDynamicCast( OSNumber, getProperty("alt_handler_id")) )
ret_id = xml_handlerID->unsigned32BitValue();
else
ret_id = APPLEPS2KEYBOARD_DEVICE_TYPE;
return ret_id;
};
It just retrurn the APPLEPS2KEYBOARD_DEVICE_TYPE value or user assigned value in Info.plist without any detection process. It determines HIDSubinterfaceID value.
I read below sites. There are some start point for recognizing keyboard layout automatically.
http://www.win.tue.nl/~aeb/linux/kbd/scancodes-12.html#kcf2
http://www.win.tue.nl/~aeb/linux/kbd/scancodes-10.html#keyboardid
-
So if I understand that patch correctly, you just changed the default keyboard, but you didn't prevent a different keyboard from being used, should such a different keyboard type be indicated in the IORegistry?
The problem is that there isn't any keyboard layout detection feature on PS2Keyboard.kext
Keyboard layout recognition is selected by examining IORegistry's HIDSubinterfaceID
It just retrurn the APPLEPS2KEYBOARD_DEVICE_TYPE value or user assigned value in Info.plist without any detection process. It determines HIDSubinterfaceID value.
Is that something that could be fixed with EFI string injection or something like that?
At least that would be a useful interim solution...
I read below sites. There are some start point for recognizing keyboard layout automatically.
http://www.win.tue.nl/~aeb/linux/kbd/scancodes-12.html#kcf2
http://www.win.tue.nl/~aeb/linux/kbd/scancodes-10.html#keyboardid
Of course, if that would actually be implemented, it would be ideal...
Thanks for the answers!
-
So if I understand that patch correctly, you just changed the default keyboard, but you didn't prevent a different keyboard from being used, should such a different keyboard type be indicated in the IORegistry?
What you mean? I can't follow you. For preventing a different keyboard, it needs to be implemented feature that I already said.
You can just change 'alt_handler_id' of VoodooPS2Keyboard.kext/Contents/Info.plist.
http://forum.voodooprojects.org/index.php/topic,304.0.html
But it is needed to update /System/Library/Extensions.mkext again.
So, if you use various layout PS/2 keyboard and switch it often, 'alt_handler_id' method would be annoying work.
By the way, if keys are entered correctly, how about you might ignore Keyboard viewer's layout?
In my case, I use a thinkpad laptop's internal PS/2 keyboard. I don't have a extra keypad. But keyboard viewer shows a keypad. But I ignore it. Because it doesn't make any problem to use OS X.
Is that something that could be fixed with EFI string injection or something like that?
I don't know. Maybe it could be done by EFI injection. ::)
But there are another way to dynamic method.
Trying to use KeyRemap4Macbook
http://forum.voodooprojects.org/index.php/topic,398.0.html
I saw vpower or pstate in VoodooPower project.
It can change cpu state online. I think that kind feature can be adapted into VoodooPS2Keyboard.kext to change some various values.
I'm not a good coder. I hope someone adapt that kind of solution into VoodooPS2Keyboard.kext
-
So if I understand that patch correctly, you just changed the default keyboard, but you didn't prevent a different keyboard from being used, should such a different keyboard type be indicated in the IORegistry?
What you mean? I can't follow you. For preventing a different keyboard, it needs to be implemented feature that I already said.
Well, you had listed a piece of code that you said was changed, and the definition of APPLEPS2KEYBOARD_DEVICE_TYPE changed from 205 to 3 in that line. I understood this to alter the default keyboard type from a 102 to a 101 key keyboard.
You can just change 'alt_handler_id' of VoodooPS2Keyboard.kext/Contents/Info.plist.
http://forum.voodooprojects.org/index.php/topic,304.0.html
But it is needed to update /System/Library/Extensions.mkext again.
So, if you use various layout PS/2 keyboard and switch it often, 'alt_handler_id' method would be annoying work.
OK, I'll check that out...
For me, only the default keyboard matters, since when I hook up an external USB keyboard, it seems to be recognized correctly, it's just the built-in PS2 keyboard that has an issue...
By the way, if keys are entered correctly, how about you might ignore Keyboard viewer's layout?
In my case, I use a thinkpad laptop's internal PS/2 keyboard. I don't have a extra keypad. But keyboard viewer shows a keypad. But I ignore it. Because it doesn't make any problem to use OS X.
Well, your keyboard shows a numeric keypad, because when you use the Fn keys, it will generate these key codes. The software doesn't know about the physical layout, but about they key codes that the keyboard can generated, and using the Fn keys, you can generate the codes of the separate keypad, which is important since some apps assign special functions to these keys (e.g. terminal emulators that emulate a VT100 keypad).
Also, the keyboard layout matters because different keys have different characters on them. That's really the issue here, because the key next to the number 1 key has ~ and ` on it on a 101 key keyboard, but it has § and ± on it on a 102 key keyboard. The key with the ~ and ` on it is next to the letter z on the 102 key keyboard, and that key is plain missing on a 101 key keyboard.
Therefore to reprogram what character is returned would cause the improper behavior when a real 102 key keyboard is attached, since it now would no longer return the required § and ± keys at that location, but would return ~ and ` instead.
If you look at the images in detail that I attached to one of my prior posts, you will see what I mean. The "wrong" keys returned right now are actually the right keys given what keyboard the software thinks is attached. What is wrong is that it thinks a 102 key keyboard is attached, when in fact it's a 101 key keyboard, or a laptop keyboard that emulates a 101 key keyboard by using the Fn keys to create a pseudo keypad.
-
First of all, I'm not a good English speaker. There are mis-understanding between you and me.
And I can't express all thing that I think and I know to English well.
So if I understand that patch correctly, you just changed the default keyboard, but you didn't prevent a different keyboard from being used, should such a different keyboard type be indicated in the IORegistry?
What you mean? I can't follow you. For preventing a different keyboard, it needs to be implemented feature that I already said.
Well, you had listed a piece of code that you said was changed, and the definition of APPLEPS2KEYBOARD_DEVICE_TYPE changed from 205 to 3 in that line. I understood this to alter the default keyboard type from a 102 to a 101 key keyboard.
I mean below site. Not the code.
http://www.win.tue.nl/~aeb/linux/kbd/scancodes-12.html#kcf2
http://www.win.tue.nl/~aeb/linux/kbd/scancodes-10.html#keyboardid
You can just change 'alt_handler_id' of VoodooPS2Keyboard.kext/Contents/Info.plist.
http://forum.voodooprojects.org/index.php/topic,304.0.html
But it is needed to update /System/Library/Extensions.mkext again.
So, if you use various layout PS/2 keyboard and switch it often, 'alt_handler_id' method would be annoying work.
OK, I'll check that out...
For me, only the default keyboard matters, since when I hook up an external USB keyboard, it seems to be recognized correctly, it's just the built-in PS2 keyboard that has an issue...
USB keyboard isn't related with VPS2 at all. It is worked with IOHIDKeyboard.cpp part in IOHIDFamily.kext.
So, its layout is recognized and worked independently from VoodooPS2Controller. When you press any key from USB, Keyboard Viewer's layout changed promptly. After when you press any key from PS/2, it is changed too.
If you have one PS/2 keyboard, the problem is simple.
By the way, if keys are entered correctly, how about you might ignore Keyboard viewer's layout?
In my case, I use a thinkpad laptop's internal PS/2 keyboard. I don't have a extra keypad. But keyboard viewer shows a keypad. But I ignore it. Because it doesn't make any problem to use OS X.
Well, your keyboard shows a numeric keypad, because when you use the Fn keys, it will generate these key codes. The software doesn't know about the physical layout, but about they key codes that the keyboard can generated, and using the Fn keys, you can generate the codes of the separate keypad, which is important since some apps assign special functions to these keys (e.g. terminal emulators that emulate a VT100 keypad).
It's not the point to refer my keyboard example. I should not have metioned it. Sorry : )
Anyway what did you mean Fn key? In thinkpad's one? or Apple's one? It's totally differant thing.
Also VT100 isn't related VPS2. Because nowadays OS X never know PS/2 Keyboard, and there are not any PS/2 scan-code supports. Nothing.
Also, the keyboard layout matters because different keys have different characters on them. That's really the issue here, because the key next to the number 1 key has ~ and ` on it on a 101 key keyboard, but it has § and ± on it on a 102 key keyboard. The key with the ~ and ` on it is next to the letter z on the 102 key keyboard, and that key is plain missing on a 101 key keyboard.
Therefore to reprogram what character is returned would cause the improper behavior when a real 102 key keyboard is attached, since it now would no longer return the required § and ± keys at that location, but would return ~ and ` instead.
If you look at the images in detail that I attached to one of my prior posts, you will see what I mean. The "wrong" keys returned right now are actually the right keys given what keyboard the software thinks is attached. What is wrong is that it thinks a 102 key keyboard is attached, when in fact it's a 101 key keyboard, or a laptop keyboard that emulates a 101 key keyboard by using the Fn keys to create a pseudo keypad.
Your former attached picture is a ISO layout. It can be seen well in Europe countries.
Improper situation is considered some point of view.
1. Does each keys actually make proper PS/2 scancode like standard scancode which was printed on keycap character?
2. When press the key, does it make proper character on OSX?
3. When press the key, is it assigned proper position on OSX's Keyboard viewer?
So... read my thread 'Europe ISO layout keyboard' part. And try it.
http://forum.voodooprojects.org/index.php/topic,304.0.html
If you have a improper working with enabling "Use ISO layout keyboard" option, try below method please.
Because I've never seen ISO PS/2 keyboard. I want to know the two keys.
I wonder what is the PS/2 scancodes for '§±' and '~`' key each on 102 ISO PS/2 keyboard.
I think that '§±' makes 0x56 and '~`' makes 0x29.
Use below debug VoodooPS2Controller.kext version.
How to capture the PS/2 Scan Code with attached kext.
1. Install attached kext. (If you want, use kext helper.( http://www.cheetha.net/Kext_Helper/Software.html ) or install manually)
2. After reboot, open Console.app. Select 'System.log'.
3. Press '§±' and '~`' keys one time each.( you don't have to input shift key. )
4. Capture the messages like 'ApplePS2Keyboard: PS/2 scancode 0x??'.
?? value is PS/2 scan code for these keys. Look at below example picture.
* You realize that Keyboard viewer doesn't make debug message, when you click the Keyboard viewer's key.
That means it isn't related with physical PS/2 Keyboard at all
When you reply the test result, I will fix the VPS2.
P.S.
I modify superhai's vpower source code into vps2kbd.
It change HIDSubinterfaceID online.
You can change whatever you want. Refer to below link for choosing keyboard_id
http://forum.voodooprojects.org/index.php/topic,115.msg1071.html#msg1071
-
OK, first off, thanks for all your help.
Second, things work.
Third, I wasn't aware of the updated kexts you posted in the thread http://forum.voodooprojects.org/index.php/topic,304.0.html (http://forum.voodooprojects.org/index.php/topic,304.0.html) here, and so all the problems I was reporting were with the version posted here: http://forum.voodooprojects.org/index.php/topic,235.0.html (http://forum.voodooprojects.org/index.php/topic,235.0.html)
When I downloaded and installed this one http://forum.voodooprojects.org/index.php?action=dlattach;topic=304.0;attach=257 (http://forum.voodooprojects.org/index.php?action=dlattach;topic=304.0;attach=257) thinks worked as expected right away, without any modifications.
Also, with the new kext it's possible to use the keyboard type detection scheme in the System Preferences' Keyboard preference pane.
So as far as I'm concerned, all seems to be OK, with the 20090511 version.
Thanks again!
-
I'd happy to hear that you had a good result. : )
Also, with the new kext it's possible to use the keyboard type detection scheme in the System Preferences' Keyboard preference pane.
P.S.
There is a caveat. Specially when you choose Japanese JIS layout.
Japanese JIS layout has some special keys such as "Ro", "Yen", Kana, Eisu.
I guess that "Ro" and "Yen" entered only when NXSystemInfo's HIDSubinterfaceID key was properly set.
If not, IME make error such as "exception in IMKServer: NSInternalInconsistencyException Non-Unicode event without Carbon EventRef (null)"
And after you change keyboard layout by System Preferences , Keyboard viewer show layout which you choose when you enter the keys. At that time if you click Keyboard viewer's key, it goes back to default layout.
It comes from mis-match HIDSubinterfaceID value between IOHIDSystem and ApplePS2Keyboard.
Keyboard viewer's layout is determinded by IOHIDSystem's HIDSubinterfaceID value.
It copies ApplePS2Keyboard's HIDSubinterfaceID value when system was booting. But inconsistency is happend when you change layout using System Preferences or vps2kbd online.
I'm trying to access NXSystemInfo's HIDSubinterfaceID. But it failed yet.
I want to someone sovle this problem.