Ta - just noticed I mailed from wrong address so original post did not go
to mailing list.
1. the unbind/bind was actually the first thing I tried (should have
mentioned that) before resorting to removing hid-generic. This worked fine
for me in the past when I had loaded my own precursor to the current
hid-spinelplus remote. However when I tried it with the latest code it
simply resulted in an unusable remote (nothing worked) it didn't even work
when I remapped back to hid-generic. So something is broken there?
Was this some kernel between 3.7-rc1 and 3.7-rc5? There was a bug in
rebinding drivers to devices which got fixed by commit df0cfd69903 in
Linus' tree.
The driver looks fine, but as it contains solely usage -> keycode mapping,
it should be possible to do it completely in userspace. There are already
a lot of udev rules for this you can use for inspiration -- in recent udev
releases they are located in /lib/udev/rules.d/keymaps, and are handled by
master /lib/udev/rules.d/*keymap* rule.
Hope this helps,
--
Jiri Kosina
SUSE Labs
From: Adam Sutton <hidden> Date: 2012-11-16 16:24:28
On 16 November 2012 15:39, Jiri Kosina [off-list ref] wrote:
On Fri, 16 Nov 2012, Adam Sutton wrote:
quoted
Ta - just noticed I mailed from wrong address so original post did not go
to mailing list.
1. the unbind/bind was actually the first thing I tried (should have
mentioned that) before resorting to removing hid-generic. This worked fine
for me in the past when I had loaded my own precursor to the current
hid-spinelplus remote. However when I tried it with the latest code it
simply resulted in an unusable remote (nothing worked) it didn't even work
when I remapped back to hid-generic. So something is broken there?
Was this some kernel between 3.7-rc1 and 3.7-rc5? There was a bug in
rebinding drivers to devices which got fixed by commit df0cfd69903 in
Linus' tree.
No we're a bit behind the curve, I think we're using a 3.6 based
kernel. I didn't really investigate the problem, simply noted that it
didn't work (as it had before) and moved on to try and figure out
another way to make it work.
The driver looks fine, but as it contains solely usage -> keycode mapping,
it should be possible to do it completely in userspace. There are already
a lot of udev rules for this you can use for inspiration -- in recent udev
releases they are located in /lib/udev/rules.d/keymaps, and are handled by
master /lib/udev/rules.d/*keymap* rule.
I'll take a look at that. I can see there are plenty of other drivers
though in the mainline that do the same thing we're doing with the
spinelplus. Are these simply relics of and older approach (before udev
updates?) or is there a benefit to doing this in the kernel?
Either way would you still be happy to accept the patch? And if so
what exactly is the process for submitting, I've had a quick read
on-line. Do I simply need to generate a git patch and post to the
mailing list?
Ta
Adam
The driver looks fine, but as it contains solely usage -> keycode mapping,
it should be possible to do it completely in userspace. There are already
a lot of udev rules for this you can use for inspiration -- in recent udev
releases they are located in /lib/udev/rules.d/keymaps, and are handled by
master /lib/udev/rules.d/*keymap* rule.
I'll take a look at that. I can see there are plenty of other drivers
though in the mainline that do the same thing we're doing with the
spinelplus. Are these simply relics of and older approach (before udev
updates?) or is there a benefit to doing this in the kernel?
Exactly as you mention, it's a relic from the times when you were not able
to change HID usages by 'setkeycodes', so the in-kernel driver changing
the mapping was the only option.
Now there are much more mappings being done from userspace instead of the
kernel, but we can't really remove the ones which are already in-kernel,
as that might cause regressions for people with old udev whould would
update to latest kernel.
Either way would you still be happy to accept the patch? And if so
what exactly is the process for submitting, I've had a quick read
on-line. Do I simply need to generate a git patch and post to the
mailing list?
Yes, that is the usual process.
But for these kinds of drivers, I'd really suggest you actually convert it
to a udev rule and submit it as a patch to udev maintainers instead.
Does that work for you?
Thanks,
--
Jiri Kosina
SUSE Labs
The driver looks fine, but as it contains solely usage -> keycode mapping,
it should be possible to do it completely in userspace. There are already
a lot of udev rules for this you can use for inspiration -- in recent udev
releases they are located in /lib/udev/rules.d/keymaps, and are handled by
master /lib/udev/rules.d/*keymap* rule.
I'll take a look at that. I can see there are plenty of other drivers
though in the mainline that do the same thing we're doing with the
spinelplus. Are these simply relics of and older approach (before udev
updates?) or is there a benefit to doing this in the kernel?
Exactly as you mention, it's a relic from the times when you were not able
to change HID usages by 'setkeycodes', so the in-kernel driver changing
the mapping was the only option.
Now there are much more mappings being done from userspace instead of the
kernel, but we can't really remove the ones which are already in-kernel,
as that might cause regressions for people with old udev whould would
update to latest kernel.
Thanks for the clarification.
quoted
Either way would you still be happy to accept the patch? And if so
what exactly is the process for submitting, I've had a quick read
on-line. Do I simply need to generate a git patch and post to the
mailing list?
Yes, that is the usual process.
But for these kinds of drivers, I'd really suggest you actually convert it
to a udev rule and submit it as a patch to udev maintainers instead.
Does that work for you?
Yes I think it does. Short term I've simply fixed the patch to mod
hid-core.c as you suggested, that will solve the immediate problem.
I'll talk to Stephen about the fact he might want to consider
investigating use of udev keymap rules. I had a quick look on my
laptop and they looked simply enough to do.
Thanks for all the help,
Adam