SB3 support

[NickyTope]

Tried installing both Arch and ubuntu in my new SB3 13.5 i7 32gb

In both cases uname reports the surface kernel however both the keyboard and trackpad do not function.

Is there anything I can do to help support this device?

Currently am back on windows but happy to install any distro again to test..

[StollD]

I think an acpidump would be the most useful thing right now, so that we can check if any device ID's changed on the SB3: https://github.com/linux-surface/linux-surface/wiki/Testers-and-Contributing#contributing-acpidumps

The output of lsmod and dmesg when running the surface kernel would be useful too.

[qzed]

Additionally, the output of ls -l /sys/bus/acpi/devices and ls -l /sys/bus/platform/devices would be helpful.

[NickyTope]

output from all the above attached

uname-r.txt acpidump.out.txt dmesg.txt lsmod.txt sys-bus-acpi-devices.txt sys-bus-platform-devices.txt

[qzed]

Can you also post the output of cat /sys/bus/acpi/devices/MSHW0117:00/path?

From the acpidump, I assume there's also no battery status?

[qzed]

Oh, and can you also upload the output of sudo dmidecode? It looks like the lid might also not be working without the workaround.

[qzed]

I've added the SID devices for the SB3 to the SID driver (feature/sb3 branch). Hopefully that's all that's necessary. Can you test this?

To do this, just follow the steps at https://github.com/linux-surface/surface-aggregator-module#buildtest-the-module. Let me know if you need more details.

After that the keyboard and trackpad should hopefully work and battery info should be present (for battery info, you might need to restart upower.service).

[NickyTope]

Wow, thanks for the quick responses. I'm in australia so that was overnight for me.. first the requested output: mshw0117-00-path.txt dmidecode.txt

I installed the module from the feature/sb3 branch and the battery status was immediately shown, unfortunately no input from the kb/trackpad still though.

a couple extra things to note.. I didn't have the surface-dtx-daemon installed so had to remove that from the unload script. I also tried installing the daemon but it doesn't want to start it reports:

$ sudo surface-dtx-daemon 
Error: Device access failure.
       No such file or directory (os error 2).

[qzed]

Regarding DTX: It seems like they have changed some stuff. I can't tell yet how much they've changed but they at least have removed the ACPI device. Could be that that's all they did and we can simply add it back in as SID device, or could be they've changed the SAM interface completely and we're going to need a new driver. Let's focus on the keyboard first.

Can you upload the dmesg log directly from when the modules are being loaded?

Can you also re-compile the module with debug output enabled? To do that you'll have to comment-in this line: https://github.com/linux-surface/surface-aggregator-module/blob/ae878ba1f4b340944779fbc818df7648cccdfc6e/module/Makefile#L38. After you've loaded the module, try typing and see if there are any messages showing up in dmesg.

[NickyTope]

dmesg-module-debug.txt no extra messages when typing, I did click the trackpad which created a bunch of extra messages, full output attached

[NickyTope]

dmesg when the module loads, without debug shows:

[  952.346675] hid-generic 0006:0000:0000.000B: item fetching failed at offset 0/0
[  952.346688] hid-generic: probe of 0006:0000:0000.000B failed with error -22
[  952.414876] Error: Driver 'surface_sam_sid_battery' is already registered, aborting...

[qzed]

By the looks of it, the basic keyboard interface should be the same (the target category is 0x15, the same as on the SL3). The messages from the touchpad seem similar to the ones we've seen at the beginning on the SL3 (without the HID feature stuff enabled).

As far as I can tell, things start to go wrong when the driver tries to get the device metadata:

[  409.294971] send: 00000000: aa 55 80 12 00 01 da 64 80 15 02 00 00 20 00 04
[  409.294972] send: 00000010: 02 00 00 00 00 76 00 00 00 00 10 dd

[  409.298587] recv: 00000000: aa 55 80 12 00 65 f8 48 80 15 00 02 00 20 00 04
[  409.298587] recv: 00000010: 02 00 00 00 00 00 00 00 00 ff 53 1e

