Fujitsu Lifebook scroll device support

Mister Genero · 04-01-2021, 09:33 AM

This thread is an offshoot of an earlier one regarding hardware support for the Fujitsu T901 hybrid laptop. It was noted that there is currently no Linux support for the two scroll devices on it (scroll wheel, scroll sensor), but some preliminary investigation showed it might be possible to add it.

I believe the scroll devices probably exist on other Fujitsu laptops as well, but I only have a single T901 in my possession to work with.

Original thread:
https://www.linuxquestions.org/quest....php?p=6235699

Mister Genero · 04-01-2021, 10:02 AM

Both the scroll wheel (a circular indentation next to the trackpad, which the user is supposed to be able to move their finger around in circles to emulate a scroll wheel), and the scroll sensor (a straight area on the display bezel, which the user can move their finger up and down on for the same effect) are attached to the legacy i8042 keyboard/mouse controller as serio2 and serio3, respectively. (The actual trackpad is a Symantics trackpad, serio4. Nothing appears to be connected to serio1, and the laptop does NOT have a ps/2 port.)

Multiplexing on this i8042 seems to work. The scroll devices get detected as generic PS/2 mice, but the data they return gets ignored as it does not adhere to any standard PS/2 protocol. It appears designed to mimic the 6-byte frames of the Synaptic pad, but it doesn't strictly adhere to that either.

Right now, I've modified drivers/input/mouse/synaptics.c in the kernel to accept the scroll devices. (The probe it does is safe, since it's the same probe that's always been used to look for synaptic devices. However, I don't know if it might generate false positives for other hardware. We can use DMI tables to restrict the probe to particular laptop models, but then we risk missing scroll devices that might exist on models we don't know about. In particular, I think we might want to look at the Fujitsu S761.)

Forcing the driver to accept devices which return an ID byte of 0x43 in addition to the Synaptics 0x47 is what does the trick. Then, a few error conditions (caused by unfamiliar data) are commented out. Once that's done, the kernel parameter "i8042.debug=1" shows both scroll devices returning data packets. The driver, of course, doesn't know what to do with the data because it's only *similar* to genuine synaptics data.

Data appears to come in 6-byte packets from both scroll devices. The bits in 80 00 00 C0 00 00 are always set. As data is coming in, only the first three bytes change - they are always followed by c0 00 00.

As I have time, I'll put together something that allows us to take data dumps of incoming packets, so we can maybe figure out what user interactions generate what kind of data. Since the number of possible parameters that can be reported are limited (touch 'pressure' - capacitative presence; movement direction; position; speed), and we don't even know if all of those are reported by hardware or are expected to by synthesized by the driver, it shouldn't be too hard.

SCerovec · 04-02-2021, 11:03 AM

Just so You know im subscribed and interested in running trials you ask for.
maybe add tags:
synaptic, scrollwheel, scrollpad?

Mister Genero · 04-03-2021, 06:59 PM

First thing, run 'dmidecode' and see what it says under "System Information". On my machine, it says:

Code:

System Information
	Manufacturer: FUJITSU
	Product Name: LIFEBOOK T901

But I've seen some stuff in the kernel to suggest that it might not necessarily always be reported in all caps. I don't know if that's actually the case, or if somebody was just being cautious.

In Gentoo, dmidecode is provided by the 'sys-apps/dmidecode' package; I don't know how you might get it in Slackware, but the project URL is http://nongnu.org/dmidecode/

Also, does your T901 have a dual digitizer? Mine does not, and only recognizes stylus touches on the screen, not finger touches. I can't imagine that finger sensing would be routed through serio1 on the i8042 as a mouse, but it'd be good to confirm.

Mister Genero · 04-04-2021, 04:09 PM

Fujitsu S762 had a scrollwheel. Somebody posted a kernel patch that modified the Alps driver to support it; it doesn't look like that ever went anywhere. In any event, the code doesn't seem to do anything for the T901, which doesn't have an Alps device.

For reference: https://www.spinics.net/lists/linux-input/msg25786.html

SCerovec · 04-05-2021, 12:04 AM

Quote:

Originally Posted by Mister Genero

First thing, run 'dmidecode' and see what it says under "System Information". On my machine, it says:

Code:

System Information
	Manufacturer: FUJITSU
	Product Name: LIFEBOOK T901

But I've seen some stuff in the kernel to suggest that it might not necessarily always be reported in all caps. I don't know if that's actually the case, or if somebody was just being cautious.

In Gentoo, dmidecode is provided by the 'sys-apps/dmidecode' package; I don't know how you might get it in Slackware, but the project URL is http://nongnu.org/dmidecode/

