Contribute
Register

New VoodooPS2Controller, Keyboard, Trackpad

Status
Not open for further replies.
I upgraded VoodooPS2Controller.kext from 1.8.29 (11-30-2017) to 1.8.32 (04-24-2018) on my DIY Desktop. After upgrade (replaced kext (Release), daemon (Release), plist), rebooted and configured my PS2 mouse. Even with tracking speed on maximum, mouse tracking was V-E-R-Y S-L-O-W and took forever to navigate across my 1440x900 display. Reverted to 1.8.29 (replaced kext, daemon, plist), rebooted. Mouse tracking speed is great with 1.8.29. My system is very old, so I don't expect a fix - just wanted to let you know. Debug files (with 1.8.29) are attached. I never ran them for 1.8.32. Note that I also installed 1.8.32 on my Thinkpad T61 / OSX Sierra (same upgrade procedure) and it runs fine.

Note about attached problem report. Tried to run gen_debug multiple times - kept complaining about Clover-F4 files (even though I kept deleting them, rebooting and pressing F4 repeatedly). I finally gave up and produced the attached files. I didn't look too closely, but Clover-F4 in version 4449 may not be working correctly on my DIY Desktop.

System Specs:
  • Gigabyte GA-G31M-S2L (BIOS F10f)
  • CPU: Xeon E5450 (771->775)
  • Memory: 4GB DDR2-800
  • CLOVER 4449 (Legacy)
  • OSX Sierra 10.12.6
  • NVidia 8600GTS / Web Drivers 378.05.05.25f07 / 1440 x 900

Attach debug report with 1.8.32.
Also, report result with 1.8.30, 1.8.31 (as it will be helpful to know which version causes the problem).

Keep in mind gen_debug.sh requires you to press F4 *and F2. You only mentioned pressing F4.
Also note your ACPI/origin files are not complete (no DSDT.aml there, for example... which might be confusing gen_debug.sh).

Also your kext configuration is wrong....
With FakeSMC.kext and other kexts installed to the system volume (/L/E or /S/L/E, should be /L/E for 10.11 and later) you should have config.plist/SystemParameters/InjectKexts="Detect" (you have it set true).
As a result, you're injecting kexts that are already installed (potentially conflicting different versions).
 
Last edited:
Attach debug report with 1.8.32.
Also, report result with 1.8.30, 1.8.31 (as it will be helpful to know which version causes the problem).

Keep in mind gen_debug.sh requires you to press F4 *and F2. You only mentioned pressing F4.
Also note your ACPI/origin files are not complete (no DSDT.aml there, for example... which might be confusing gen_debug.sh).

Also your kext configuration is wrong....
With FakeSMC.kext and other kexts installed to the system volume (/L/E or /S/L/E, should be /L/E for 10.11 and later) you should have config.plist/SystemParameters/InjectKexts="Detect" (you have it set true).
As a result, you're injecting kexts that are already installed (potentially conflicting different versions).

@RehabMan - thank you for the quick reply and for noticing my incorrect inject setting. That is now fixed. I did press both F2 and F4. The preboot.log is in the CLOVER/misc folder that I posted.

Clover-F4 has prepended RSDT- to my ACPI files (e.g. DSDT.aml is RSDT-DSDT.aml). A screen shot of the CLOVER/ACPI/origin folder is attached to illustrate. This is new behavior after I updated Clover from 4439 to 4449. I'm sure you're right - that's why gen_debug complained. I could manually rename the files to make gen_debug happy again.

Running debug reports for each VoodooPS2Controller.kext version will take some time. I should be able to get back to this during the weekend. In the mean time, the old VoodooPS2Controller.kext is working great. Since this is new to you, I assume it is because my system is old and that this condition affects very few people.

Thanks again.
 

Attachments

  • Screen Shot 2018-05-04 at 12.10.42 AM.png
    Screen Shot 2018-05-04 at 12.10.42 AM.png
    54.6 KB · Views: 93
Last edited:
@RehabMan - thank you for the quick reply and for noticing my incorrect inject setting. That is now fixed. I did press both F2 and F4. The preboot.log is in the CLOVER/misc folder that I posted.

Clover-F4 has prepended RSDT- to my ACPI files (e.g. DSDT.aml is RSDT-DSDT.aml). A screen shot of the CLOVER/ACPI/origin folder is attached to illustrate. This is new behavior after I updated Clover from 4439 to 4449. I'm sure you're right - that's why gen_debug complained. I could manually rename the files to make gen_debug happy again.