No data is returned here. Same with the HID descriptor.

We've already noticed on the SL3 that the keyboard and trackpad are separated with an instance ID (IID). However, there it seemed that both are accessible together under the IID 0x00, maybe that's changed here and we'll need to go by different IIDs. CC @archseer.

Can you try again (with debug output) and change the IIDs here and here from 0x00 to 0x01, and then try again with 0x02? IIRC 0x01 should be trackpad and 0x02 keyboard, but I might be wrong there.

[NickyTope]

with id changed to both of those values, keyboard click does not register anything but trackpad click does. the 0x01 value however shows the keyboard being recognised as below.. 0x01-load.txt 0x01-tpclick.txt 0x02-load.txt 0x02-tpclick.txt

[qzed]

Okay, so IID 0x01 seems to be the keyboard then. That at least provides us with a valid descriptor for the keyboard. Small steps... What about IID 0x03 or 0x04?

I'm not quite sure why the keyboard events don't get sent by the EC, although I have another idea that you could test (with IID 0x01): Try changing the 0x01 in this line to 0x02. (That's currently an unknown parameter. I suspect that this could be the priority value, which for keyboard/trackpad events is 0x02).

[qzed]

Ah, didn't look at the 0x01-tpclick log before I wrote this. Actually it looks like keyboard input events are coming through (or at least something is), just with a different target category (TC). With IID 0x01, try changing this line to

if (event->cid == 0x00 || event->cid == 0x03 || event->cid == 0x04)

(basically ignoring the TC value for now).

[qzed]

Okay, not sure if those are the keyboard events. They look significantly different than on the SL1, and it doesn't quite look like HID data to me.

[qzed]

Ah, I think I've misunderstood you, sorry, you're tapping the touchpad both times, right? They look exactly like the touchpad stuff, just with a different IID. So we still just get touchpad stuff.

[NickyTope]

yes, those were just with touchpad click. will update line 334 now and report back

[qzed]

Changing line 334 will only help for the unsupported event messages. So given that those are the same messages we got before just with a different TC, that shouldn't make any difference. We need to figure out two things right now:

1. How to get the touchpad HID descriptor. Hopefully that will get the touchpad to work. Likely that's just a different IID.
2. How to enable keyboard events. Hopefully that's working with the change in line 379.

If that doesn't pan out, you might need go dig around a bit on windows (https://github.com/linux-surface/surface-aggregator-module#getting-windows-logs-for-reverse-engineering). I need to catch some sleep now but I'll have a look at this again tomorrow.

[NickyTope]

ok, hopefully more progress but still no input actually registering..

looks like the touchpad iid is at 0x03: 0x03-load.txt

here is the module load with 0x04 id set: 0x04-load.txt

this is probably the same but here is the load with id 0x01 and lines 379/334 changed as above: 0x01-load-379+334.txt

In all 3 of the cases above pressing keys on the keyboard did not generate extra output in dmesg.

I'll read and provide the logs from windows shortly

[archseer]

Here's something that I noticed, the descriptor in the first log is really short:

0x01-load-379+334.txt

[ 5168.160076] hid (null): HID descriptor of device:
[ 5168.160077] descriptor:00000000: 05 01 09 06 a1 01 85 01 15 00 25 01 75 01 95 08
[ 5168.160078] descriptor:00000010: 05 07 19 e0 29 e7 81 02 75 08 95 0a 19 00 29 91
[ 5168.160079] descriptor:00000020: 26 ff 00 81 00 05 0c 0a c0 02 a1 02 1a c1 02 2a
[ 5168.160080] descriptor:00000030: c6 02 95 06 b1 03 c0 05 08 19 01 29 03 75 01 95
[ 5168.160081] descriptor:00000040: 03 25 01 91 02 95 05 91 01 c0 05 01 09 80 a1 01
[ 5168.160081] descriptor:00000050: 85 5b 15 00 25 01 75 01 95 03 09 97 09 98 09 99
[ 5168.160082] descriptor:00000060: 81 02 95 05 81 01 c0 05 0c 09 01 a1 01 85 03 95
[ 5168.160083] descriptor:00000070: 01 75 10 15 00 26 ff 03 19 00 2a ff 03 81 00 c0

0x03 has a longer one:

[ 4670.311370] hid (null): HID descriptor of device:
[ 4670.311370] descriptor:00000000: 05 01 09 02 a1 01 85 02 09 01 a1 00 05 09 19 01
[ 4670.311371] descriptor:00000010: 29 02 15 00 25 01 75 01 95 02 81 02 95 06 81 03
[ 4670.311371] descriptor:00000020: 05 01 09 30 09 31 15 81 25 7f 75 08 95 02 81 06
[ 4670.311372] descriptor:00000030: c0 c0 05 0d 09 05 a1 01 85 04 05 0d 09 22 a1 02
[ 4670.311372] descriptor:00000040: 15 00 25 01 09 47 09 42 95 02 75 01 81 02 95 01
[ 4670.311372] descriptor:00000050: 75 03 25 05 09 51 81 02 75 01 95 03 81 03 05 01
[ 4670.311373] descriptor:00000060: 15 00 26 e4 07 75 10 55 0e 65 11 09 30 35 00 46
[ 4670.311373] descriptor:00000070: f2 03 95 01 81 02 46 94 02 26 29 05 09 31 81 02
[ 4670.311373] descriptor:00000080: 45 00 55 00 65 00 c0 05 0d 09 22 a1 02 15 00 25
[ 4670.311374] descriptor:00000090: 01 09 47 09 42 95 02 75 01 81 02 95 01 75 03 25
[ 4670.311374] descriptor:000000a0: 05 09 51 81 02 75 01 95 03 81 03 05 01 15 00 26
[ 4670.311374] descriptor:000000b0: e4 07 75 10 55 0e 65 11 09 30 35 00 46 f2 03 95
[ 4670.311375] descriptor:000000c0: 01 81 02 46 94 02 26 29 05 09 31 81 02 45 00 55
[ 4670.311375] descriptor:000000d0: 00 65 00 c0 05 0d 09 22 a1 02 15 00 25 01 09 47
[ 4670.311375] descriptor:000000e0: 09 42 95 02 75 01 81 02 95 01 75 03 25 05 09 51
[ 4670.311376] descriptor:000000f0: 81 02 75 01 95 03 81 03 05 01 15 00 26 e4 07 75
[ 4670.311376] descriptor:00000100: 10 55 0e 65 11 09 30 35 00 46 f2 03 95 01 81 02
[ 4670.311376] descriptor:00000110: 46 94 02 26 29 05 09 31 81 02 45 00 55 00 65 00
[ 4670.311377] descriptor:00000120: c0 05 0d 09 22 a1 02 15 00 25 01 09 47 09 42 95
[ 4670.311377] descriptor:00000130: 02 75 01 81 02 95 01 75 03 25 05 09 51 81 02 75
[ 4670.311377] descriptor:00000140: 01 95 03 81 03 05 01 15 00 26 e4 07 75 10 55 0e
[ 4670.311378] descriptor:00000150: 65 11 09 30 35 00 46 f2 03 95 01 81 02 46 94 02
[ 4670.311378] descriptor:00000160: 26 29 05 09 31 81 02 45 00 55 00 65 00 c0 05 0d
[ 4670.311378] descriptor:00000170: 09 22 a1 02 15 00 25 01 09 47 09 42 95 02 75 01
[ 4670.311379] descriptor:00000180: 81 02 95 01 75 03 25 05 09 51 81 02 75 01 95 03
[ 4670.311379] descriptor:00000190: 81 03 05 01 15 00 26 e4 07 75 10 55 0e 65 11 09
[ 4670.311379] descriptor:000001a0: 30 35 00 46 f2 03 95 01 81 02 46 94 02 26 29 05
[ 4670.311380] descriptor:000001b0: 09 31 81 02 45 00 55 00 65 00 c0 05 0d 55 0c 66
[ 4670.311380] descriptor:000001c0: 01 10 47 ff ff 00 00 27 ff ff 00 00 75 10 95 01
[ 4670.311380] descriptor:000001d0: 09 56 81 02 09 54 25 7f 95 01 75 08 81 02 05 09
[ 4670.311381] descriptor:000001e0: 09 01 25 01 75 01 95 01 81 02 95 07 81 03 05 0d
[ 4670.311381] descriptor:000001f0: 85 04 09 55 09 59 75 04 95 02 25 0f b1 02 85 06
[ 4670.311381] descriptor:00000200: 09 60 95 01 15 00 25 01 b1 02 95 07 b1 03 85 05
[ 4670.311382] descriptor:00000210: 06 00 ff 09 c6 15 00 25 08 75 08 95 01 b1 02 09
[ 4670.311382] descriptor:00000220: c7 26 ff 00 75 08 95 20 b1 02 c0 05 0d 09 0e a1
[ 4670.311382] descriptor:00000230: 01 85 07 09 22 a1 02 09 52 15 00 25 0a 75 08 95
[ 4670.311383] descriptor:00000240: 01 b1 02 c0 09 22 a1 00 85 08 09 57 09 58 75 01
[ 4670.311383] descriptor:00000250: 95 02 25 01 b1 02 95 06 b1 03 c0 c0 06 07 ff 09
[ 4670.311383] descriptor:00000260: 01 a1 01 85 0a 09 02 26 ff 00 75 08 95 14 91 02
[ 4670.311384] descriptor:00000270: 85 09 09 03 91 02 85 0a 09 04 95 26 81 02 85 09
[ 4670.311384] descriptor:00000280: 09 05 81 02 85 09 09 06 95 01 b1 02 85 0b 09 07
[ 4670.311384] descriptor:00000290: b1 02 c0 06 05 ff 09 04 a1 01 85 0e 09 31 91 02
[ 4670.311385] descriptor:000002a0: 09 31 81 03 09 30 91 02 09 30 81 02 95 39 09 32
[ 4670.311385] descriptor:000002b0: 92 02 01 09 32 82 02 01 c0

and there is none reported under 0x04. We currently only fetch the 0x00 descriptor: https://github.com/linux-surface/surface-aggregator-module/blob/03b784e8ec9f29b1756661018f8f54c7b6ea256a/module/surface_sam_sid_vhf.c#L211

I wonder why the descriptor returned varied. I think in the 0x01 case it might have only received partial data because I see another big recv: block afterwards. I'll go and dump the descriptor into C code/comments later so we can compare the data.

[NickyTope]

ok, I'm not really sure what the contents of these will be like but here are 2 outputs from IRPMon one where I started it and just pressed 2 buttons on the keyboard and one where I detached and reattached the screen. keypresstest.log detachattach.log

[qzed]

Here are the two descriptors, converted to C code with comments:

• descriptor-0x01.c.txt
• descriptor-0x03.c.txt

They do look like complete descriptors to me. 0x01 for the keyboard, 0x03 for the trackpad. Unlike on the SL3 they are not combined, so we should probably create separate input devices for them.

[qzed]

@NickyTope Thanks, those logs are definitely what we need! I'll dig into them more later, but it looks like there might also be something on IID = 0x05 and IID = 0x06 (in total, I see stuff going on for IIDs 1, 3, 5, and 6). Can you check that?

Here's what seems like a metadata request on IID 0x05 (has a response later in the log):

{"ctrl":{"type":128,"len":18,"pad":0,"seq":69},"cmd":{"type":128,"tc":21,"outgoing":2,"incoming":0,"iid":5,"rqid_lo":105,"rqid_hi":1,"cid":4},"payload":[0,0,0,0,0,118,0,0,0,0]}

[archseer]

If you have the time, here's also a way to dump all the HID descriptors on Windows but it's a bit more involved: https://github.com/linux-surface/surface-aggregator-module/issues/8#issuecomment-565800865

[archseer]

Would be super nice to get the touchscreen ones dumped so we can compare it to SL3

[qzed]

It kind of looks like they have a new event registration system (TC = 0x21)... Would explain why we don't get any events. Can you change this line to

data = bytes([0x21, 0x01, 0x00, 0x02, 0x01, 0x05, 0x15, 0x00, 0x15, 0x00, 0x01])

and run this script (requires root) with the driver loaded (and IID = 0x01)? I think that should enable keyboard events. If that works,

data = bytes([0x21, 0x01, 0x00, 0x02, 0x01, 0x05, 0x15, 0x00, 0x15, 0x00, 0x03])

should enable trackpad events (with driver loaded and IID = 0x03).

A bit more context on that: Looks like TC=0x21 might a new event/registration system, which also allows to filter by IID. CID=0x01 could be "enable event", CID=0x02 could be "disable event". TC=0x33 seems to have some events itself and could need to be enabled before we enable the other events:

{"ctrl":{"type":128,"len":13,"pad":0,"seq":22},"cmd":{"type":128,"tc":33,"outgoing":0,"incoming":2,"iid":0,"rqid_lo":33,"rqid_hi":0,"cid":3},"payload":[1,0,2,3,1]}
{"ctrl":{"type":128,"len":13,"pad":0,"seq":23},"cmd":{"type":128,"tc":33,"outgoing":0,"incoming":2,"iid":0,"rqid_lo":33,"rqid_hi":0,"cid":3},"payload":[1,0,2,21,5]}
{"ctrl":{"type":128,"len":13,"pad":0,"seq":24},"cmd":{"type":128,"tc":33,"outgoing":0,"incoming":2,"iid":0,"rqid_lo":33,"rqid_hi":0,"cid":3},"payload":[1,0,2,2,1]}
{"ctrl":{"type":128,"len":13,"pad":0,"seq":25},"cmd":{"type":128,"tc":33,"outgoing":0,"incoming":2,"iid":0,"rqid_lo":33,"rqid_hi":0,"cid":3},"payload":[1,0,2,21,6]}
{"ctrl":{"type":128,"len":13,"pad":0,"seq":26},"cmd":{"type":128,"tc":33,"outgoing":0,"incoming":2,"iid":0,"rqid_lo":33,"rqid_hi":0,"cid":3},"payload":[1,0,2,21,3]}
{"ctrl":{"type":128,"len":13,"pad":0,"seq":27},"cmd":{"type":128,"tc":33,"outgoing":0,"incoming":2,"iid":0,"rqid_lo":33,"rqid_hi":0,"cid":3},"payload":[1,0,2,33,0]}
{"ctrl":{"type":128,"len":13,"pad":0,"seq":28},"cmd":{"type":128,"tc":33,"outgoing":0,"incoming":2,"iid":0,"rqid_lo":33,"rqid_hi":0,"cid":3},"payload":[1,0,2,21,1]}

The payload of those events kind of looks like a list of enabled events (TC + IID):

[..., 0x03, 0x01],
[..., 0x15, 0x05],
[..., 0x02, 0x01],
[..., 0x15, 0x06],
[..., 0x21, 0x00],
[..., 0x15, 0x01],

The payload of CID=0x01/CID=0x02 commands seems to be [tc, seqtype, rqid_low, rqid_high, iid]. This kind of makes me think that on the old event system the unknown parameter may be seqtype (0x01 if the packet containing the event is sequenced, 0x00 if not).

[NickyTope]

Have been stepping through the changes and commands above and found a combination of these changes that made the keyboard start working, with id 0x01 and the change in line 379 here is the diff that showed working keyboard: kb-working.diff.txt

Here are module loads with ids 0x05 and 0x06: 0x05-load.txt 0x06-load.txt

I have not yet updated and run the script above or looked at getting the hid descriptors from windows, I need to go do some shopping but will continue looking into this when I'm back home.

[NickyTope]

was just about to walk out the door but thought to myself.. will the trackpad just work now also with that id set to 0x03.. and indeed it does!!!

not sure if i didnt unload/load properly when testing these before but I'm stoked for the progress..

do you still want me to update and run the py script?

[NickyTope]

Another thing I noticed is that the touch screen works but the registration is way off, it registers a touch far to the right of where you actually touched.

I also have the surface pen and could connect it over bluetooth but nothing registers.

[archseer]

The touchscreen is a whole different can of worms, I think SL3 had similar issues that were fixed after @StollD adjusted some values. I don't expect multi-touch to work there at all until we figure out the new touch protocol (it's also broken on SL3).

