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 [email protected] 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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
