I2C/smbus keyboards and touchpads support

[adamfowleruk]

As per the forum, I've installed Haiku hrev53001 on my PC Specialist Recoil II. The Keyboard and Trackpad do not operate.

Please suggest a solution / missing driver that needs writing.

Attached are the relevant logs. I shall add further windows trace files from prior to Haiku install later too.

[adamfowleruk]

acpidump and wii demo output on Linux Mint when both trackpad and keyboard were working

[adamfowleruk]

Here's a thread that references the issue. I can confirm the keyboard worked OOTB in Linux Mint, but the trackpad required the 4.19 kernel.

I think now actually the keyboard was a PS/2 derivative, and the trackpad was the I2C device. It's just the keyboard LIGHTING that's a WMI device. That may well make it simpler.

​https://askubuntu.com/questions/1070644/tongfang-gk5cn6z-ubuntu-touchpad-and-keyboard-backlight

[waddlesplash]

This part I have not seen before:

KERN: ps2: active multiplexing v1.1 enabled
KERN: ps2: accessing multiplexed mouse port 0 timed out, ignoring it!

This part looks to have the same message as #14856:

KERN: ps2: reset failed
KERN: ps2: devfs_publish_device input/mouse/ps2/3, status = 0xffffffff
KERN: ps2: devfs_publish_device input/keyboard/at/0, status = 0x00000000
KERN: register_domain(4, link)
KERN: ps2: keyboard reset failed, status 0x80000009, data 0xff
KERN: ps2: keyboard probing failed

Likely the first message is the "actual" problem.

[pulkomandy]

Synaptics docs on PS/2 multiplexing ​http://www.isdaman.com/alsos/hardware/mouse/mouse2.pdf

This would normally be used only for pointing devices, but could it be that in your case they multiplexed the keyboard with the touchpad, to connect them both to a single port and save on wiring maybe?

[adamfowleruk]

I've done some more research...

Turns out it’s the same model as the MechRevo Z2 i7-8750h-gtx-1060 ​https://www.pdevice.com/product/mechrevo-z2-notebook-price-specs

Aka Z210606Z ​https://www.banggood.com/MECHREVO-Deep-Sea-Ghost-Z2-Gaming-Laptop-i7-8750H-8GB-DDR4-128-SSD-1TB-HDD-GTX1060-6G-Laptop-p-1353657.html?ID=227&cur_warehouse=CN

Reviews and tech tips linked ​http://forum.notebookreview.com/threads/tongfang-gk5cn5z-gk5cn6z-gk5cq7z-gk5cp0z.815943/page-109

Very detailed description of the touchpad:- ​https://bugzilla.kernel.org/show_bug.cgi?id=200787

Touchpad make: "I disassembled the laptop hardware and determined that the touchpad is a PCT1336QN, which is a Pixart device: ​http://www.pixart.com/product_data.asp?product_id=154&productclassify_id=12&productclassify2_id=50&partnumber=PCT1336QN"

Correct url: ​https://www.alldatasheet.com/datasheet-pdf/pdf/987650/PIXART/PCT1336QN.html

​https://pdf1.alldatasheet.com/datasheet-pdf/view/987650/PIXART/PCT1336QN.html

So It’s definitely an I2C device for the keyboard itself.

What I2C support does Haiku have?

[adamfowleruk]

This looks promising as a base library to use for i2c communication:- ​http://xref.plausible.coop/source/xref/haiku/src/add-ons/kernel/drivers/dvb/cx23882/i2c_core.c

Probably a good idea to start writing an i2cdetect and test utility to allow drivers to be created. What do we think?

[pulkomandy]

We have a software implementation of I2C for probing EDID in VGA displays: ​http://xref.plausible.coop/source/xref/haiku/src/add-ons/accelerants/common/i2c.c

However I don't know if that would be of much help here.

i2cdetect itself will be easily ported, however, you will need drivers for whatever implements the I2C bus in your case. There is a standard one on motherboards (SMBus), there is a separate one for EDID display (on the graphics card), and there may be more (the datasheet for the touchpad apparently suggests wiring it to the WiFi controller). So, before going further, you would need to figure out which I2C controller is actually used to connect this touchpad. You will need a driver for that, and only then you can make a driver for the touchpad itself.

I2C is a standard protocol, but there is no standard host controller for it (like there is XHCI for USB, for example). The protocol is simple and slow enough that it can be implemented entirely in software using a GPIO line (manually driving the pins to 1 and 0 with careful timing to create the required signal), but it can also be done in hardware, to save CPU use, especially if there is a lot of data to send or it runs at high speeds.

The file I linked is a software implementation.

We also have the i2c_core.c you linked already in tree: ​http://xref.plausible.coop/source/xref/haiku/src/add-ons/kernel/drivers/dvb/cx23882/i2c_core.c (this one is in a driver for TV tuners, I2C is originally a TV manufacturer standard, to simplify wiring in TVs as they started adding more and more electronics to them).

And we have various I2C implementations in video drivers (also for EDID), some using the generic file I linked above, some using custom code, apparently (and they should be refactored to use the common code, I guess, unless there is indeed some hardware acceleration going on).

It probably makes sense to implement a driver exposing your I2C bus in a way compatible to either FreeBSD's or Linux tools (implementing the same ioctls).

[adamfowleruk]

From the discussions on the Linux Kernel site about my device, it appears the keyboard connects to the I2C adapter on the Intel PCH south bridge. This is detectable from PCI (See #14980 for PCI ids file issue). This supports SMBus rather than generic I2C.

So I'll need to detect Intel chips and their PCH subsystems, then expose an SMBus compliant interface in order to talk to various types of hardware.

On the plus side, it will also give Haiku access to other sensors and devices that may be attached. Anything from temperature sensors, to accelerometers, to trackpads... And my keyboard. :)

I'll start reading the source for how Linux and FreeBSD do it, then write a proposal for you guys, before I write any code. It's probably a fairly big job, even if the protocol itself is simple. Drivers built on top of drivers...

[pulkomandy]

That makes sense then (from a costs saving perspective, at least), they can get rid of the whole PS/2 support and use the existing SMBus wiring.

So, you will need an SMBus bus and bus_manager, using the device_manager API. It can publish the bus under /dev/bus/i2c/... for linux/freeBSD userland tools to play with it (this will ease testing, I guess), and expose a way for kernel-side drivers to probe it for devices and publish their own nodes.

[waddlesplash]

So, actually what's going on here is that there is a new (yes, imagine that!) type of PS/2 multiplexing called "active multiplexing" that we need to implement at the bus level.

Here's the FreeBSD commit implementing just enough of it to do configuration, from November of just last year: ​https://github.com/freebsd/freebsd/commit/96d45629821938bb1112a2927535366404775290

It's possible, since our PS/2 system is simpler, that we could get away with even less than the ~250 lines FreeBSD needs. Either way, someone with the relevant hardware will need to attempt the work... :)

[waddlesplash]

Hmm, actually it seems the multiplexing we implement already is "active multiplexing", though it looks like this is a newer version than we actually support.