Opened 3 months ago

Last modified 3 months ago

#14977 new enhancement

PS2: implement "active multiplexing"

Reported by: adamfowleruk Owned by: nobody
Priority: normal Milestone: Unscheduled
Component: Drivers/Input/PS2 Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All


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.

Attachments (4)

listdev.txt (3.0 KB) - added by adamfowleruk 3 months ago.
listusb.txt (612 bytes) - added by adamfowleruk 3 months ago.
syslog.txt (115.6 KB) - added by adamfowleruk 3 months ago. (460.4 KB) - added by adamfowleruk 3 months ago.
acpidump and wii demo output on Linux Mint when both trackpad and keyboard were working

Download all attachments as: .zip

Change History (14)

Changed 3 months ago by adamfowleruk

Attachment: listdev.txt added

Changed 3 months ago by adamfowleruk

Attachment: listusb.txt added

Changed 3 months ago by adamfowleruk

Attachment: syslog.txt added

Changed 3 months ago by adamfowleruk

Attachment: added

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

comment:1 Changed 3 months ago by 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.

comment:2 Changed 3 months ago by waddlesplash

Component: Drivers/InputDrivers/Input/PS2
Summary: Add support for devices in Recoil IIPS2: multiplexing and reset failed

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.

comment:3 Changed 3 months ago by pulkomandy

Synaptics docs on PS/2 multiplexing

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?

comment:4 Changed 3 months ago by adamfowleruk

comment:5 Changed 3 months ago by adamfowleruk

This looks promising as a base library to use for i2c communication:-

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

Linux i2cdetect source code (This tool is GNU GPL licensed unfortunately, but can provide inspiration)

FreeBSD I2C: FreeBSD i2cscan:

Last edited 3 months ago by adamfowleruk (previous) (diff)

comment:6 Changed 3 months ago by pulkomandy

We have a software implementation of I2C for probing EDID in VGA displays:

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: (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).

comment:7 Changed 3 months ago by 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...

comment:8 Changed 3 months ago by 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.

comment:9 Changed 3 months ago by waddlesplash

Summary: PS2: multiplexing and reset failedPS2: implement "active multiplexing"

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:

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... :)

comment:10 Changed 3 months ago by 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.

Note: See TracTickets for help on using tickets.