On Thu, Aug 12, 2021 at 7:16 PM Felipe Balbi <balbi@xxxxxxxxxx> wrote: > > > Hi Benjamin, > > Benjamin Tissoires <benjamin.tissoires@xxxxxxxxxx> writes: > > Hi Dmitry, > > > > On Thu, Aug 12, 2021 at 2:13 AM Dmitry Antipov <daantipov@xxxxxxxxx> wrote: > >> > >> Surface Duo uses a touch digitizer that communicates to the main SoC via SPI > >> and presents itself as a HID device. This patch contains the changes needed > >> for the driver to work as a module: HID Core affordances for SPI devices, > >> addition of the new Device IDs, and a new quirk in hid-microsoft. The driver > >> itself is being prepared for a submission in the near future. > >> > >> Signed-off-by: Dmitry Antipov dmanti@xxxxxxxxxxxxx > > > > Though I really appreciate seeing a microsoft.com submission, the > > commit description makes me wonder if we should not postpone the > > inclusion of this patch with the "submission in the near future". > > > > AFAIK, HID is not SPI aware. So basically, we are introducing dead > > code in the upstream kernel if we take this patch. > > Right, unfortunately spec isn't public yet (albeit having products > shipped using it and a driver available in a public tree somewhere I > couldn't find). > > I _do_ have one question though: > > Is there a way to tell hid core that $this device wants hidraw? If we Depending on what you want and can do I can think of several solutions: - add a quirk for this device (either at boot time, either in hid-quirks.c) There must be one that tells to only bind to hidraw - provide an out of the tree driver that declares the BUS:VID:PID, and start the HID device with HIDRAW only. > remove the hid-microsoft changes, hid-generic will pick the device as > expected, but this really needs hidraw. Any hints? I am fine with the hid-microsoft changes, I just want them in a separate commit. But I don't see why we would take only the first one without the SPI transport and the hid-microsoft code... Basically: not sure why you need hidraw for it. Cheers, Benjamin >
