Fujitsu Lifebook scroll device support

Mister Genero · 04-17-2021, 03:17 PM

I updated the github code to do the following:
1) Raw data dump to the kernel log is now controlled by the #define FJS_LOG_PACKETS, found in fujitsu_scroll.h, and it defaults to 0, or off. At least on my machine, the packet format I documented is proving accurate and all the logs were drowning out more interesting stuff.

2) Instead, it spits out possible user events to the log. It's not perfect, but looks pretty close. I tried defining the scroll action to generate multiple steps if the position change was big enough, but it samples so frequently that it was very hard for me to ever get it to report more than one step at a time. So I made it simple.

3) I pared down the init sequence significantly. Looks like it takes a single sliced command byte, and so long as bit 7 (0x80) in that byte is set, it'll report data. Interestingly, if bit 5 (0x20) is also set, only the button press events get reported - weight and position are always 0. It's not obvious that any of the other bits are significant.

What's next:
1) Actually register with the Linux input subsystem and generate real events
2) Chase down what's causing those random resets, which will probably feel to the user like little hiccups in responsiveness.
3) See about defining driver parameters so a recompile isn't needed for every single change
...
X) WAY down the line: consider alternate modes of operation (in the driver). I have some ideas but I don't want to get lost putting the cart before the horse.
Y) See how hard it would be to get this submitted into the kernel

Mister Genero · 04-17-2021, 07:15 PM

Another checkin. It basically works. Feel free to give feedback, make adjustments, etc., and I'll listen or ignore as I see fit

.

There are some #defines in fujitsu_scroll.h worth mentioning (well, they ALL are, but these especially):

FJS_LOG_PACKETS 0 // set to 1 to re-enable logging all raw packets
FJS_LOG_POSSIBLE_EVENTS 0 // set to 1 to re-enable logging hypothetical events
FJS_LOG_FUNCTIONS 0 // set to 1 to re-enable logging function entries
FJS_SEND_EVENTS 1 // set to 0 to not send actual input events

FJS_WEIGHT_THRESHOLD 0x08 // There must be at least this much weight to
// consider a touch. Sometimes I've seen the value
// get stuck at a very low but non-zero level
FJS_POSITION_CHANGE_THRESHOLD 0x100 // Used for the possible events. Not actual
// events, though.
FJS_MOVEMENT_BITSHIFT 8 // How much to bitshift right the position value for
// scroll values. May need tweaking

SCerovec · 04-18-2021, 04:09 AM

:Holding the fingers crossed but not holding the breath:

This is awesome - so far it looks more than promising - and all without the slightest help from the OEM.

I wish i could spare more time on this right now.

Mister Genero · 04-18-2021, 09:34 AM

It's like a puzzle, and *just* enough pieces kept falling into place... As a side "benefit", I now know way more about the obsolete PS/2 mouse protocols and even more obsolete i8042 interface than I ever thought I would.

Don't worry about not having time for it. For some reason I'm finding this fun, and will keep pecking away at it. Of course, you're then stuck at my timetable, which is also limited to a few hours here and there.

One thing I am really curious about is the device detection. Right now, it only probes if the DMI says it's on a T901. From photos I've seen, I think the T900 has a scroll sensor but no scroll wheel. And those may be the only two laptop models with these things. Since I'm not about to buy a bunch of T900s/T901s off EBay, it would be nice to get confirmation that things work on machines other than my own.

- I need to revamp the event generation code, the first effort was mostly PoC. It works, but isn't as consistent as it could be, and that's really important in a user interface. If you code much, feel free to have a hack at it yourself. If not, well, no shame in that but you're again at the mercy of my timetable.

- I still want to see what I can do about all the resets. I think it's a matter of too many packets; playing around with data rates didn't seem to help.

- Eventually, I will probably come up with a userspace version, because I have some ideas about non-standard uses I'd like to play with that don't belong in a kernel mouse driver (for instance, turning the wheel into a d-pad). That will likely still require at least a semi-nonstandard kernel configuration (to expose both serio and uinput).

- And I still have the lofty goal of getting code of mine incorporated into the kernel.

Since my main goal is complete and what's left is mostly tweaking, I'm going to stop posting so many updates here. (Besides, I would often post an update, get to thinking about it, and then make further changes which make my post less relevant.) Progress will continue on Github. I should still be reachable here or via the email address in fujitsu_scroll.c .

SCerovec · 04-18-2021, 04:47 PM

There is always the option of living as an out of tree module IMHO.

I'm glad you find fun in this

