bpedman
Members-
Posts
65 -
Joined
-
Last visited
-
Days Won
5
Content Type
Profiles
Articles, News and Tips
Forums
Everything posted by 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
-
Weird, so it is getting past the trackstick probe now but it is still having issues with the result from reading a register. In the linux driver it states that the first and second bytes should come back representing the address that was read from. However, in your case it is always coming back as 0x50 0x00. I stuck a little workaround in for this so that if the version is v3 and the first and second bytes come back as 0x50 0x00 then I will treat it as acceptable. Give it a shot, attached to this post ALPS-TouchPad-Driver-v5.1.zip
-
OK, I will look again. I know where this is happening, something is being handled wrong when it probes for the trackstick. Also, can't remember if it was you or someone else that asked, but yes the code is up on github, the link is is the first post...but here is the link too so you don't have to go look at the first post as well: https://github.com/bpedman/OS-X-Voodoo-PS2-Controller The file you would want to look at is https://github.com/bpedman/OS-X-Voodoo-PS2-Controller/blob/master/VoodooPS2Trackpad/VoodooPS2ALPSGlidePoint.cpp
-
OK, I have uploaded a new version. This should fix some issues for everyone. I think I am correctly probing for a trackstick now, so it should properly initialize when the trackstick isn't present. I also refined some of the v1/v2 model stuff so that should work better as well. Give it a shot, the new version is on the original post marked as v5, once I get some verification it works OK I will remove the v4 download.
-
Weird..well, that makes a lot of sense now. I will make some adjustments for that so that it won't fail if setting up the trackstick fails.
-
@bjornw So the daemon doesn't do much, it just monitors the number of mouse devices (i.e. you may have a USB mouse attached as well). I am not exactly certain what the number of mice actually triggers though. I do see that there is a case where it can be used to turn off the touchpad but I am not sure when that occurs. It may have to do with the preference pane option where it will turn off the trackpad if another mouse is present. Interesting that it fails to initialize. I have the same exact model on mine, same E7 and EC response, everything works fine. It is failing while trying to initialize the trackstick. You guys have a trackstick along with the trackpad right?
-
Could you look at /var/log/system.log and look for a line that says: "Found ALPS Device with ID....." and paste that here. I would like to know what the model is. It sounds somewhat similar to what driedger reported here https://osxlatitude.com/index.php?/topic/2545-new-touchpad-driver-for-e6520-alps/page-2&do=findComment&comment=19378. Need to know what model it is so I know where to make any changes.
-
That's great. Could you look at /var/log/system.log and look for a line that says: "Found ALPS Device with ID....." and paste that here. I would like to keep track of models that are working and have been tested. Also, glad you have 2-finger scroll working. Is it working very well? On mine it works but it is not very smooth...I need to make some tweaks there I think, but if it works well for you then maybe I shouldn't touch it
-
OK, I removed the older downloads just to avoid confusion in the future...just kept them there for history but really anyone should always just use the latest version
-
This is not good. The touchpad isn't responding to a probe... The versioning is a little weird right now...all the drivers I have posted will output 1.8.4 right now in the log. Do you know which version you downloaded from my first post? v2, v3 or v4?
-
OK, thanks for the log, I made a few tiny tweaks, let me know if this version works. If not, I can think of one more thing I might need to do to enable the reporting correctly (and again look for any reported errors, mainly just between the initializing touchpad hardware and initialization complete messages) ALPS-TouchPad-Driver-v4.2.zip