Also, does your T901 have a dual digitizer? Mine does not, and only recognizes stylus touches on the screen, not finger touches. I can't imagine that finger sensing would be routed through serio1 on the i8042 as a mouse, but it'd be good to confirm.

Code:

System Information
        Manufacturer: FUJITSU
        Product Name: LIFEBOOK T901
        Version: 10601409549

check

The Alps driver illustrates my point exactly, while unmaintained drivers fall aside the road during kernel development, for unmaintained userspace tools it is usually sufficient to just download, do some editing and it compiles again.

Mister Genero · 04-06-2021, 04:59 PM

We're gonna have to agree to disagree on this one. I'm not getting paid for this, so I may as well do whatever seems like more fun. And right now, that means modifying the kernel. As I said before, it wouldn't be hard to shift to user space if need be.

In the meantime, I'll be looking at i8042 comms by passing "i8042.debug=1" as a kernel parameter upon boot. (As I mentioned, I can only devote a little time to this here and there.)

Code:

dmesg -w |tee dmesg.out

Lines which end in "(interrupt, 3, 12)" are bytes coming from the wheel, "(interrupt, 4, 12)" are coming from the sensor. ('1' is the keyboard, '5' is the touchpad. You may see a 'MUX error' attempting to access serio1, which is actually a timeout and that makes sense because it's not connecting to anything.) Most of those will be the 'fa' that the hardware devices use to confirm every byte/command they've received. The interesting stuff is when there's a steady stream of such bytes, indicating incoming packets.

Mister Genero · 04-10-2021, 08:12 AM

This appears to be the proper init sequence for both wheel and sensor:

Code:

void fujitsu_scroll_init_sequence(struct psmouse *psmouse) {
  struct ps2dev *ps2dev = &psmouse->ps2dev;
  u8 param[4] = { 0 };
  int error;
  psmouse_info(psmouse, "fujitsu_scroll_init_sequence");
  
  error = ps2_sliced_command(ps2dev, 0x00);
  ps2_command(ps2dev, param, PSMOUSE_CMD_GETINFO);
  error = ps2_sliced_command(ps2dev, 0x03);
  ps2_command(ps2dev, param, PSMOUSE_CMD_GETINFO);
  error = ps2_sliced_command(ps2dev, 0x0a);
  ps2_command(ps2dev, param, PSMOUSE_CMD_GETINFO);
  error = ps2_sliced_command(ps2dev, 0x02);
  ps2_command(ps2dev, param, PSMOUSE_CMD_GETINFO);
  error = ps2_sliced_command(ps2dev, 0x08);
  ps2_command(ps2dev, param, PSMOUSE_CMD_GETINFO);
  error = ps2_sliced_command(ps2dev, 0xc4);
  param[0] = SYN_PS_SET_MODE2; // 0x14
  ps2_command(ps2dev, param, PSMOUSE_CMD_SETRATE);
  error = ps2_sliced_command(ps2dev, 0xc4);
  ps2_command(ps2dev, param, PSMOUSE_CMD_SETRATE);
  
}

Not all of that may be necessary, especially the first sliced/command pair.

Mister Genero · 04-10-2021, 06:48 PM

Okay - I have a drop-in driver that simply reports packets. It's a hacked up, simplified version of the synaptics driver, because that's where I started my investigations. I'll put it up here (or, more likely, put it on github and provide a link) soon, I want to clean up some of the cruft first.

First observations of the packets:
As mentioned, only the first 3 bytes of the 6 byte packets actually change, the other 3 appear to be there for framing.
Here's an example packet from dmesg output: a5/0f/92 c0/00/00
The second byte, here '0f', reports position. Only the lower 4 bits change, so values can range from 00 to 0f. On the scroll wheel, '00' is at the top of the wheel (at 12, if it were a clock), and proceeds clockwise around the rim. On the scroll sensor, '00' is at the end closest to the Fujitsu logo in the center, '0f' is closest to the left edge of the screen.

Technically, that's enough information to implement a driver that emits scroll button presses. I'll bet the other incoming data would let us make it a lot nicer, though.

Both devices appear to get out of sync easily and require resetting. That reset happens so fast it'll go unnoticed by the end user. I wonder if they truly just sometimes trip over themselves, or if there's another data form that I'm missing. (The reset happens in some of the leftover synaptics code, so it might even just be spurious.)

BTW, I've compiled my kernel to have psmouse be a module. This lets me swap experimental versions in and out pretty quickly, then revert back to the stock, stable version when I'm done. No need to recompile a whole kernel or reboot to test.

Mister Genero · 04-10-2021, 06:56 PM

The above is actually a very strong argument for having a driver in user space. So long as the code is kept in the kernel (in the form of something that might ever have a chance of getting included), we have to just emulate mouse behavior as best we can. Go to user space, and you can turn it into whatever bizarro non-standard user interface you'd like. Turn the scroll wheel into 15 individual buttons if you like (a bad example).

I'm still going with a kernel driver first, on the premise that once the protocol is learned it'll be a piece of cake to do it either way.

Mister Genero · 04-11-2021, 10:05 AM

Code:

/*
 * Fujitsu Scroll device PS/2 mouse driver
 *
 * Scroll Wheel packets
 *  Bytes 0,1,2:  1 0 c c c c c c  0 0 0 0 a a a a  a a a a a a a a
 *  Bytes 3,4,5:  1 1 0 0 0 0 0 0  p 0 0 0 0 0 0 0  0 0 0 0 0 0 0 0
 *
 *  c - 6 bits, capacitance, how much capacitance is detected.
 *              Seems to be highest around a ring inside the wheel
 *              circle, decreasing the farther the finger is from
 *              that ring
 *  a - 12 bits, angle, the angle of the wheel where touch is sensed
 *               the upper 4 bits are 'f' when the touch is at the
 *               top of the wheel (12 o'clock), and loops back to 0.
 *               Increased in a clockwise direction.
 *  p - 1 bit,  pressed, is the wheel being touched in the center.
 *
 *  Multitouch is not supported.  If one or more fingers are added to
 *  a first one that's touching, the reported angle will stay the same
 *  but the capacitance and center press may change.
 *
 *
 * Scroll Sensor packets
 *  Same as scroll wheel, except the 'a' angle is now position, with
 *  lower values to the right and higher values to the left, and 'p'
 *  now indicates whether a spot on the bezel about 0.5cm left of the
 *  sensor is being touched.  There is no indication on the bezel where
 *  this spot is.  Unlike the wheel, it is very possible for 'p' to be 1
 *  and both 'c' and 'a' to be 0.  (Although they may not be if both this spot
 *  and the sensor are being touched simultaneously.)
 */

Every now and then the generic portion of the psmouse driver decides that one or the other sensor needs to be reconnected. If, at that time, we don't send the init sequence (shown in a previous post), the driver will fail to recognize any further input.

Some of those 0 bits may be used for hardware error conditions that my machine simply has never experienced. Also, we don't know if the sensors can be put into different modes that might produce different output (but how many modes could there be for these simple things?).

SCerovec · 04-11-2021, 05:08 PM

Excellent progress thus far!

Looking forward to help if anything needed.

Keep up the good work

Mister Genero · 04-11-2021, 06:37 PM

Okay, I've put the code changes in GitHub: https://github.com/sammertens/fujitsu_scroll

So now you can divine Mister Genero's secret identity (whoopity doo

.

Right now, all the code does is spit out the data packets to the kernel log (which will quickly get flooded, as it's circular). I strongly recommend you compile psmouse as a module, and don't install it in /lib/modules/*wherever*, instead just building it in your linux source directory and loading it via insmod:

Code:

cd /usr/src/linux
make modules
rmmod psmouse
insmod drivers/input/mouse/psmouse.ko

You can revert to the standard psmouse driver via:

Code:

rmmod psmouse
modprobe psmouse

While it's loaded, 'dmesg -w' will let you see the output. Play around with the sensors and see if the data you get jives with what I wrote about the protocol. Bonus points if you can get it to do something unexpected or prove one of my assumptions wrong (I won't mind, promise

.

I'll add README documentation to GitHub before too long.

The code was written against the Gentoo-patched Linux kernel 5.4.97, and it looks like it'll drop cleanly into Gentoo-patched 5.10.27 (it'll probably be fine with stock kernel code, but let me know if you run into issues). The changes to psmouse.h and psmouse-base.c are minimal: I just added definitions for the Fujitsu Scroll driver and a call to the detection code. fujitsu_scroll.c and fujitsu_scroll.h can certainly be cleaned up more, but I think I got rid of the bulk of Synaptics code that turned out to be unrelated. I don't think PS/2 support code changes very much these days.

SCerovec · 04-12-2021, 03:04 AM

Will report as i get the time for a proper session

Mister Genero · 04-12-2021, 08:40 PM

Quick note, can confirm the files I put up on GitHub can be dropped cleanly into the latest kernel (5.12-rc7, it looks like) and compiled without error.

I wrote Fujitsu about documentation. I got a very quick, polite "NO" - if it's not on their website they're not going to make it available. I'm sure there are tech specs buried in a filing cabinet somewhere but their customer service is not set up to go dig them up upon request.