"soft" USB keyboard and mouse driver
Hi I would need a hint what is best to do; I have an embedded device that can do a "soft" implementation of USB for embedded applications. The aim is to be compatible with low-speed HID USB devices.
The fact is, it does not implement a full USB stack but only point-to-point communication with the aforementioned devices. I know it sounds weird but it's more like a "PS/2" port than a USB thing.
Now, I have a generic character device driver that can read keyboard and mouse data. Of course I get what a USB device would send when you press keys etc.
How do you think it would be the best way to integrate it with the input subsystem?
Any idea would be appreciated.
Thank you!
Alessio
Quoted 8 lines · Alessio Sangalli
Hi I would need a hint what is best to do; I have an embedded device that can do a "soft" implementation of USB for embedded applications. The aim is to be compatible with low-speed HID USB devices.
The fact is, it does not implement a full USB stack but only point-to-point communication with the aforementioned devices. I know it sounds weird but it's more like a "PS/2" port than a USB thing.
Quoted 6 lines
Now, I have a generic character device driver that can read keyboard and mouse data. Of course I get what a USB device would send when you press keys etc.
How do you think it would be the best way to integrate it with the input subsystem?
I am not really sure I understand very well. So you have the device the provides some "crippled" implementation of USB and provides some HID devices on top of it, and you would like to have this compliant with the kernel Input/HID infrastructure?
If the devices are really HID (i.e. the protocol on the wire is proper HID as defined by HID specification), you'd only need to implement a specialized "transport" HID code for this transport protocol, and let the HID core do the rest.
Currently there are implementations for USB and Bluetooth which you can look at.
Or maybe I just misunderstood your situation completely?
Signature · 2 lines
Jiri Kosina SUSE Labs
Quoted 4 lines · Jiri Kosina
I am not really sure I understand very well. So you have the device the provides some "crippled" implementation of USB and provides some HID devices on top of it, and you would like to have this compliant with the kernel Input/HID infrastructure?
Yeah we can define it that way. It basically provides a low-speed USB port to chips that do not have a USB controller and PHY. Yes, it sounds disgusting, but sometimes it's the only way to use USB input devices to embedded systems that do not have USB connectivity.
Quoted 4 lines
If the devices are really HID (i.e. the protocol on the wire is proper HID as defined by HID specification), you'd only need to implement a specialized "transport" HID code for this transport protocol, and let the HID core do the rest.
Well those are standard USB keyboard and mice, so what goes on the wire is what is expected by those devices.
Quoted 2 lines
Currently there are implementations for USB and Bluetooth which you can look at.
Could you point me to a more specific example?
Thank you
Alessio
Quoted 3 lines · Alessio Sangalli
Quoted 2 lines
Currently there are implementations for USB and Bluetooth which you can look at.
Could you point me to a more specific example?
There is a generic HID layer, which implements the HID specification (parsin of report descriptor, passing and interpretation of reports, interaction with input subsystem, etc), independently on the underlying physical protocol being used, in drivers/hid/hid-core.c and drivers/hid/hid-input.c
Then, there are the transport-dependent parts of the implementation. For USB this is in driver/hid/usbhid/hid-core.c, which contains all the USB-specific protocol handling and interaction with HID core.
For Bluetooth, this is in net/bluetooth/hidp/core.c.
Signature · 2 lines
Jiri Kosina SUSE Labs
Quoted 2 lines · Jiri Kosina
There is a generic HID layer, which implements the HID specification (parsin of report descriptor, passing and interpretation of reports,
Thank you. I will have a look.
bye
Alessio