Vendor id and product id unset #64
Comments
|
it should, but at least (and for now) it'd make sense to hardcode the apple vendor ID in there somewhere. Makes it pick up on a couple of behaviours. |
|
Yes, the driver absolutely should put the proper ID's there, but so far we don't have them. I know of a single "info" query (from SPI traces) that possibly has that info in it, but I have no clue (yet) where inside that response the vendor and product ID lie. As to hardcoding some ID, the question is, which ID and why? PCI? USB? Other? And why an Apple ID, since I think the keyboard and touchpad are made by Synaptics? And what happens if/when we finally manage to get the actual vendor id from SPI - do we switch to that and break existing stuff, or are we now stuck with a wrong id forever? (my guess is most likely the latter, since Linus is pretty adamant about kernel changes not breaking userspace) All in all, I'm not yet convinced that putting some other ID in there is a good idea. Also, notice that most devices in |
|
Well, that number is skewed, e.g. I have 7 "HDA Intel" devices for PCH and HDMI as well as the lid, sleep, power platform devices. Of the ones that are actual input devices (mice, keyboard, touchpads) only the keyboard has a garbage vendor ID because it's on the serial bus. |
|
@roadrunner2 Do you know how to trigger such an info query and can you please also share what you get as response there? I already looked into the debug output of |
|
@Dunedan Sorry for the delay. I had that info query in my local stuff only, but I've now pushed it to my clone of this repo - if you build and load the |
|
Here is the output of a MacBookPro13,2 with German keyboard layout. They differ, but the difference is pretty small: |
|
So the difference is really just 2 bytes (the other 2 bytes difference are the checksum): |
|
Mine seems to be identical to @Dunedan but from a MBP13,1 with Finnish layout. |
|
MacBookPro14,1, UK English keyboard |
|
@christophgysin, @peterychuang: thanks for those. Yes, they're both identical to @Dunedan's output. I presume you both have/need the |
|
@roadrunner2 Indeed, |
|
Yes, I'm also using So I guess we should be able to autodetect |
|
I'd really like to see an info query result from a MacBookPro13,3 or 14,3 with ISO keyboard to be sure it's related to ANSI vs. ISO and not to 13" vs. 15". Also good would be a result from a 13" one with ANSI keyboard, as that'd be another interesting data point. |
|
MacBook Pro14,3 Japanese(JIS) Keyboard |
|
Thanks @turenar, that's actually pretty interesting, as it shows the same values for an ANSI keyboard and a JIS keyboard. Right now it sounds likely to me that the differences in the output let us identify 13" and 15" models, but let's wait for the output of a MacBookPro13,3/14,3 with ISO keyboard to confirm. Oh and the output of a 12" MacBook would be pretty interesting as well. |
|
Macbook 12" US keyboard |
|
Macbook Pro 14,3, US Keyboard: |
|
As there are even more models which support SPI (in addition to USB), the output of any MacBook Air or MacBook Pro released between Mid 2013 and 2015 would be interesting as well. @newperson1746: I don't know how far you are getting a working driver for the MacBook Air, but if you can get the output of the info query it'd be awesome if you could post it here. |
|
Thanks everyone so far! So yes, it looks like there's a touchpad model id in there - that'll certainly be helpful. Regarding getting info from the MBA's: the reading of the response to a sent command is triggered by the receipt of the GPE; so as long as we're not getting those, we won't see the info command response. |
|
Another MacBookPro14,3 with US keyboard here, the output is identical to the one provided by @ClashTheBunny |
|
I've pushed a change to my clone that retrieves the id and 1) uses it to look up the touchpad info, and 2) populates the vendor and product id. If some of you could give it a whirl that would be great (basically it should work as before, and |
|
@roadrunner2 I tried commit cc3a895 from your fork and it doesn't seem to populate the bus, vendor and product id on MacBookPro14,3: |
|
@melentye Thanks for trying this out! Well, something's really odd: the touchpad is still working, but the id's aren't set? Sorry if this is a stupid question, but are you sure you loaded the new driver? (e.g. |
|
@roadrunner2 and just when I thought that I double-checked everything... The issue was with me forgetting to re-generate the initramfs which contains It seems to work now: sorry about the confusion earlier |
|
@melentye Thanks for going back and getting it working! |
|
Works fine for me with Linux 4.18. Vendor id and product id for the touch pad are properly set. The ones for the keyboard are still missing, but that's expected as far as I can see. |
|
Thanks for testing. Yes, don't have a keyboard "info" command yet, so no id's for that (and no automatic iso/non-iso layout determination 😞). |
An info command is now sent to the touchpad during initialization, the result of which contains a model id (or so we think). The model id is then used instead of the dmi info to look up the touchpad dimensions (that information does not appear to be present in the info command results, unfortunately). This makes the lookup more robust for future laptops that use the same touchpads. Additionally, the input device's vendor and product id fields are now filled in, using Synaptics' USB vendor id for the vendor id and the above model id for the product id. The choice of vendor id is based on the fact that that is what is used in the kernel rmi4 driver too (see drivers/input/rmi4/rmi_driver.h). This addresses #64.
An info command is now sent to the touchpad during initialization, the result of which contains a model id (or so we think). The model id is then used instead of the dmi info to look up the touchpad dimensions (that information does not appear to be present in the info command results, unfortunately). This makes the lookup more robust for future laptops that use the same touchpads. Additionally, the input device's vendor and product id fields are now filled in, using Synaptics' USB vendor id for the vendor id and the above model id for the product id. The choice of vendor id is based on the fact that that is what is used in the kernel rmi4 driver too (see drivers/input/rmi4/rmi_driver.h). This addresses #64.
An info command is now sent to the touchpad during initialization, the result of which contains a model id (or so we think). The model id is then used instead of the dmi info to look up the touchpad dimensions (that information does not appear to be present in the info command results, unfortunately). This makes the lookup more robust for future laptops that use the same touchpads. Additionally, the input device's vendor and product id fields are now filled in, using Synaptics' USB vendor id for the vendor id and the above model id for the product id. The choice of vendor id is based on the fact that that is what is used in the kernel rmi4 driver too (see drivers/input/rmi4/rmi_driver.h). This addresses #64.
An info command is now sent to the touchpad during initialization, the result of which contains a model id (or so we think). The model id is then used instead of the dmi info to look up the touchpad dimensions (that information does not appear to be present in the info command results, unfortunately). This makes the lookup more robust for future laptops that use the same touchpads. Additionally, the input device's vendor and product id fields are now filled in, using Synaptics' USB vendor id for the vendor id and the above model id for the product id. The choice of vendor id is based on the fact that that is what is used in the kernel rmi4 driver too (see drivers/input/rmi4/rmi_driver.h). This addresses #64.
As @whot pointed out in Dunedan/mbp-2016-linux#20 (comment), applespi currently doesn't set any vendor id or product id for the keyboard and the touchpad, preventing the automatic enabling of some features for Apple devices.
Here is how it looks in
/proc/bus/input/devicesfor me:While the driver does currently use DMI for detecting the model and setting touchpad sizes accordingly, shouldn't or couldn't the SPI device provide such information itself somehow?
The text was updated successfully, but these errors were encountered: