On Thu, Aug 13, 2009 at 11:34:44AM +0200, David Härdeman wrote:The main problem right now is that getkeycode is practically useless since
you can't blindly guess at a full range of 2^32 different scancodes to get
the complete keymap. Perhaps a index-based getkeycode would make sense...
The drivers that have such sparce keymaps are expected to issue
EV_MSC/MSC_SCAN events to aid userspace in identifying the "scancodes"
that are emitted by the device.
+static struct device_attribute dev_attr_last_scancode = {
+ .attr = {
+ .name = "last_scancode",
+ .mode = 0444,
+ },
+ .show = wbcir_show_last_scancode,
+ .store = NULL,
+
+};
Why is this needed? And if this is needed we have a nice macro
for that.
I hope I've explained it wrt. EV_IR in my other mail. It's for building
keymaps of unknown remotes. And it'll go away once EV_IR is supported so I
don't think there's much point in fiddling with it now?
Because once the driver is in mainline it becomes part of userspace ABI
and has to stay for a looong time.
Thanks for the review. Are you willing to push the driver upstream through
the input tree once I've implemented your suggested fixes?
I'd need to take a look at your EV_IR patyches and see how they will
affect this driver. I do nt want to merge something that will stay one
way for half a release and then will switch to completely new interface.