New VoodooPS2Controller, Keyboard, Trackpad

[schinkengott]

I saw someone recommending using BetterTouchTool in this topic. I can't get this to work. Is there a way to do that in combination with this VoodooPS2Controller? Or does this require to uninstall the kexts?

View attachment 40650

i recommended it,and its very good but you have to think a little bit...
our swipe functions are EMULATED keyboard keys.. so you have to use KEYBOARD in bettertouchtool,choose a action and asign the swipe(keys) in it, works without problems

 

[Rourke]

The print screen key is special-case in the code. It never gets converted to an ADB code -- it is "swallowed up" in the driver to do the trackpad enable/disable. That's why KeyRemap4MacBook never sees it.

You can map it to another PS2 code using Custom PS2 Map. The scan code of printscreen for this purpose is e05f. So map e05f to some other scan code. You can map it to a scan code that is "imaginary" that isn't already used on the actual keyboard, then use the Custom ADB Map to map it to whatever ADB code you want. Or if you want to map it to F13, use the scan code for F13 (64). Then print screen won't enable/disable the trackpad anymore (it is being remapped before the code responsible sees it), and KeyRemap4MacBook will see it as a key, because it will see the ADB code (in the case of F13... 69).

I'm afraid I don't quite get this. At the start you say e05f is printscreen? I thought it was Fn+F1?
I read your post over and over again, but I can't seem to grasp it. Could you perhaps give an example of how it looks like in the VoodooPS2Keyboard.kext/content/info.plist? I appreciate the effort you put in helping people/me

 

[RehabMan]

I'm afraid I don't quite get this. At the start you say e05f is printscreen? I thought it was Fn+F1?
I read your post over and over again, but I can't seem to grasp it. Could you perhaps give an example of how it looks like in the VoodooPS2Keyboard.kext/content/info.plist? I appreciate the effort you put in helping people/me

Did I say e05f? Oh crap, I meant e037 -- this is why I have to test my code before I release it

You wanted to map prntscrn to F13. Scan code for prntscrn is e037, so to map it to F13, you need an entry that looks like:
<string>e037=64</string>

Because it gets mapped before the special case prntscrn code, the code never sees it and will not be toggling the trackpad on/off...

 

[snapchops]

EdgeRight and EdgeBottom determine vscroll & hscroll areas. So, they are not dead areas, just areas designated to initiate scrolling. EdgeRight and EdgeTop are only used for circular scroll (I've never tried to enable circular scroll, whatever that is...). Except for circular scroll, there really isn't any dependencies in the code on the concept of 'center'.

You can turn the "edge" scrolling features off with TrackpadHorizScroll and TrackpadScroll. Two finger scroll will still work.

You should probably run the debug version, and examine the output in console to determine how your trackpad is behaving.

I've ran the debug version. The bottom and right 1/4 of the trackpad that don't respond to tapping or scrolling actually register the tap in console. Here's what shows in console when I single tap once on a close button (which doesn't actually close the app)

Dec 11 12:53:50 --- last message repeated 41 times ---
Dec 11 12:53:50 localhost kernel[0]: ps2: dx=0, dy=0 (1170,168) z=8 w=4 mode=(0,0,0) buttons=0 wasdouble=0
Dec 11 12:53:50 localhost kernel[0]: ps2: dx=0, dy=0 (2336,340) z=9 w=4 mode=(0,0,0) buttons=0 wasdouble=0
Dec 11 12:53:50 localhost kernel[0]: ps2: dx=0, dy=0 (3506,507) z=10 w=4 mode=(0,0,0) buttons=0 wasdouble=0
Dec 11 12:53:50 localhost kernel[0]: ps2: dx=0, dy=0 (3508,505) z=10 w=4 mode=(0,0,0) buttons=0 wasdouble=0
Dec 11 12:53:50 localhost kernel[0]: ps2: dx=0, dy=0 (3510,501) z=11 w=4 mode=(0,0,0) buttons=0 wasdouble=0
Dec 11 12:53:50 localhost kernel[0]: ps2: dx=0, dy=0 (3512,503) z=11 w=4 mode=(0,0,0) buttons=0 wasdouble=0
Dec 11 12:53:50 localhost kernel[0]: ps2: dx=0, dy=0 (3510,503) z=11 w=4 mode=(0,0,0) buttons=0 wasdouble=0
Dec 11 12:53:50 localhost kernel[0]: ps2: dx=0, dy=0 (3514,503) z=11 w=4 mode=(0,0,0) buttons=0 wasdouble=0
Dec 11 12:53:50 localhost kernel[0]: ps2: dx=0, dy=0 (3512,503) z=11 w=4 mode=(0,0,0) buttons=0 wasdouble=0
Dec 11 12:53:50 localhost kernel[0]: ps2: dx=0, dy=0 (3512,506) z=11 w=4 mode=(0,0,0) buttons=0 wasdouble=0
Dec 11 12:53:50 localhost kernel[0]: ps2: dx=0, dy=0 (3511,508) z=2 w=0 mode=(0,0,0) buttons=0 wasdouble=0
Dec 11 12:53:50 localhost kernel[0]: ps2: dx=0, dy=0 (2340,338) z=0 w=0 mode=(0,0,0) buttons=0 wasdouble=0
Dec 11 12:53:50 localhost kernel[0]: ps2: dx=0, dy=0 (1170,169) z=0 w=0 mode=(0,0,0) buttons=0 wasdouble=0
Dec 11 12:53:50 localhost kernel[0]: ps2: dx=0, dy=0 (0,0) z=0 w=0 mode=(0,0,0) buttons=0 wasdouble=0



