As everyone knows already, lot of trackpads/touch screens are not working on Haiku. This happens on modern laptops sporting multitouch trackpads.
Don’t work because most of them are wired through i2c-hid. We do support (most) of this protocol, however we have support only for Intel PCH i2c chipsets, and today a specification known as Designware is broadly used.
On top of that, our HID layer is not well suited for neither multi-touch devices neither Windows 8 compatible trackpads, where a set of hid features must be checked.
I have some contributions to Haiku HID driver, I am maybe not an expert but at least, I feel confident on this topic. But I have no idea about i2c, other than is a kind of low lever serial bus.
I decided anyway, to write a designware i2c driver. The main idea was to take the PCH driver as reference, lookup the bus on ACPI and fill a header with all known registers.
As I started to write this “skeleton” I realized registers were 99% equal to PCH ones so I ended writing all de driver just replacing constants names.
Yeah, it sounds dumb, and maybe it is, but my point was (and still is) to do most of boring plumbing so a real expert on this topic only has to fix some lines to get it working.
The driver is already on gerrit, but meanwhile, I have been trying to determine if the driver works o not, and trying to fix it.
What is working?
As I have access to almost all Slimbook laptops, I currently have a pair of them to develop this so:
- i2c busses are shown on /dev
- i2c tool scans the bus and find the trackpad where It is expected to be
- i2c-hid driver finds a hid device, reads the report descriptor and receives events
- I can send (at least some) feature reports to device
Does the pointer move? Well… here comes the problem. At first, I was convinced the problem was at HID level, not handling properly multiple x-y each positions report.
On one of the laptops I can switch (via feature report) the trackpad to a mouse-like behaviour and I can use the trackpad without problems (I’ve uploaded a video on telegram). Here we lost any multi-touch gesture, but wasn’t a bad idea as a first milestone.
Anyway, I’ve been trying to get multitouch reports working but after some debugging I realized that I get some corrupted data from i2c.
The funny thing is, I fetch report descriptor from the device, which seems to be ok and well parser by our hid driver. The report weights around 700 bytes. However, input events are ok only the first eight bytes, then, data shows some kind of corruption I have not been able to determine how. That’s why It works well on mouse mode, incoming i2c events have this format:
(2b length) (1b ID) (1b buttons) (2b x) (2b y)
Multitouch events have Y data on bytes 8 and 9, and 9 is always bad. Some times with an unexpected 0x01.
I am reading datasheet (there are tons of concepts to understand here) because it looks like some kind of time shift issue. This does not explain why I am able to fetch a 700 byte report but can fetch input reports no longer than 8 bytes. Driver reports sometimes, a timeout waiting for data, but input reports are constantly wrong.
So… this is where we are. I know there are lot of work to do but I am happy and confident because I already have a pointer moving around, with more or less glitches.
Any help is more than welcome