Support for Force-Feedback

[poisonnuke]

Hello @robotrovsky
may I ask in the first play, how you where able to determine all the values for the driver? Reverese-Engineering by intercepting the communications?

I am interested in the force-feedback functionality, disabeling the default force-touch and sending my own events. If possible with different profiles.

[mwyborski]

Hi @poisonnuke
Yes, i tried to reverse engineer the protocol, but in the hid-magicmouse was already the parsing of the Magic Trackpad 1,which seems to be similar or the same. I can not tell because i have no MT1.
The format is as follows:
header + 9 bytes finger report for each recognized touch.
The header in USB is 12 bytes and in bluetooth mode 4 bytes.

Look at magicmouse_emit_touch to see the 9 bytes finger report are:

		id = tdata[8]& 0xf;
		x = (tdata[1] << 27 | tdata[0] << 19) >> 19;
		y = -((tdata[3] << 30 | tdata[2] << 22 | tdata[1] << 14) >> 19);
		size = tdata[6] & 0x3f;
		orientation = (tdata[7] >> 2) - 32;
		touch_major = tdata[4];
		touch_minor = tdata[5];
		state = tdata[7] & TOUCH_STATE_MASK;

I am pretty sure,that x,y, touch_major and touch_minor are correct, but the rest may contain errors. You can debug the 9 bytes finger report and check, if it works for you. Regarding force-touch you can look at this driver from ponyfleisch,which makes use of force touch in bluetooth:
https://github.com/ponyfleisch/hid-magictrackpad2

[rohitpid]

What tool did you use for to figure out the headers and length of finger report? I'd like to try to make the magicmouse2 work with this driver. Also, can we merge ponyfleish's force touch work back into this driver so that we can mainline all the features?

[rohitpid]

I managed to get magic mouse 2 to register with hid_magicmouse now. However, scrolling isn't working. How did you reverse engineer that part of the protocol?

[mwyborski]

@rohitpid when i first started with the magictrackpad 2 i connected it to windows and used wireshark to sniff the USB communication to see how Trackpad++ switches to multi finger reporting, during development i compared the outcome with the trackpad of my macbook. Later i also used a Beagle USB to sniff the USB communication on Mac OSX. But there is also a apple tool to sniff the communication called Packet Logger. I haven't tested it, but @ponyfleisch used it for looking at the bluetooth protocol. The bluetooth and USB protocols are different.

[rohitpid]

@robotrovsky I have basic working changes for magic mouse 2 now!

[poisonnuke]

@rohitpid have you found something regarding the haptic feedback engine?

[rohitpid]

@poisonnuke nope I haven't looked at it yet sorry.

[poisonnuke]

@robotrovsky where you able to create a new usb-trace recently? because I have no MacOSX where Wireshark works and no Beagle too. And as mentioned, I cant find any valid USB-Request in your last trace :(

[mwyborski]

@poisonnuke i am sorry, but i have no other usb-trace

[dos1]

@poisonnuke Have you seen #28?

[nexustar]

After reading the code of @mwyborski @dos1 @ponyfleisch , I added support to change click pressure and haptic feedback for magic trackpad 2 based on mainline driver. It works on both usb and bt. https://github.com/nexustar/linux-hid-magicmouse

[alice-mkh]

@nexustar any plans for mainlining your changes?

[dos1]

@nexustar Any reason to rely on host clicking? Back when I was figuring this stuff out I pursued a solution with device clicking because host clicking increases latency, which was especially noticeable over Bluetooth.

The main reason I didn't send my code upstream so far was because it uses hid_to_usb_dev, which breaks HID replay, so it's unlikely that it would be accepted. I see that your code shares the same problem. Meanwhile I've also noticed stability issues when using it over USB - it was pretty rare on my laptop, but quite easy to trigger on my phone. Haven't tried your code yet, but in case you based it on mine it's something you should be aware of. And these days I'm actually less convinced that this stuff even belongs to the kernel at all. I'd rather look into writing an user-space app that could configure the touchpad's haptic feedback, which I guess could be done via hidraw and/or libusb. I'm not using this touchpad anymore as often as I used to though, so it stays in my TODO list at a rather low priority ;)

[dos1]

Nevermind the stability issues - looks like it may have been fixed in torvalds/linux@4fb1251 and torvalds/linux@4b4f6ce which means it wasn't my fault :)

[alice-mkh]

Any reason to rely on host clicking?

The click type setting on macOS changes pressure threshold as well, not just feedback strength. It may be doable with device clicking, but not sure - macOS seems to use host clicking as well and settings there only affect feedback when using the same touchpad in linux, and none of the values in the message that sets feedback seems to change the threshold.

[nexustar]

Any reason to rely on host clicking?

The click type setting on macOS changes pressure threshold as well, not just feedback strength. It may be doable with device clicking, but not sure - macOS seems to use host clicking as well and settings there only affect feedback when using the same touchpad in linux, and none of the values in the message that sets feedback seems to change the threshold.

you are right

[nexustar]

@nexustar Any reason to rely on host clicking? Back when I was figuring this stuff out I pursued a solution with device clicking because host clicking increases latency, which was especially noticeable over Bluetooth.

The main reason I didn't send my code upstream so far was because it uses hid_to_usb_dev, which breaks HID replay, so it's unlikely that it would be accepted. I see that your code shares the same problem. Meanwhile I've also noticed stability issues when using it over USB - it was pretty rare on my laptop, but quite easy to trigger on my phone. Haven't tried your code yet, but in case you based it on mine it's something you should be aware of. And these days I'm actually less convinced that this stuff even belongs to the kernel at all. I'd rather look into writing an user-space app that could configure the touchpad's haptic feedback, which I guess could be done via hidraw and/or libusb. I'm not using this touchpad anymore as often as I used to though, so it stays in my TODO list at a rather low priority ;)

• I need host clicking because It is hard too click for me and I dont feel unacceptable latency ( maybe because of my bt 5.0 adapter ?
• stability issues is cause by NULL point, after fix,you could try my code, it is steady
• I think configure the trackpad in user-space is a good idea, but host clicking needs sending packet whenever you want the trackpad be clicked. so we had better do it in kernel.
• I am new to kernel development, could you please tell me more about why hid_to_usb_dev is unacceptable?

[NicoWeio]

I'd rather look into writing an user-space app that could configure the touchpad's haptic feedback, which I guess could be done via hidraw and/or libusb.

That might be in scope for https://github.com/libratbag/piper/ (https://github.com/libratbag/libratbag) :)

[NicoWeio]

Looks like https://github.com/dos1/Linux-Magic-Trackpad-2-Driver allows for changing the haptic feedback without host clicking. I didn't notice changes in sensitivity doing this.
See also #28 (comment).