Jump to content
InsanelyMac Forum


  • Content count

  • Joined

  • Last visited

About alex.daoud

  • Rank
    InsanelyMac Geek

Profile Information

  • Gender

Recent Profile Visitors

4,665 profile views
  1. Chat support is fundamentally necessary for VoodooI2C due to the complicated nature of the driver. It is practically impossible to create a "one-step" guide and a "one-step" debugging process due to various issues arising with how macOS implements APIC interrupts. We are forced to "hack" GPIO interrupt support in which means a high level of manual patching is required. When this goes wrong, a static bug reporting format (such as in a forum thread) makes it very difficult to debug end user issues since the support team usually has to go back and forth with the user receiving many iterations of troubleshooting archives. It is far easier to debug something instantly than wait (potentially days) for a user to reply only to have forgotten what the issue was in the first place (not to mention the likely scenario of having many other posts from other users appearing since that user last posted). It is a fair point regarding the readme of the native branch and I will update this accordingly. It would have been helpful, however, for you to point this out to me. When it comes to your pros/cons list for your Dell XPS 9550, I have some issues. Namely that I, myself, have a Dell XPS 9550 and I develop specifically for this machine. That means that nothing is released if it doesn't work for me on this machine. I do not experience any crashes on boot nor on wake/sleep. My (USB) touchscreen also works beautifully with @blankmac's touchscreen driver which is baked into VoodooI2CHID. In future the HID part of the driver will be separated out so that it is agnostic from the I2C/USB protocol. For the moment, however, USB touchscreens and trackpads required VoodooI2C.kext and VoodooI2CHID.kext installed. If you experience issues with the kext as you listed then you should have submitted your troubleshooting archives to us. That's the process everyone goes through and I guarantee VoodooI2C v2.0.1 is far more stable than you make it out to be. Edit: Finally, I should also point out one last very important thing regarding the native branch. I have not yet done the due diligence in determining to what extent the legality of simulating the magic trackpad 2 is. This issue requires more careful thought. It could be in the end that I deem it not a good idea for such a thing to be in the public domain. This is one of the reasons for which I cannot approve of any build of the native branch going out.
  2. I apologise that I was rude to you in the first instance. I certainly do not mean to imply that your contributions are not welcome. What you must understand is that we have had many people come "eager" to contribute. Then in the end, it turns out they just wanted as much as my (or others') help as was possible to fix a situation for their own problems and then leave the code half-assed and unabled to be merged. This is the situation with the following fork: https://github.com/shdkpr2008/VoodooI2CHID where the guy needed keyboard support and leeched off of me helping him until he sorted it out and then disappeared saying "well it works for me, so i'll just leave it like that". In the end I just stick to my close core of collaborators who have proven to me that they care about the development of the project rather than just "making it work for them". If someone wants to contribute then I am very eager to see their work but I try to be wary of my time being wasted. I am a full-time PhD student and I have very little free time for anything, let alone VoodooI2C as it is. When I do work on VoodooI2C I would like to maximise the good I do for the project in the short time that I can afford. Hence if someone appears saying they want to contribute I'd rather just watch them and see what they can do rather than have any kind of high expectations.
  3. Thank you. The license acts as a deterrent for companies like touch-base from appropriating code from VoodooI2C. Legally speaking, however, Apple's EULA nullifies any open source license that is applied to kernel level software developed for OS X. The license is merely the illusion of rights applied. That being said I have always and will always be 100% committed to the open-source development of VoodooI2C. However, it is typically well-recognised that OSS that does not start as a form of collaboration between many people (i.e that was only really started and worked on for a large amount of time by one or two people) will develop a group of people that is known as the "benevolent dictator for life"(https://en.wikipedia.org/wiki/Benevolent_dictator_for_life). Linux is a famous example of this whereby Linus Torvalds effectively has the final say as to what is merged into the master branch of the Linux kernel. Currently myself and @coolstar exercise our rights to this kind of control over the project due to the vast amount of man-hours we have put into it. We have recently (within the last year and a half or so) seen new people eagerly contributing and helping out and, gradually, they will also be able to exercise the same rights over the project. One day I will officially leave this project fully to the community (and cease development myself) but that day cannot come until people realise that this whole idea of making some small changes, bundling them up in a new buggy kext and spreading these kexts around the internet severely undermines the hackintosh community as a whole. This is why the hackintosh community is so unpolished as compared to the iOS jailbreak community. There is very little attention to quality control and what is appropriate to be released as a "beta". This is also why we get so many of the same boring old questions over and over again - its because the internet is full of old junk kexts which people continue to download then complain about when they don't work. You can see this easily with VoodooI2C. We had someone called macforceone create a fork with a certain fix for Elan1200 back in the days of v1.0.0. It was a buggy fix and has long since been superseded - yet I still get questions about why this kext isn't working for people and whether its better to use than v2. The existence of these things undermines the very goal of this project: to provide super fluid (someday native) input on I2C devices. I spent 3 long months working very hard full-time to rewrite VoodooI2C from the ground up officially finishing it in September 2017. I held off on releasing until January 2018 after months of extensive private and then public beta testing. As a result, something that was written in 3 months is almost up to scratch to (and even often outperforms) VoodooPS2 which has been around (and not been rewritten since) in various iterations for close to 13 years. I remember using the predecessor to VoodooPS2 back in 2005 when I first started hackintoshing and the performance has not drastically improved since then. It is for this reason that I do not approve of anything that isn't on the Release page being posted anywhere. It really is for the good of the development of VoodooI2C.
  4. I did not give you permission to upload a compiled version of the native branch. Kindly remove it. I said multiple times that it was not for public use and the source code is online strictly for development purposes. I will take down the source code for the native branch if people continue to abuse this.
  5. alex.daoud

    VoodooI2C Help and Support

    The patches are in the linked repository (which comes from https://github.com/alexandred/VoodooI2C-Patches ) Moreover, most Skylake+ users will require manually applying a GPIO pinning patch for which they need to follow the GPIO pinning guide. It is not possible to create an all-encompassing patch for this particular step so there exists no "patch" for it.
  6. alex.daoud

    VoodooI2C Help and Support

    The DSDT patches are outlined in the installation guide found here: https://voodooi2c.github.io/#Installation/Installation .
  7. alex.daoud

    VoodooI2C Help and Support

    This thread is intended for users of VoodooI2C to get support for using the kext on their system. What is VoodooI2C? VoodooI2C is a project consisting of macOS kernel extensions that add support for I2C bus devices. The project is split into two main components: the core extension and various other satellite extensions. The Core The core is the VoodooI2C.kext kernel extension. This kext is intended to be installed by anyone whose computer requires some form of I2C support. It consists of I2C controller drivers and is responsible for publishing device nubs to the IOService plane. The Satellites The satellites are a collection of various kernel extensions that implement support for a specific type of I2C device. An example of a satellite kext is VoodooI2CHID.kext which adds support for I2C-HID devices. Usually a user will install one satellite kext per class of I2C device. What can I use VoodooI2C for? The most common devices that are compatible with VoodooI2C are I2C-HID devices such as Precision Trackpads and Touchscreens. If you have an I2C trackpad or touchscreen, chances are it will work with this driver. It is also possible to use VoodooI2C to get multitouch on USB devices but this is experimental. How do I install VoodooI2C? All installation instructions can be found here: https://voodooi2c.github.io/#Installation/Installation Help! It doesn't work Follow carefully the instructions here: https://voodooi2c.github.io/#Troubleshooting/Troubleshooting Where is the source code? The main Github repository can be found here: https://github.com/alexandred/VoodooI2C Upload all requested files in an archive to this thread. Note that if you are on 10.12+ then the system log has been moved. Instructions for how to obtain it can be found on the following page: https://voodooi2c.github.io/#Common Errors/Common Errors
  8. alex.daoud

    Wacom MobileStudio Pro

    If the device has both an integrated and discrete graphics card (Intel and an nVidia), it is unlikely you will get the nVidia card running (except in special cases where the Intel one can be switched off). Also keep in mind that if the touchscreen is USB then the only multitouch drivers out there (provided Wacom don't make their own) are proprietary and pretty costly (touchbase). If the touchscreen is I2C then its unlikely you'd get multitouch for the time being.
  9. alex.daoud

    i2c-hid touchscreens, trackpads and more

    OP updated to reflect upstream's update with Skylake support.
  10. alex.daoud

    [Guide] 10.11 El Capitan On the Surface Pro 4

    I have good news and bad news. Good news is that the official drivers for the SP4's touch screen are out for linux: https://github.com/ipts-linux-org/ipts-linux/tree/master/drivers/misc/itouch. Bad news is that they look pretty complicated, they involve a lot of calls to the GPU. Doesn't bode well for an OS X port unless someone is really dedicated enough to port them.
  11. The DVP touchpad is USB and not I2C (this is clear when you check IOReg and from the fact that the touchpad works in Clover). The reason why it doesn't work is still unknown to me. I'm leaning towards it being a bug in Apple's IOUSBComposite driver.
  12. Yeah it does, I just forgot to post the kext. Come to http://gitter.im/alexandred/VoodooI2Cand I'll compile the DVP one for you.
  13. alex.daoud

    i2c-hid touchscreens, trackpads and more

    No, only basic mouse input for the moment.
  14. alex.daoud

    [Guide] 10.11 El Capitan On the Surface Pro 4

    We figured out the cause of the apparent meddling the I2C controller kexts were causing with the other system. Turns out it had nothing to do with them and the issue was immediately rebooting from Windows. For some reason, the system has two DSDTs so the one we modified was only being loaded on a fresh boot. The unmodified one was still in memory upon rebooting from Windows. Might not be the situation for you but just wanted to make you aware.
  15. Yeah someone has got it to work on the XPS 12. Come join us in gitter.im/alexandred/VoodooI2C if you need help.