bpedman

Great, thanks for testing that out...I have a list of things to start looking at soon, I think fixing the preference saving stuff will be the first

Hey everyone, just wanted to let you know I am monitoring this thread still. I just have not had time to work on this at all and haven't had any quick answers to the issues that have come up. However, RehabMan has attempted a merge of my changes with his stuff. I just posted the merged build on the first post. I don't have my laptop with an ALPS driver anymore so I can't test it out. If you guys could try out the build and see if there are any problems that would be really helpful. That way I can let him know if anything went wrong with the merge or not.

I just use the makefile and run make from the command line to build it. It builds both the release and debug versions.

Ah got it. Makes sense why I couldn't see it to download then.

Whoops, you are right. Forgot about that. Just pushed up the source. Guess it looks like you have to be on Mavericks to even build for it, is that right? I didn't see an SDK out yet which makes sense since it isn't released yet.

OK, just added another update. I fixed up the refactoring I did in v6. It should now properly support those models that don't have a trackstick. The new driver is posted as v7 on the original post. Thanks go to bjornw for helping me debug the issues with this and get it working!

Well, there is a method which is supposed to safely detect whether the trackstick is present or not. It just reads a registry value and based on the registry value it will tell us whether or not the trackstick is present. The linux driver does the same exact thing. Also, the reason that the linux driver says "DualPoint Stick" is because there is a flag that is set for this model (0x88 0x07 0x9d) and actually most all of the ALPS models, that says it is a dual point device. When setting the name of the device, if the flag is set it will set the name to DualPoint Stick....so it really doesn't have anything to do with whether there actually is a trackstick present or not. I can ignore the error during detection but I am pretty sure you will run into problems right after the detection when it tries to read and set more register values. There is something not working right in the command mode when it is setting and reading the register values. So there may or may not be a log message missing here. There should have been some error printed about why reading the register failed...looking at the code I can see 1 place where the error may have happened that I didn't have a log message. I updated the driver to add a log message there. Would you mind trying again just so I can verify that it is getting an error where I think it is? I have attached the file to this post. Sorry I missed that...it could also be that the system log is dropping some log messages because it spits them out too fast...hope thats not the case...booting in verbose mode may help if that is the case. ALPS-TouchPad-Driver-v6.1.zip

Weird. What did you do when you captured the attached log? Just a 1 finger swipe down or up? What is strange here is the z value reported only goes as high as 25, this is the amount of pressure sensed by the touchpad. By default the driver is setup so that it ignores anything below 45, this is why you are having to press extremely hard to get it to move. If you are able to you may want to use the pref pane and change the sensitivity. I haven't tried myself but it sounds like others have had to make some adjustments in the pref pane to get it working OK. If you can search the log for "Found ALPS Device with ID" and paste that line it would be helpful. If the ID is different from others I can put something in to automatically reduce the ignored z value for that model.

Interesting...just realized several people have mentioned this now. I haven't touched any of the pref pane code from ReHabMan's version, I can try and poke around and see what I can find though.

OK, sorry for the hiatus. I have 2 jobs right now and my family to take care of and finding time is difficult for this, sorry. I made another change that I hope will help bjornw and miguelme777 (and maybe others?). There was a potential error occurring in the way I handled the command mode when it was sending special little byte sequences to the touchpad. I hope to have fixed that with this and I hope that it fixes the issues for you guys. This will only affect people with a v3/v4 protocol version touchpad, which is more of the newer ones within the last couple years I believe. If you are curious about the gritty details, basically I was confused about how the linux driver processes sending and receiving extra data after the primary command is sent to the mouse. I was always confused because some of the mouse commands in the linux driver used 2 bytes while the constants in ReHabMan's driver were only 1. Well that extra byte in the linux version gave information about the amount of data to send and receive after the initial command was sent. I made the translation for the nibble commands that are used in command mode for this driver. There may be other areas in the driver affected by this now too that I may need to visit, but the errors from bjornw and miguelme777 were in this area. The new driver is on the OP, v6. I kept v5 around in case v6 doesn't work right. I have not tested it out to confirm if it works.

This is awesome. Thanks for finding this. I will have to analyze this more later and compare to what I am doing right now. Yeah, I saw that a long time ago...forgot about that...I will have to look through his code some more. I wonder if it is any different than the one here https://github.com/AppleLife/VoodooPS2

Hmm, that's really weird...not sure what that message means. I haven't touched the preference pane code from what ReHabMan has done though so might be something to ask him? Also, I tried compiling for 32 and 64 bit but it is broken right now. I would have to make some changes to enable it to work on 32-bit. How important is having 32-bit support?

Sweet, thanks for that log from ubuntu. Didn't even know about that evtest tool, that is pretty nifty....wish I would get updates from the forum on when a post has been modified...didn't get an email when you added that. Also, about the ignored ps/2 packets. On my touchpad I had to ignore them because otherwise my mouse movement was all crazy. I believe the touchpad sends interleaved ALPS and PS/2 packets but apparently yours is only sending the PS/2 packets right now, which kind of makes sense because the initialization is probably not working correctly. What I really need is a dump of all the data that it sends to the touchpad during initialization. I don't know how to get that info though....anyone know?

Thanks for the log...some of my log messages don't have PS2 in them though unfortunately...I should probably fix that...any way I could get the whole log?

Sheesh...well, OK, so I removed all error checking here for this model then. Dunno what is going on. You will have to see what happens after all the initialization is complete. Thanks a bunch for testing this out so much, hopefully we can get a good driver working for everybody. New version attached ALPS-TouchPad-Driver-v5.2.zip