any idea why??

 

[Rourke]

Did I say e05f? Oh crap, I meant e037 -- this is why I have to test my code before I release it

You wanted to map prntscrn to F13. Scan code for prntscrn is e037, so to map it to F13, you need an entry that looks like:
<string>e037=64</string>

Because it gets mapped before the special case prntscrn code, the code never sees it and will not be toggling the trackpad on/off...

Thank you! This works : )

 

[RehabMan]

I've ran the debug version. The bottom and right 1/4 of the trackpad that don't respond to tapping or scrolling actually register the tap in console. Here's what shows in console when I single tap once on a close button (which doesn't actually close the app)

Dec 11 12:53:50 --- last message repeated 41 times ---
Dec 11 12:53:50 localhost kernel[0]: ps2: dx=0, dy=0 (1170,168) z=8 w=4 mode=(0,0,0) buttons=0 wasdouble=0
Dec 11 12:53:50 localhost kernel[0]: ps2: dx=0, dy=0 (2336,340) z=9 w=4 mode=(0,0,0) buttons=0 wasdouble=0
Dec 11 12:53:50 localhost kernel[0]: ps2: dx=0, dy=0 (3506,507) z=10 w=4 mode=(0,0,0) buttons=0 wasdouble=0
Dec 11 12:53:50 localhost kernel[0]: ps2: dx=0, dy=0 (3508,505) z=10 w=4 mode=(0,0,0) buttons=0 wasdouble=0
Dec 11 12:53:50 localhost kernel[0]: ps2: dx=0, dy=0 (3510,501) z=11 w=4 mode=(0,0,0) buttons=0 wasdouble=0
Dec 11 12:53:50 localhost kernel[0]: ps2: dx=0, dy=0 (3512,503) z=11 w=4 mode=(0,0,0) buttons=0 wasdouble=0
Dec 11 12:53:50 localhost kernel[0]: ps2: dx=0, dy=0 (3510,503) z=11 w=4 mode=(0,0,0) buttons=0 wasdouble=0
Dec 11 12:53:50 localhost kernel[0]: ps2: dx=0, dy=0 (3514,503) z=11 w=4 mode=(0,0,0) buttons=0 wasdouble=0
Dec 11 12:53:50 localhost kernel[0]: ps2: dx=0, dy=0 (3512,503) z=11 w=4 mode=(0,0,0) buttons=0 wasdouble=0
Dec 11 12:53:50 localhost kernel[0]: ps2: dx=0, dy=0 (3512,506) z=11 w=4 mode=(0,0,0) buttons=0 wasdouble=0
Dec 11 12:53:50 localhost kernel[0]: ps2: dx=0, dy=0 (3511,508) z=2 w=0 mode=(0,0,0) buttons=0 wasdouble=0
Dec 11 12:53:50 localhost kernel[0]: ps2: dx=0, dy=0 (2340,338) z=0 w=0 mode=(0,0,0) buttons=0 wasdouble=0
Dec 11 12:53:50 localhost kernel[0]: ps2: dx=0, dy=0 (1170,169) z=0 w=0 mode=(0,0,0) buttons=0 wasdouble=0
Dec 11 12:53:50 localhost kernel[0]: ps2: dx=0, dy=0 (0,0) z=0 w=0 mode=(0,0,0) buttons=0 wasdouble=0



any idea why??

The z value is too low to indicate touch. Does it do that when you just move into that area? If you start at the left edge and move towards the right, does the z value fall off like that?

 

[snapchops]

