Hi Dmitry,
Dmitry Torokhov wrote:
That is because by default atkbd uses software-emulated raw mode.
bootk with atkbd.softraw=0 or switch it off after boot through sysfs
attribute to get EV_MSC/MSC_RAW passed through).
Thank you for your advice, but I really don't know, what will be the
secondary effect if it will be switched off.
No, input core should not pass any events device did not claim to support.
I am not sure, but I think the function input_event in
drivers/input/input.c has 2 tasks:
One is to send events to the device (first part: "switch (type){").
The other one is to send the events to the handler (second part:
"list_for_each_entry(handle, &dev->h_list, d_node)").
This is the reason why I had the idea of changing the code as I have
described it before.
With the current implementation, the device sends events to the handler.
But only events, known/claimed by the device are passed through to the
handler. I believe, this should be handled transparently.
What are you trying to do though? Why are you interested in raw atkbd
events? What will your handler do with events from other input devices
that might emit raw events?
I have to connected special Point Of Sales Keyboards. Sometimes they are
sending none standard scan codes, only make codes and no break codes. I
had successfully implemented this in kernel version 2.4 and now I have
to do it in 2.6.
Best regards, Frank
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
