bjornw

Just recompiled the v7 version for Mavericks. Works fine. I was only able to recompile the debug version, somehow I could't find out how to buid a non-debug version. If someone explains me how I'll recompile the normal version also. Tested with 10.9 DP1 and DP2 no problems found up to now. VoodooPS2Controller.kext.zip BTW Xcode5 Runs fine on ML

Not sure about having to be on Mavericks, but you have to be able to download and run Xcode 5 (maybe it runs on older os x versions...). So one has to be either in the Apple Dev program or be able to get it be some other means (of course I wouldn't have a clue on how to do that... ) Thanks

Hi bpedman, Still happily scrolling all over the place. I've been experimenting with Mavericks a bit. The kext doesn't load on 10.9. Did you update the source on Github with the v7 version? As far as I can see it's not updated right? When I have the latest source code I'll try to recompile on Xcode 5 to see if it will run on Mavericks. cheers

The trackpad is fixed now, see this thread by bpedman https://osxlatitude.com/index.php?/topic/2545-new-touchpad-driver-for-e6520-alps/ side scrolling and two finger scrolling works fine now. I'm quite happy with my N5050 now. almost everything works now. sleep is still a bit buggy, sometimes it won't go to sleep when I shut the lit or use the menu. No real problem, and haven't bothered to research it any further. Ethernet is not working, but since I don't like cables hanging off my laptop and Wifi works fine I don't mind. EDP?

Yep works like a charm! Thanks!

Just sent you a full boot cycle via PM. I've been booting verbose all the time since I started testing your kexts. I have a verbose flag enabled in org.chameleon.Boot.plist. so if there're messages missing they don't show up the system log

Hi bpedman, I tried the the v6 version, I've attached the log. Seems things go wrong here: Jul 10 09:25:08 localhost kernel[0]: ApplePS2ALPSGlidePoint EC Report: { 0x88, 0x07, 0x9d } Jul 10 09:25:08 localhost kernel[0]: ApplePS2ALPSGlidePoint: num nibble commands=1, expexted=1 Jul 10 09:25:28 --- last message repeated 3 times --- Jul 10 09:25:08 localhost kernel[0]: ApplePS2ALPSGlidePoint:: Error reading whether a trackstick is present or notexit command mode Jul 10 09:25:08 localhost kernel[0]: probeTrackstick result: -536870198 Jul 10 09:25:08 localhost kernel[0]: IO error trying to probe for trackstick Jul 10 09:25:08 localhost kernel[0]: exit command mode Jul 10 09:25:08 localhost kernel[0]: ApplePS2ALPSGlidePoint: Device initialization failed. Touchpad probably won't work The kext tries to find a tracktick, but there is none present in the Latitude N5050. I was wondering the same thing when I posted the Linux log a few posts back. See the ubuntu log: I: Bus=0011 Vendor=0002 Product=0008 Version=0000 N: Name="DualPoint Stick" P: Phys=isa0060/serio1/input1 S: Sysfs=/devices/platform/i8042/serio1/input/input7 U: Uniq= H: Handlers=mouse1 event7 B: PROP=0 B: EV=7 B: KEY=70000 0 0 0 0 B: REL=3 Can't I disable the trackstick detection part in the kext somehow? V6log.txt

http://www.projectosx.com/forum/index.php?showtopic=1937 Just to be sure you saw this (you probably have). An old (2011) topic Slice opened about the developement of alps support with voodoops2. Probably Specific's source

For anyone interested, I've been running ML now for a while on my N5050. Most things work. Not working: Ethernet, original WIFI card (replaced It) and Sleep Here's my EXTRA folder. Extra.zip SysLibExt.zip For intallation I used myHack-3.1.2 to make a USB ML install drive. During installation choose Use Custom Extra Folder. Delete the problematic kexts MyHack asks for. After installation I installed some kexts to S/L/E (2nd zip) to get sleep, audio, battery and touchpad working. Touchpad is a work in progress, check bpedman's threat for progress https://osxlatitude.com/index.php?/topic/2545-new-touchpad-driver-for-e6520-alps/

I missed these messages when I tested the V5-2 version of the kext... Seems that my thouchpad writes output to the system.log when I touch it: Jun 10 20:13:31 server kernel[0]: Intercepted bare PS/2 packet..ignoring Jun 10 20:13:31 server kernel[0]: Intercepted bare PS/2 packet..ignoring Jun 10 20:13:31 server kernel[0]: Intercepted bare PS/2 packet..ignoring

I send you a pm with a full boot cycle log, I saw there were a few debug messages i missed before. I sent it by PM because there probably will be private information in there I don't want spread publicly. I trust you'll treat it with respect Small Update: I thuoght I could test Ububtu and see how it would detect my touchpad. So I installed 13.04 on an extrernal HDD and did some testing. in Ubuntu the touchpad works just fine, single and multi touch. I've attached a file with the output of the tests I did. Maybe it helps if you know what output my ALPS trackpad gives when it is working propperly. If it helps I can do additional tests. Let me know what tests on Ubuntu i should run, to help you make the propper adjustments to the kext so it will detect my trackpad in OS X. Cheers Log file ubuntu touchpad.txt

Well different result, but worse than it was . Now the trackpad isn't functioning at all... (keyboard is fine though) No debug messages anymore when I touch it. I've attached a complete system.log of a boot cycle filtered on "PS2". V5-2 ps2 system.log.txt A bunch of reg entries are loaded now (what do they refer to?) Jun 6 17:34:21 localhost kernel[0]: ApplePS2ALPSGlidePoint::identify: Found ALPS Device with ID E7=0x73 0x02 0x64, EC=0x88 0x07 0x9d Jun 6 17:34:21 localhost kernel[0]: ApplePS2ALPSGlidePoint EC Report: { 0x88, 0x07, 0x9d } Jun 6 17:34:21 localhost kernel[0]: ApplePS2ALPSGlidePoint read reg result: { 0x50, 0x00, 0x64 } Jun 6 17:34:21 localhost kernel[0]: ApplePS2ALPSGlidePoint EC Report: { 0x88, 0x07, 0x9d } Jun 6 17:34:21 localhost kernel[0]: ApplePS2ALPSGlidePoint read reg result: { 0x50, 0x00, 0x14 } Jun 6 17:34:21 localhost kernel[0]: ApplePS2ALPSGlidePoint read reg result: { 0x40, 0x02, 0x3c } Jun 6 17:34:21 localhost kernel[0]: ApplePS2ALPSGlidePoint read reg result: { 0x40, 0x02, 0x50 } Jun 6 17:34:21 localhost kernel[0]: ApplePS2ALPSGlidePoint read reg result: { 0x00, 0x02, 0x14 } Jun 6 17:34:21 localhost kernel[0]: ApplePS2ALPSGlidePoint read reg result: { 0x00, 0x02, 0xc8 } Jun 6 17:34:21 localhost kernel[0]: ApplePS2ALPSGlidePoint read reg result: { 0x00, 0x02, 0x0a } Jun 6 17:34:21 localhost kernel[0]: ApplePS2ALPSGlidePoint read reg result: { 0x10, 0x02, 0x3c } Jun 6 17:34:21 localhost kernel[0]: ApplePS2Controller: setCommandByte for mouse interrupt install Jun 6 17:34:21 localhost kernel[0]: ApplePS2Controller: oldCommandByte = 45 Jun 6 17:34:21 localhost kernel[0]: ApplePS2Controller: newCommandByte = 47 How would a log of a successful kext load look like? can someone post an example?

Jun 6 11:39:44 localhost kernel[0]: ApplePS2ALPSGlidePoint::identify: Found ALPS Device with ID E7=0x73 0x02 0x64, EC=0x88 0x07 0x9d Jun 6 11:39:44 localhost kernel[0]: ApplePS2ALPSGlidePoint EC Report: { 0x88, 0x07, 0x9d } Jun 6 11:39:44 localhost kernel[0]: ApplePS2ALPSGlidePoint read reg result: { 0x50, 0x00, 0x64 } Jun 6 11:39:44 localhost kernel[0]: ApplePS2ALPSGlidePoint EC Report: { 0x88, 0x07, 0x9d } Jun 6 11:39:44 localhost kernel[0]: ApplePS2ALPSGlidePoint read reg result: { 0x50, 0x00, 0x14 } Jun 6 11:39:44 localhost kernel[0]: ApplePS2ALPSGlidePoint read reg result: { 0x40, 0x02, 0x3c } Jun 6 11:39:44 localhost kernel[0]: ApplePS2ALPSGlidePoint ERROR: read wrong registry value, expected: 6 Jun 6 11:39:44 localhost kernel[0]: ApplePS2ALPSGlidePoint: Device initialization failed. Touchpad probably won't work this what happens now, so it does read another reg value, but that doesn't change the outcome.

it was me, I already saw that you posted the code location on github in your first post, I oversaw it at first. when I found it, I edited my post, no reason for asking something that's already clear I already had a look at the file you mentioned, but it's a bit above my programming skills Really appreciate your efforts though! cheers

The V5 version looks to be doing more or less the same for me. The only difference I see is here: Jun 5 10:57:36 localhost kernel[0]: ApplePS2ALPSGlidePoint EC Report: { 0x88, 0x07, 0x9d } Jun 5 10:57:36 localhost kernel[0]: ApplePS2ALPSGlidePoint read reg result: { 0x50, 0x00, 0x64 } Jun 5 10:57:36 localhost kernel[0]: ApplePS2ALPSGlidePoint ERROR: read wrong registry value, expected: 8 Jun 5 10:57:36 localhost kernel[0]: ApplePS2ALPSGlidePoint EC Report: { 0x88, 0x07, 0x9d } Jun 5 10:57:36 localhost kernel[0]: ApplePS2ALPSGlidePoint read reg result: { 0x50, 0x00, 0x14 } Jun 5 10:57:36 localhost kernel[0]: ApplePS2ALPSGlidePoint ERROR: read wrong registry value, expected: 4 Used to be in the V4 version: Jun 3 09:32:00 localhost kernel[0]: ApplePS2ALPSGlidePoint EC Report: { 0x88, 0x07, 0x9d } Jun 3 09:32:00 localhost kernel[0]: ApplePS2ALPSGlidePoint read reg result: { 0x50, 0x00, 0x64 } Jun 3 09:32:00 localhost kernel[0]: ApplePS2ALPSGlidePoint ERROR: read wrong registry value, expected: 8 Jun 3 09:32:00 localhost kernel[0]: ApplePS2ALPSGlidePoint EC Report: { 0x88, 0x07, 0x9d } Jun 3 09:32:00 localhost kernel[0]: ApplePS2ALPSGlidePoint read reg result: { 0x50, 0x00, 0x64 } Jun 3 09:32:00 localhost kernel[0]: ApplePS2ALPSGlidePoint ERROR: read wrong registry value, expected: 8 So " 0x14 " is now " 0x64 " and " expected: 8 " is now " expected: 4 " Not sure this is significant. I also Noticed that the VoodooPS2synapticsPane.prefPane Doesn't save settings after reboot, maybe this has to do with not propperly loading the kext. After reboot, it goes back to default settings. Like miguelme777 my n5050 has no stick. basically n5050 (mine) is the same as his n5040 (miguelme777) Different cpu, hdd and RAM, but the rest is the same Here's complete log output with the v5 version (filtered the system.log on "PS2") of anything trackpad related. (attached it to the post to keep the thread better readable). Would like to contribute more than just testing, is there anything I can do? Look at the source code maybe? Any advice on where to start? V5 log.txt SMALL UPDATE: Did a clean install on a other HDD, just to make sure that my current installation wasn't the source of the error. It didn't change anything though, same log entries as mentioned above.