Would you mind marking off whatever works out of the box with checkmarks here? https://github.com/linux-surface/linux-surface/wiki/Supported-Devices-and-Features

We'll mark the ones that require the ACPI modules after that's merged to master.

[qzed]

Awesome! Glad that you've got it to work.

not sure if i didnt unload/load properly when testing these before but I'm stoked for the progress..

One thing that could cause some trouble is could be Windows not disabling events on shutdown. IIRC it did happen at some point that Windows enabled some events and they were still enabled when booting into Linux afterwards. To make absolutely sure that your changes work, can you try to do a two-button-reset (press and hold power and volume up, i.e. the volume button directly next to power, until the device reboots) and try again (directly booting into Linux)? If that works we're set.

After that I'd still like to figure out what those TC=0x21 calls are... I'll update the script tomorrow to make it a bit easier for you to play around with. I still think that they have something to do with events, the payload data just fits too well for this to be a coincidence.

I've also converted the 0x05 and 0x06 descriptors:

• descriptor-0x05.c.txt
• descriptor-0x06.c.txt

This doesn't really look like any normal input device to me. Might be that this is related to firmware updates for the keyboard controller.

[NickyTope]

Added initially supported features to that document, the "tablet mode" seems to work (the touchscreen was still responding but off centre) however docking it again totally locked up the system. Also the nvidia-settings says it is using prime mode and allows me to switch (requiring a restart) does that count as "dedicated gpu support"?

