Hi,
Just figured out the solution to my own problem.
Turns out the linux input system will only report a key event if the
value is different from the previous key report. In my case, I was only
sending the value '1'.
Duh. I should have known that.
On 09/11/14 10:57, Jose Diez wrote:
Hello linux-input,
Sorry to post about a similar question again, but I'm still stuck. So a
bit of back story: I'm writing a custom HID driver which, among other
things, will register several input devices.
I'm able to read HID reports from the device using the raw_event
callback, and I'm able to communicate with the device, but I seem to
have hit an obstacle I can't get over. I've tried to add a proper input
device to the driver, and while it registers it properly and shows up in
/dev/input/*, the events seem to not go through.
I found this simple kernel module, which indeed works properly and
reports key events: http://sprunge.us/NLcD
I then adapted it to work with my kernel module, shown here:
http://sprunge.us/egIi
It allocates the input device in fblng_probe(), sets the KEY_A bit in
the keybit field, and registers it. Then, when a request comes to the
device, in fblng_event(), I (try to) send a key with input_report_key.
This doesn't seem to trigger a keypress.
I'm looking at the relevant /dev/input/eventX with `evtest`. I know I'm
getting events through, because I can see it in `dmesg`. However, it
doesn't actually go through to the input handler.
Any help, please?
Thanks a lot,
Jose
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