Mister Genero · 04-18-2021, 06:32 PM

Shrug. Guess I'm just weird that way. Some people do jigsaw puzzles.

The problem with being an out-of-kernel module is that this is really a small piece of code that fits inside the existing larger psmouse module. But we'll see.
---
Actually, an out-of-kernel module makes way more sense than a userspace version. It could just be a stripped down version of psmouse (remove all the code/devices the T901 will never have connected to its i8042) + this scroll stuff. To use it you'd have to compile a kernel with i8042 support but not psmouse (or, compile psmouse as a module and then unload it). That would also provide an easy way to get parameters in, and thus non-standard behavior modes (like D-Pad, as mentioned before).

Side note, I've tweaked the input subsystem interactions and this version of the driver actually feels usable. I had to shift away from reporting the 'middle' button because accidental presses were causing all sorts of trouble. You can muck about in fujitsu_scroll.h to change things around.

Mister Genero · 05-02-2021, 07:22 AM

You can now dump the contents of the github repository into a recent version of the kernel source, then enable scroll device support through the kernel config menus. (You'll still have to dive deep into the input / mouse / psmouse settings.)

SCerovec · 05-05-2021, 11:20 AM

That's beyond awesome!

lofisofi · 12-27-2022, 06:15 AM

I know this is an old thread, but some excellent news: After making the code check for the Fujitsu Lifebook P772 in the DMI table instead of the T901, the scroll wheel worked without any further modifications! This was with the 6.1.1 kernel with the otherwise default Arch Linux configurations.

Here's an except of my Xorg log which shows it being detected:

Code:

[     7.866] (II) config/udev: Adding input device FujitsuPS/2 Fujitsu Scroll Wheel (/dev/input/event7)
[     7.866] (**) FujitsuPS/2 Fujitsu Scroll Wheel: Applying InputClass "libinput pointer catchall"
[     7.866] (II) Using input driver 'libinput' for 'FujitsuPS/2 Fujitsu Scroll Wheel'
[     7.866] (**) FujitsuPS/2 Fujitsu Scroll Wheel: always reports core events
[     7.866] (**) Option "Device" "/dev/input/event7"
[     7.867] (II) event7  - FujitsuPS/2 Fujitsu Scroll Wheel: is tagged by udev as: Mouse
[     7.867] (II) event7  - FujitsuPS/2 Fujitsu Scroll Wheel: device is a pointer
[     7.867] (II) event7  - FujitsuPS/2 Fujitsu Scroll Wheel: device removed
[     7.907] (**) Option "config_info" "udev:/sys/devices/platform/i8042/serio3/input/input13/event7"
[     7.907] (II) XINPUT: Adding extended input device "FujitsuPS/2 Fujitsu Scroll Wheel" (type: MOUSE, id 13)
[     7.907] (**) Option "AccelerationScheme" "none"
[     7.907] (**) FujitsuPS/2 Fujitsu Scroll Wheel: (accel) selected scheme none/0
[     7.907] (**) FujitsuPS/2 Fujitsu Scroll Wheel: (accel) acceleration factor: 2.000
[     7.907] (**) FujitsuPS/2 Fujitsu Scroll Wheel: (accel) acceleration threshold: 4
[     7.908] (II) event7  - FujitsuPS/2 Fujitsu Scroll Wheel: is tagged by udev as: Mouse
[     7.908] (II) event7  - FujitsuPS/2 Fujitsu Scroll Wheel: device is a pointer
[     7.909] (II) config/udev: Adding input device FujitsuPS/2 Fujitsu Scroll Wheel (/dev/input/mouse0)
[     7.909] (II) No input driver specified, ignoring this device.
[     7.909] (II) This device may have been added with another device file.

And some evtest logs showing it is indeed working:

Code:

Input driver version is 1.0.1
Input device ID: bus 0x11 vendor 0x2 product 0x17 version 0x0
Input device name: "FujitsuPS/2 Fujitsu Scroll Wheel"
Supported events:
  Event type 0 (EV_SYN)
  Event type 1 (EV_KEY)
    Event code 272 (BTN_LEFT)
    Event code 273 (BTN_RIGHT)
  Event type 2 (EV_REL)
    Event code 0 (REL_X)
    Event code 1 (REL_Y)
    Event code 8 (REL_WHEEL)
Properties:
  Property type 0 (INPUT_PROP_POINTER)
Testing ... (interrupt to exit)
Event: time 1672143196.567579, type 2 (EV_REL), code 8 (REL_WHEEL), value -1
Event: time 1672143196.567579, -------------- SYN_REPORT ------------
^EEvent: time 1672143196.707516, type 2 (EV_REL), code 8 (REL_WHEEL), value 1
Event: time 1672143196.707516, -------------- SYN_REPORT ------------
^YEvent: time 1672143197.145630, type 2 (EV_REL), code 8 (REL_WHEEL), value -1
Event: time 1672143197.145630, -------------- SYN_REPORT ------------
^EEvent: time 1672143198.003364, type 2 (EV_REL), code 8 (REL_WHEEL), value -1
Event: time 1672143198.003364, -------------- SYN_REPORT ------------
^EEvent: time 1672143198.025237, type 2 (EV_REL), code 8 (REL_WHEEL), value -1
Event: time 1672143198.025237, -------------- SYN_REPORT ------------
^EEvent: time 1672143198.905014, type 2 (EV_REL), code 8 (REL_WHEEL), value -1
Event: time 1672143198.905014, -------------- SYN_REPORT ------------
^EEvent: time 1672143199.275630, type 2 (EV_REL), code 8 (REL_WHEEL), value -1
Event: time 1672143199.275630, -------------- SYN_REPORT ------------
^EEvent: time 1672143199.437734, type 2 (EV_REL), code 8 (REL_WHEEL), value -1
Event: time 1672143199.437734, -------------- SYN_REPORT ------------
^EEvent: time 1672143199.623997, type 2 (EV_REL), code 8 (REL_WHEEL), value -1
Event: time 1672143199.623997, -------------- SYN_REPORT ------------
^EEvent: time 1672143200.040520, type 2 (EV_REL), code 8 (REL_WHEEL), value 1
Event: time 1672143200.040520, -------------- SYN_REPORT ------------

Now my only questions are, 1) how do I change the acceleration so it isn't so fast? and 2) is there a way to add some palm detection so it doesn't activate while typing?