@qzed you may be right about windows enabling the events, after using the 2 button reset and inserting the module again the events no longer work. I'll boot into windows to confirm after this post..

I updated the py script as suggested however it fails as below:

sudo ./sysfs_rqst.py 
Traceback (most recent call last):
  File "./sysfs_rqst.py", line 36, in <module>
    main()
  File "./sysfs_rqst.py", line 19, in main
    fd = os.open(PATH_DEV_RQST, os.O_RDWR | os.O_SYNC)
FileNotFoundError: [Errno 2] No such file or directory: '/sys/bus/serial/devices/serial0-0/rqst'

heres the contents of that serial0-0 dir

ls /sys/bus/serial/devices/serial0-0/
firmware_node  modalias  power  subsystem  uevent

I looked for any other serial devices but, there is only serial0 and serial0-0 present.

[archseer]

I feel like I've seen 0x21 calls before in my logs too. I'll have to check my irpmon gists

[archseer]

0x05, 0x06: I think those are the firmware update descriptors, a version of it is in all descriptors we've seen so far. Should be safe to ignore

[archseer]

https://docs.microsoft.com/en-us/windows-hardware/design/component-guidelines/windows-precision-touchpad-required-hid-top-level-collections#firmware-update-collection-optional

[NickyTope]

I did a dkms-install on the module with iid 0x01 and then tried rebooting to windows and back, tried the 2 button reboot also, it seems that the keyboard now works regardless of the boot, I logged in before posting this with the built in keyboard!