Running debug reports for each VoodooPS2Controller.kext version will take some time. I should be able to get back to this during the weekend. In the mean time, the old VoodooPS2Controller.kext is working great. Since this is new to you, I assume it is because my system is old and that this condition affects very few people.

Thanks again.

Reply when you can provide the requested data.
 
Reply when you can provide the requested data.

I reverted to Clover 4439 and pressed F4 to gen new ACPI files. The file names still have RSDT- (e.g. DSDT.aml is named RSDT-DSDT.aml). It's my system and not Clover and I don't remember having to rename my ACPI files before. Have you seen systems with an ACPI file naming convention like this? Is it possible that I did something to change these file names?
 
I reverted to Clover 4439 and pressed F4 to gen new ACPI files. The file names still have RSDT- (e.g. DSDT.aml is named RSDT-DSDT.aml). It's my system and not Clover and I don't remember having to rename my ACPI files before. Have you seen systems with an ACPI file naming convention like this? Is it possible that I did something to change these file names?

It could just be your system is old and therefore uses old ways to organize ACPI.
gen_debug.sh definitely checks specifically for DSDT.aml as a way to insure you pressed F4... probably just not a compatible assumption with older hardware like yours (renaming of copying RDST-DSDT.aml to DSDT.aml will quell its complaints).

You could report the problem to the gen_debug.sh author...
 
It could just be your system is old and therefore uses old ways to organize ACPI.
gen_debug.sh definitely checks specifically for DSDT.aml as a way to insure you pressed F4... probably just not a compatible assumption with older hardware like yours (renaming of copying RDST-DSDT.aml to DSDT.aml will quell its complaints).

You could report the problem to the gen_debug.sh author...

@RehabMan - I just went back to the original Clover-F4 ACPI files that I used recently to perform my static DSDT patching. None of the files have the RSDT- prefix and I don't believe I'm smart enough to have figured out that I needed to remove the prefix. I either did something that changed the ACPI file names or I'm losing my mind. Feel free to be candid with your response (not that I've seen you hold back before).
 
@RehabMan - I just went back to the original Clover-F4 ACPI files that I used recently to perform my static DSDT patching. None of the files have the RSDT- prefix and I don't believe I'm smart enough to have figured out that I needed to remove the prefix. I either did something that changed the ACPI file names or I'm losing my mind. Feel free to be candid with your response (not that I've seen you hold back before).

If you used a different version of Clover before, might be a change in Clover...
At any rate, I'm really only interested in ioreg, kextcache, config.plist, and to some extent what you have in ACPI/patched.
 
Reply when you can provide the requested data.

@RehabMan - Two items for you in this post:
  • Attached are the gen_debug files that you requested (I hope this helps you to address an issue in VoodooPS2Controller.kext v 1.8.30 and v1.8.32). My system works fine with v1.8.29, so I don't need a fix - just trying to help.
  • This is off-topic (for this thread), but if you have suggestions about why TRIM is not enabled on my DIY Desktop System (even though I load the TRIM patch with Clover), I'd appreciate your advice. TRIM works fine on my Thinkpad laptop using the same Clover version / patch.

VoodooPS2Controller
The slow mouse problem for my DIY Desktop system was introduced with VoodooPS2Controller v1.8.30 (mouse works fine with v1.8.29). Attached are the gen_debug files for v1.8.29 and v1.8.30. I didn't bother to re-install v1.8.32 since I already confirmed that the v.1.8.32 behavior is no different than v1.8.30. Hopefully this helps you.

Not sure if this is anything and don't want to send you on a wild goose chase, but when I installed v1.8.30 and rebooted, my sound didn't work. It didn't occur to me until I had already reverted to 1.8.29 that I should have rebooted (again) with v1.8.30 to see if the sound problem persisted. Anyway, my sound on this DIY Desktop system is very reliable - no problems. When I reverted to VoodooPS2Controller.kext v1.8.29 and rebooted, sound was back to normal.

To test each VoodooPS2Controller version, I used the Release builds of VoodooPS2Controller.kext and VoodooPS2Daemon. I cp'd VoodooPS2Controller.kext to /L/E and CLOVER/kexts/Other. I cp'd VoodooPS2Daemon to /usr/bin. I cp'd org...plist to /L/LaunchDaemons. I manually installed the kext to /L/E with chown, chmod and kextcache -i. Then I shutdown (not restart) and rebooted.