Anyway, thank you so much for your work! This was something I never expected to see solved, so I really cannot express my gratitude enough. Since this works in the T901 as well as the P772, I imagine it's quite likely may actually work for other models as well!

Mister Genero · 12-27-2022, 07:42 PM

What were the exact DMI settings you used for the P772? From what you sent, it looks like the wheel is being detected, but there's no sensor strip (like there is on the T901). I can add them to the code. I can't know if the sensor probe code is harmless on all devices, which is why I use DMI to lock down which machines we run the probes on.

If there's any way to adjust the hardware's reporting sensitivity, I never found it. So the driver does its own filtering.

For sensitivity, there are values in fujitsu_scroll.h to look at:
FJS_CAPACITANCE_THRESHOLD 0x08
and
FJS_POSITION_CHANGE_THRESHOLD 0x04
FJS_MOVEMENT_BITSHIFT 3

The higher FJS_CAPACITANCE_THRESHOLD is, the more finger touch there needs to be before we consider it an actual touch (i.e. the less sensitive it gets).
The higher FJS_POSITION_CHANGE_THRESHOLD is, the more movement there needs to be before an event gets generated.
The higher FJS_MOVEMENT_BITSHIFT is, the smaller the amount of movement gets reported.

Hmm, a bitshift of 3 is equivalent to dividing by 8. But the change threshold is only 4. That makes it possible for movement values of 0 to get through. I don't know if that could cause issues.

Good news - I'm perfectly open to using better logic. This was done mostly as a proof of concept, and then adjusted the values to suit my liking.

lofisofi · 12-28-2022, 07:25 PM

Quote:

Originally Posted by Mister Genero

What were the exact DMI settings you used for the P772? From what you sent, it looks like the wheel is being detected, but there's no sensor strip (like there is on the T901). I can add them to the code. I can't know if the sensor probe code is harmless on all devices, which is why I use DMI to lock down which machines we run the probes on.

I changed nothing other than lines 30 and 36 in fujitsu_scroll.c to match 'LIFEBOOK P772' / 'LifeBook P772' instead of 'LIFEBOOK T901' and 'LifeBook T901', so this means the code seems to be ready to run pretty much without any changes.

Quote:

Originally Posted by Mister Genero

For sensitivity, there are values in fujitsu_scroll.h to look at:
FJS_CAPACITANCE_THRESHOLD 0x08
and
FJS_POSITION_CHANGE_THRESHOLD 0x04
FJS_MOVEMENT_BITSHIFT 3