I haven't mentioned it yet, but there's a big pause before the grub menu is responsive, like 5-10 seconds

[StollD]

Another thing I noticed is that the touch screen works but the registration is way off, it registers a touch far to the right of where you actually touched.

I also have the surface pen and could connect it over bluetooth but nothing registers.

@NickyTope Could you try to enable debug output for the touchscreen driver? This sounds like something changed in the messages that are received from the hardware.

$ sudo modprobe -r ipts
$ sudo modprobe ipts debug

After that the incoming data will be logged to dmesg, so please generate some data by touching the screen, and upload the log here.

[NickyTope]

Here is the dmesg output for ipts debug with a single touch event: ipts-debug.txt

Also saw this output just after the above..

[62118.855627] surface_sam: power event (cid = 0x53)
[62118.855629] surface_sam: unhandled power event (cid = 0x53)

[qzed]

@NickyTope

I updated the py script as suggested however it fails as below:

Did you have the module loaded when you ran this? I haven't gotten around to update the script yet as I have a bit of other stuff to do, but I plan to do that soon.

Added initially supported features to that document, the "tablet mode" seems to work (the touchscreen was still responding but off centre) however docking it again totally locked up the system.

I kind of suspect this may have something to do with the DE or nvidia driver crashing when the dGPU is re-attached. It's also likely you'll see freezes/crashes if the DE tries to somehow use dGPU and you're detaching the tablet (that's one of the main reasons I disabled it on the SB2 by default).