The z value is too low to indicate touch. Does it do that when you just move into that area? If you start at the left edge and move towards the right, does the z value fall off like that?

Actually no, When I drag my finger into the area or hold down my finger without lifting is registers a z-value around 40. If I tap, the z-value is zero.

While dragging a window, even though it registers a z-value, as soon as my finger hits about 1/4"-3/8" from the bottom edge or right edge of the trackpad, the window is dropped. The older voodoops2 prefpane has an option to adjust the dimensions, maybe the answer lies in the code to that prefpane.

 

[RehabMan]

Actually no, When I drag my finger into the area or hold down my finger without lifting is registers a z-value around 40. If I tap, the z-value is zero.

While dragging a window, even though it registers a z-value, as soon as my finger hits about 1/4"-3/8" from the bottom edge or right edge of the trackpad, the window is dropped. The older voodoops2 prefpane has an option to adjust the dimensions, maybe the answer lies in the code to that prefpane.

When you say "Actually, no" presumably to my question about holding down your finger from left to right, and when you say "dragging a window, ... as soon as my finger hits about 1/4"-3/8" from the bottom... right edge... the window is dropped"... these two statements seem to contradict each other. The only reason the window would be "dropped" (ie. dragging ceases) is if the z-value dropped below FingerZ while moving into these "dead" areas.

Trackpad prefpane won't do you any good. As stated before, there is nothing in the code that defines an overall trackpad region. Only certain areas designated for certain things (scrolling, enable/disable trackpad, and areas to watch out for as far as accidental 'palm' input). Certainly those areas could be adjusted if your trackpad demonstrates a different overall resolution, but you can do that through the Info.plist just as much through the prefpane (if it was working). The only thing the prefpane does is adjust things you can adjust already through the Info.plist.

What you are seeing in the debug output is the raw data the driver is receiving. If what it is receiving doesn't look like a touch, then there is no way any modifications to Info.plist parameters is going to help you.

For some reason, your trackpad is different. Perhaps it needs different a different initialization sequence or something. Unfortunately, the only document we have from Synaptics describing the protocol is about 10 years old. So, there are probably variations in trackpad behavior on different Synaptics models/firmware, etc... probably customizations made for large OEMs... The only way to improve the compatibility of the driver for such variations is through experimentation and reverse engineering. Obviously, it is not something you can do unless you have some coding skills, a little imagination, and the actual hardware.

 

[snapchops]

When you say "Actually, no" presumably to my question about holding down your finger from left to right, and when you say "dragging a window, ... as soon as my finger hits about 1/4"-3/8" from the bottom... right edge... the window is dropped"... these two statements seem to contradict each other. The only reason the window would be "dropped" (ie. dragging ceases) is if the z-value dropped below FingerZ while moving into these "dead" areas.

.

Sorry for the confusion. The "actually no" was the answer to "If you start at the left edge and move towards the right, does the z value fall off like that? " The z-value was only low if I tapped in the dead area. If I held my finger down the z-value was around 40. Even though console registered my finger in the dead area, it would dropped the window I was dragging as though I lifted my finger.

prior to switching to your version, I used the driver included with multibeast. With the MB version the trackpad area is 100% usable to the edges, but I needed to double click finder navigation, firefox navigation & program launch from dock.

Is there an specific edit to the Info.plist or code that will allow me to change from double clicking to single clicking as mentioned above? If so, I can switch back to the MB version and edit the info.plist.

otherwise, I'll try playing around with different versions to see if I can zero in on what's changed . . .

 

[RehabMan]

Sorry for the confusion. The "actually no" was the answer to "If you start at the left edge and move towards the right, does the z value fall off like that? " The z-value was only low if I tapped in the dead area. If I held my finger down the z-value was around 40. Even though console registered my finger in the dead area, it would dropped the window I was dragging as though I lifted my finger.

But if you move your finger from left edge to the right edge (no need to engage dragging or anything), what happens to z as you enter your supposed 'dead' area?

prior to switching to your version, I used the driver included with multibeast. With the MB version the trackpad area is 100% usable to the edges, but I needed to double click finder navigation, firefox navigation & program launch from dock.

Is there an specific edit to the Info.plist or code that will allow me to change from double clicking to single clicking as mentioned above? If so, I can switch back to the MB version and edit the info.plist.

otherwise, I'll try playing around with different versions to see if I can zero in on what's changed . . .

I'm not familiar with the source code for the version in MB (or even if it is available anywhere). But it is possible the MB version is running in 'mouse emulation' mode, which is a totally different animal. In that mode the trackpad firmware itself simulates a two-button mouse with scroll wheel.