TRIM
One other question - It appears that TRIM is not enabled even though I'm load the TRIM patch with CLOVER. Not sure if this is related in any way, but if you have suggestions for enabling TRIM on this system, I'd appreciate your advice. Thank you.
 

Attachments

  • debug_PS2_v1.8.29.zip
    1.1 MB · Views: 82
  • debug_PS2_v1.8.30.zip
    1 MB · Views: 66
Last edited:
@RehabMan - the slow mouse problem for my DIY Desktop system was introduced with VoodooPS2Controller v1.8.30 (mouse works fine with v1.8.29). Attached are the gen_debug files for v1.8.29 and v1.8.30. I didn't bother to re-install v1.8.32 since I already confirmed that the v.1.8.32 behavior is no different than v1.8.30. Hopefully this helps you. In the mean time, I'm happy with v1.8.29 and don't expect a fix for my system. I'm happy with what I have.

Not sure if this is anything and don't want to send you on a wild goose chase, but when I installed v1.8.30 and rebooted, my sound didn't work. It didn't occur to me until I had already reverted to 1.8.29 that I should have rebooted (again) with v1.8.30 to see if the sound problem persisted. Anyway, my sound on this system is very reliable - no problems. When I reverted to v1.8.29 and rebooted, sound was back to normal.

Audio not related to PS2.

With v1.8.30, try setting a shorter FindMouseDelay (default is 500ms).
For example, to set to zero use kernel flag: vps2_findmousedelay=0
Or for 100ms: vps2_findmousedelay=100
If zero works, try to find the smallest value that causes failure (and by correlation, largest value that works).

Also, to make sure it isn't VoodooPS2Trackpad.kext changes (at startup, it probes and fails, which allows VoodooPS2Mouse.kext to start), remove VoodooPS2Controller.kext/Contents/PlugIns/VoodooPS2Trackpad.kext.
 
Last edited:
Audio not related to PS2.

With v1.8.30, try setting a shorter FindMouseDelay (default is 500ms).
For example, to set to zero use kernel flag: vps2_findmousedelay=0
Or for 100ms: vps2_findmousedelay=100
If zero works, try to find the smallest value that causes failure (and by correlation, largest value that works).

Also, to make sure it isn't VoodooPS2Trackpad.kext changes (at startup, it probes and fails, which allows VoodooPS2Mouse.kext to start), remove VoodooPS2Controller.kext/Contents/PlugIns/VoodooPS2Trackpad.kext.

As you expected, system behavior is different with and without VoodooPS2Trackpad.kext. Detailed test results are below. After testing variations with VoodooPS2Controller.kext v1.8.30, I found that vps2_findmousedelay=180 works when VoodooPS2Trackpad.kext is installed (vps2_findmousedelay=430 works when VoodooPS2Trackpad.kext is NOT installed). After testing with v1.8.30, I installed v1.8.32 and confirmed that it also works with the same modified vps2_findmousedelay. My current working state is VoodooPS2Controller.kext v1.8.32 (with VoodooPS2Trackpad.kext) and vps2_findmousedelay=180. My debug files for this latest configuration are attached.

A couple of notes:
  1. When I first set findmousedelay=0 at the start of testing (v1.8.30 without VoodooPS2Trackpad.kext), my system experienced a kernel panic upon reboot. The screen vanished quickly (didn't have debug=0x100). I set debug=0x100 after this and never observed the kernel panic again. I don't ever see kernel panics on this system, but can't be certain that the kernel panic was caused by VoodooPS2Controller.
  2. Off-topic: TRIM does not appear to be enabled on this system (even though I have the TRIM patch selected in Clover). If you have any suggestions to enable TRIM, please let me know. Thank you.

Test results with v1.8.30 (reboot after each change):
Without VoodooPS2Trackpad.kext
vps2_findmousedelay=425: Fast (good)
vps2_findmousedelay=430: Fast (good)
vps2_findmousedelay=435: Slow (bad)

With VoodooPS2Trackpad.kext
vps2_findmousedelay=175: Fast (good)
vps2_findmousedelay=180: Fast (good)
vps2_findmousedelay=185: Slow (bad)
 

Attachments

  • debug_PS2_v1.8.32.zip
    1.1 MB · Views: 91
Status
Not open for further replies.
Back
Top