Unfortunately it looks like that whole system may have changed a bit, so might be tricky for me to properly implement dGPU on/off setting without having a device. Doing that (reliably) for the SB2 was a lot of trial and error.

I did a dkms-install on the module with iid 0x01 and then tried rebooting to windows and back, tried the 2 button reboot also, it seems that the keyboard now works regardless of the boot, I logged in before posting this with the built in keyboard!

Neat! So hopefully that all works. I kinda wonder what the other thing is for then. Let me know in case it stops working at some point. I'll try to properly implement this in the driver tomorrow (or monday latest).

I haven't mentioned it yet, but there's a big pause before the grub menu is responsive, like 5-10 seconds

I think that's also a problem on the SL3 and SP7 (see https://github.com/linux-surface/linux-surface/issues/108). I'm currently not using grub, so I can't really say anything about it.

@archseer

0x05, 0x06: I think those are the firmware update descriptors, a version of it is in all descriptors we've seen so far. Should be safe to ignore

Should also be no problem to add them if we do a device/instance per IID. I think we can implement this pretty similar to the "new" battery driver, so that would be a difference of two lines in the SID MFD cell.

Can you also try if the events still get enabled for you on the SL3 with the event registration change:

Try changing the 0x01 in this line to 0x02. (That's currently an unknown parameter. I suspect that this could be the priority value, which for keyboard/trackpad events is 0x02).

[NickyTope]

Here is a gist with all of the Windows Driver Kit Debugger output as requested @archseer https://gist.github.com/NickyTope/7545facc9d6657632f49c7ee437d3338 let me know if any more details are required

[NickyTope]

Did you have the module loaded when you ran this? I haven't gotten around to update the script yet as I have a bit of other stuff to do, but I plan to do that soon.

Just reran the script with my current state (module dkms installed with iid 0x01) and you are right it does now run, and outputs 00. there was no extra output in dmesg although I do have debugging turned off, let me know if you want more info on this!

[qzed]

Running it with debug output would be nice, but I'm still planning to update the script. I want to see how this (and other commands, thus the script update) interact with the events (i.e. if they're going to stop via some command, stuff like that). I'll notify you once I've done that (I'm currently a bit busy with some other things, but I'll hopefully get to it tomorrow).

