VoodooI2C Bindings

[1Revenger1]

RMI4 in Linux has I2C bindings alongside with SMBus bindings. This should be very easy to add to this kext as I've already done all the abstractions needed.

VoodooI2C already does have their own Synaptics kext so this is very low priority. I2C bindings for this kext should only be needed if people want to use F12 or the trackpoint.

https://github.com/torvalds/linux/blob/master/drivers/input/rmi4/rmi_i2c.c

[gimdh]

As far as I know, Thinkpads with I2C touchpad has Trackpoint buttons attached to keyboard assembly so VoodooPS2 can handle everything - Lenovo may also have thought mixing interfaces are no good. And if I2C F12 device needs support, then that's a work for VoodooI2C team.
Considering VoodooRMI is under VoodooSMBus project, I think I2C support should not be a concern at all.

[1Revenger1]

Linux uses the exact same driver for both I2C and SMBus, and behaviour I'd guess should be similar. Afaik there isn't a lot of interest to add F12, and honestly it's been a giant pain to get working (it keeps reporting over 80 fingers when >_<). Additionally, if you load voodoops2mouse/trackpad it does mess up this kext and I'd guess VoodooI2C as well so that isn't an option. Though, I don't think trackpoint gets sent over PS2 anyways since it is router through the trackpad. Overall, it's not a lot of work to add I2C support as well. I don't see any reason why not to at least think about it.

[gimdh]

I doubt there's any device benefits with I2C bindings, although I understand it's required for completeness of porting.
Besides practicality, I thought you were considering reconstruction of VoodooRMI as a satellite kext of VoodooSMbus, just like VoodooI2C. In that case, I'm worried that I2C support might hinder hierarchy and lead to a confusion.

[1Revenger1]

It's already constructed in such a way to allow easy construction of other bindings. All the SMBus stuff is abstracted out already, and there is a common interface between different transport services. There certainly are devices which only support I2C which I would like to support since support is lacking. It definitely is a valid concern though, especially considering that we'd be dealing with trying to support VoodooI2C in GitHub issues and what not, which just sounds like a giant pain now that I think about it...