The higher FJS_CAPACITANCE_THRESHOLD is, the more finger touch there needs to be before we consider it an actual touch (i.e. the less sensitive it gets).
The higher FJS_POSITION_CHANGE_THRESHOLD is, the more movement there needs to be before an event gets generated.
The higher FJS_MOVEMENT_BITSHIFT is, the smaller the amount of movement gets reported.

Hmm, a bitshift of 3 is equivalent to dividing by 8. But the change threshold is only 4. That makes it possible for movement values of 0 to get through. I don't know if that could cause issues.

Good news - I'm perfectly open to using better logic. This was done mostly as a proof of concept, and then adjusted the values to suit my liking.

Thanks for this! What exactly is the range of values? For example, how does a capacitance_threshold of 0x08 compare to 0x09? or 0x18?

Let me know if you need to do any testing in the future, by the way. I would be happy to test any updates to the driver!

Mister Genero · 12-30-2022, 06:08 PM

Capacitance seems to be 6 bits. I documented my findings in the file 'protocol.txt' in the repository. (Actually, I only documented my meaningful findings. There were a bunch of things I tried and verified were NOT how the sensor worked.) I forget if it tops out at 111111 (0x3F) or some other value, but I think if there was some hard limit lower than that I'd have noted it. I call it 'capacitance' because that's consistent with how the value behaves, and how I understand the sensor operates.

So, in the next couple of days, I'll add definitions for your laptop to the code.

How much can you code? If you want to try to mess around with it, the place to look would be the fujitsu_scroll_process_packet function in fujitsu_scroll.c . It pulls the movement and capacitance info from a completed data packet, and figures out what (if any) kind of event to send to the kernel.

lofisofi · 02-07-2023, 08:52 AM

Hello, sorry for disappearing for a while. Quite busy this year so far!

I just tried recompiling the driver again for 6.1.10 but now it's no longer being detected. I'm not so sure why this is the case yet, so I'll have to look into it.

I haven't worked with C in a very long time and certainly never with a kernel driver before, but I might take a poke around when I have a chance. Is there a way to test it without recompiling my whole kernel every time? That's what I'm currently doing, which means I'm waiting at least 5 hours between tests.

Kudos to you again for all you've managed to do. I admire all the hard work you've put in!

Mister Genero · 02-08-2023, 04:54 PM

Hmm. I can take a closer look over the weekend. The only change I made was to add the DMI for P772 laptops. I then dropped the code into 5.15.80 (the latest kernel offered by Gentoo), compiled, tested that it worked (at least on my P901), and pushed the updated code to GitHub. I can try with whatever the latest is on tap at kernel.org.

I was thinking about making the DMI part optional anyway. It's really only a double safety check. It uses the same probe (sequence of bytes sent to the 8042 controller) that the Synaptics driver uses, it just looks for a different response. The DMI check simply restricts that probe to laptop models we know might actually have the hardware. It pretty much eliminates the possibility of a false positive. Such an event is already highly unlikely, but there's so much varied hardware out there that it can't otherwise be ruled out.

As for compiling (the only thing my P901 lags at, since I put an SSD into it), what I generally do is compile the PS/2 mouse support as a module (psmouse.ko). "make modules" can still take a very long time, but if you're already doing a custom kernel you can whittle down the number of modules that get compiled to a very small number.

So from the command line:
cd /usr/src/linux
make modules
make modules_install
rmmod psmouse
modprobe psmouse

Assuming the kernel you're currently running was built from /usr/src/linux, and it was set for PS/2 mouse support to be modular, that will build the modules, install them on disk, remove the existing in-memory psmouse module, and load the new one.

As a reminder though, that only really helps if you turn off the tons of drivers/modules you're not going to need on your Fujitsu laptop.

Mister Genero · 02-11-2023, 09:30 AM

I downloaded 6.1.11 from kernel.org and took a look. It's definitely not compatible, or at least it won't work to copy over my files from github. It's possible that if I took a diff of my changes against a 5.x kernel, then applied that as a patch to a 6.x kernel, it might work. Too soon to tell.

Essentially, it looks like some housekeeping stuff got modified. If you copy over my files for the 5.x kernels, you'll get 5.x-style housekeeping when you want the 6.x version.

It would be real easy to just update to 6.x, but I would like to keep compatibility at least for now. Time for a branch? I'll look into this - I'm going to have to deal with it sooner or later anyway.

So, on my immediate TODO list:
- Have 5.x and 6.x versions
- Make DMI checking a compile time configurable option
- Make sensitivity thresholds adjustable (preferably runtime)