Thanks for testing btw.!

[NickyTope]

Thanks for testing btw.!

My pleasure, you guys rock!! Thanks for all the support and work on this so far!

Running it with debug output would be nice

here is the output in dmesg when the script is run:

[ 1228.348283] surface_sam_ssh serial0-0: sending message
[ 1228.348285] send: 00000000: aa 55 80 0d 00 16 5e 69 80 21 02 00 00 c0 02 01
[ 1228.348285] send: 00000010: 15 00 15 00 01 67 e1
[ 1228.349947] surface_sam_ssh serial0-0: recv: received buffer (size: 10)
[ 1228.349948] recv: 00000000: aa 55 40 00 00 16 ab 98 ff ff
[ 1228.349949] surface_sam_ssh serial0-0: recv: valid control message received (type: 0x40)
[ 1228.351316] surface_sam_ssh serial0-0: recv: received buffer (size: 19)
[ 1228.351330] recv: 00000000: aa 55 80 09 00 c9 0c 8f 80 21 00 02 00 c0 02 01
[ 1228.351331] recv: 00000010: 00 ce fe
[ 1228.351332] surface_sam_ssh serial0-0: recv: valid command message received
[ 1228.351385] surface_sam_ssh serial0-0: sending message
[ 1228.351386] send: 00000000: aa 55 40 00 00 c9 39 a2 ff ff

