This patch adds the missing keys from input.h to hid-debug.h.
Signed-off-by: Michael Hanselmann <[email protected]>
---
Dmitry: This patch replaces the one I submitted on December 11, 2005.
The old one had only KEY_FN while this one has all keys. If wanted, I
can submit a patch that applies over the old patch.
--- linux-2.6.15-rc7.orig/drivers/usb/input/hid-debug.h 2006-01-01 00:41:15.000000000 +0100
+++ linux-2.6.15-rc7/drivers/usb/input/hid-debug.h 2006-01-03 00:26:17.000000000 +0100
@@ -681,6 +681,21 @@ static char *keys[KEY_MAX + 1] = {
[KEY_SEND] = "Send", [KEY_REPLY] = "Reply",
[KEY_FORWARDMAIL] = "ForwardMail", [KEY_SAVE] = "Save",
[KEY_DOCUMENTS] = "Documents",
+ [KEY_FN] = "Fn", [KEY_FN_ESC] = "Fn+ESC",
+ [KEY_FN_1] = "Fn+1", [KEY_FN_2] = "Fn+2",
+ [KEY_FN_B] = "Fn+B", [KEY_FN_D] = "Fn+D",
+ [KEY_FN_E] = "Fn+E", [KEY_FN_F] = "Fn+F",
+ [KEY_FN_S] = "Fn+S",
+ [KEY_FN_F1] = "Fn+F1", [KEY_FN_F2] = "Fn+F2",
+ [KEY_FN_F3] = "Fn+F3", [KEY_FN_F4] = "Fn+F4",
+ [KEY_FN_F5] = "Fn+F5", [KEY_FN_F6] = "Fn+F6",
+ [KEY_FN_F7] = "Fn+F7", [KEY_FN_F8] = "Fn+F8",
+ [KEY_FN_F9] = "Fn+F9", [KEY_FN_F10] = "Fn+F10",
+ [KEY_FN_F11] = "Fn+F11", [KEY_FN_F12] = "Fn+F12",
+ [KEY_KBDILLUMTOGGLE] = "KbdIlluminationToggle",
+ [KEY_KBDILLUMDOWN] = "KbdIlluminationDown",
+ [KEY_KBDILLUMUP] = "KbdIlluminationUp",
+ [KEY_SWITCHVIDEOMODE] = "SwitchVideoMode",
};
static char *relatives[REL_MAX + 1] = {
On Monday 02 January 2006 18:37, Michael Hanselmann wrote:
> This patch adds the missing keys from input.h to hid-debug.h.
>
> Signed-off-by: Michael Hanselmann <[email protected]>
Thank you Michael, I will add it to my tree. I still ponder your other
patch and whether we should employ something like hooks for HID.
--
Dmitry
On Tue, Jan 03, 2006 at 01:42:31AM -0500, Dmitry Torokhov wrote:
> On Monday 02 January 2006 18:37, Michael Hanselmann wrote:
> > This patch adds the missing keys from input.h to hid-debug.h.
> >
> > Signed-off-by: Michael Hanselmann <[email protected]>
>
> Thank you Michael, I will add it to my tree. I still ponder your other
> patch and whether we should employ something like hooks for HID.
We should split HID in two parts - transport and decoding. This would
help in many places:
Bluetooth would be happy, because it uses the same HID protocol
on top of a different transport layer (completely non-USB).
Wacom and many other blacklisted devices would be happy, because
they could use the USB HID transport - no blacklist would be
needed.
Would allow for /dev/usb/rawhid0 style devices, which would give
access to raw HID reports without any parsing done.
Would allow userspace drivers for broken UPS devices (like APC)
without the need for special handling of their bugs in the kernel.
It seems to me it could be almost its own layer, like serio or gameport.
Windows has an API like that.
I don't have the time to do the split myself, but it shouldn't be too
hard.
It would not be the perfect solution for Apple keyboards, because the
patch is simplifies by doing the processing after parsing the reports,
but still, since it would allow for device-specific parsers, it'd be a
reasonable solution for devices that need more special handling than
just a simple quirk.
--
Vojtech Pavlik
SuSE Labs, SuSE CR
Hello Vojtech
On Tue, Jan 03, 2006 at 08:53:44PM +0100, Vojtech Pavlik wrote:
> We should split HID in two parts - transport and decoding. This would
> help in many places:
> [...]
> I don't have the time to do the split myself, but it shouldn't be too
> hard.
And for myself, I think I'm not enough into kernel development already.
Beside of that, USB isn't my very interest but those patches had to be
done to get the new PowerBook models running smooth. Hopefully there's
someone else interested in doing the split because it would be a good
thing.
> It would not be the perfect solution for Apple keyboards, [...]
Does that mean the patch doesn't get into the kernel until the split
happened?
Thanks,
Michael
On Tuesday 03 January 2006 17:11, Michael Hanselmann wrote:
> Hello Vojtech
>
> On Tue, Jan 03, 2006 at 08:53:44PM +0100, Vojtech Pavlik wrote:
> > We should split HID in two parts - transport and decoding. This would
> > help in many places:
> > [...]
>
> > I don't have the time to do the split myself, but it shouldn't be too
> > hard.
>
> And for myself, I think I'm not enough into kernel development already.
> Beside of that, USB isn't my very interest but those patches had to be
> done to get the new PowerBook models running smooth. Hopefully there's
> someone else interested in doing the split because it would be a good
> thing.
>
> > It would not be the perfect solution for Apple keyboards, [...]
>
> Does that mean the patch doesn't get into the kernel until the split
> happened?
>
No, it does not mean that.
--
Dmitry
On Tue, Jan 03, 2006 at 11:11:33PM +0100, Michael Hanselmann wrote:
> Hello Vojtech
>
> On Tue, Jan 03, 2006 at 08:53:44PM +0100, Vojtech Pavlik wrote:
> > We should split HID in two parts - transport and decoding. This would
> > help in many places:
> > [...]
>
> > I don't have the time to do the split myself, but it shouldn't be too
> > hard.
>
> And for myself, I think I'm not enough into kernel development already.
> Beside of that, USB isn't my very interest but those patches had to be
> done to get the new PowerBook models running smooth. Hopefully there's
> someone else interested in doing the split because it would be a good
> thing.
>
> > It would not be the perfect solution for Apple keyboards, [...]
>
> Does that mean the patch doesn't get into the kernel until the split
> happened?
No, I'm fine with the patch going in, but it can be removed and redone
as a separate HID parser if the split happens.
--
Vojtech Pavlik
SuSE Labs, SuSE CR
Hi guys,
> We should split HID in two parts - transport and decoding. This would
> help in many places:
>
> Bluetooth would be happy, because it uses the same HID protocol
> on top of a different transport layer (completely non-USB).
>
> Wacom and many other blacklisted devices would be happy, because
> they could use the USB HID transport - no blacklist would be
> needed.
>
> Would allow for /dev/usb/rawhid0 style devices, which would give
> access to raw HID reports without any parsing done.
>
> Would allow userspace drivers for broken UPS devices (like APC)
> without the need for special handling of their bugs in the kernel.
>
> It seems to me it could be almost its own layer, like serio or gameport.
> Windows has an API like that.
>
> I don't have the time to do the split myself, but it shouldn't be too
> hard.
I actually started this work when I presented the Bluetooth HID at the
Linux-Kongress 2004. However getting this fully done is not as easy as
it sounds. There are still parts inside the HID driver that I still have
no clue why they exists and what they actually do. A good revision
history inside the SCM seems really important for this driver.
The biggest problem that I see is that we can't break the current USB
HID driver, because this will render a lot of desktop system totally
useless and one 2.6 release is not enough to sort the problems out. Even
breaking the -mm kernel doesn't sound very helpful.
My idea actually was to create a HID subsystem under drivers/hid/ which
will be a fully copy of the current usbhid.ko driver, but without any
USB related code. This means that hiddev needs its own major number.
After that I am happy to offer the Bluetooth subsystem as testing base
for the new HID subsystem. The number of devices are still limited, but
it should be enough to sort out the basic problems.
The rawhidX devices should not be USB specific, because we might even
need them with Bluetooth as transport. There exists a Wacom tablet that
might make use of it.
I also need raw access to the reports (sending and receiving) for some
special features. The LCD displays of some Logitech keyboards are using
two report IDs for this job. It would be great to handle them via a
special rawhidX (with a ID filter) or via an extra driver while the
basic input processing is still done by the HID driver.
Regards
Marcel