I think that's also a problem on the SL3 and SP7 (see #108). I'm currently not using grub, so I can't really say anything about it.

Ok, I see that using other bootloaders is notes as a fix, my previous work laptop was running arch/bspwm and refind. not sure yet what I will actually run on this (maybe sway?) currently using xubuntu just for the speed of the initial setup (hence having grub installed)

[qzed]

Okay, I encountered a minor hick-up along the way: The current master state doesn't support multiple event handlers yet. We need that if we want to handle each HID device separately. That's currently only implemented on the cleanup branch. But on the cleanup branch there is no rqst sysfs device for testing (I removed it because I wanted to re-implement it in a better way, but that's currently blocked by some other missing stuff).

I've pushed an update to the feature/sb3 branch (which is currently based on master) to enable keyboard only for now and also added a sb3_test.py script. Can you test that the keyboard works with this update? If it does, can you play around a bit with the script? Here's what I'm trying to figure out:

1. Run ./scripts/sb3_test.py setup. This should be the set up command.
2. Run ./scripts/sb3_test.py enable.
3. Run ./scripts/sb3_test.py disable.
4. Run ./scripts/sb3_test.py teardown.

Between each command, try to type something and see if the events are still enabled (also preferably build the module with debug enabled and log everything while you're doing this). I suspect that 3 or 2 might disable the events. If one of those does, try running the other one and see if that enables them again (basically enable+disable and setup+teardown should be pairs).

If the keyboard works with the changes I've made, I'll try to find a good commit from the cleanup branch to base this on (that already supports multiple event handlers per TC), that should allow us to handle the trackpad, too. Might also be possible to temporarily re-add the sysfs device if necessary, I'll have to look into that.

[qzed]

@archseer Can you also test the feature/sb3 branch and check that the changes didn't break anything for the SL3?

[qzed]

Okay, I've added support for both the rqst device and the keyboard and trackpad (simultaneously) on the feature/sb3-v2 branch. So you should be able to test everything on that branch.

There is a significant difference to the master-based version though: In the cleanup branch, I've splitted the external module into multiple modules (just like the in-kernel version). These modules have the same name as the in-kernel versions. I've also added a script to simplify loading/unloading of those modules (documented here, but I put the basics below).

Running ../scripts/ssam-modprobe -r unloads the in-kernel modules, running ../scripts/ssam-modprobe insmod inserts the .ko modules inside the current directory (so you should run it from the module directory), running ../scripts/ssam-modprobe rmmod unloads the .ko modules and ../scripts/ssam-modprobe inserts the in-kernel (or dkms-installed) modules again.

If you plan on installing this via dkms, make sure that you first run make dkms-uninstall with the old version checked out.

[qzed]

If that works out, I think we can also merge this into the master as the readme for that is now updated.

[NickyTope]

sorry haven't had much time to try this today. I did try to load the modules but something was not working, will test more and try to provide as much info as i can.

There doesn't seem to be the same debug flag in the Makefile, do I just add it the same as before?

My system crashed at some point and then refused to accept these events again, possibly until i loaded windows and then rebooted, will try to replicate this also.

[qzed]

There doesn't seem to be the same debug flag in the Makefile, do I just add it the same as before?

Yes (Edit: Although not in the Makefile but in the Kbuild file this time)

I did try to load the modules but something was not working, will test more and try to provide as much info as i can.

I just noticed that I forgot to change the event enable command parameter (the change from 0x01 to 0x02)... That's a bit more hidden in the API now. I'll change that and let you know when I have a new version to test ready.

[qzed]

Okay, I've updated the code