* Re: [RFC v2] [HID] allow using external Hid Descriptors.
2009-12-24 13:52 [RFC v2] [HID] allow using external Hid Descriptors Marcin Tolysz
@ 2009-12-31 19:24 ` Marcin Tolysz
0 siblings, 0 replies; 2+ messages in thread
From: Marcin Tolysz @ 2009-12-31 19:24 UTC (permalink / raw)
To: linux-input
Politics:
Q1) Why is this patch important?
A1) Linux HID driver is really good code, however because of errors in
HID description reports we need to write separate drivers, patching,
and playing with raw data: reimplementing the hid event reporting, and
adding quirks.
Most of the hardware could be usable just after providing a valid hid
descriptor!
Q2) But is it useful. How can I use it?
A2). Take, Sony Vaio VGX has wrongly mouse pointer declared as
constant from hid-sony.c there is a just a bit of code which fixes
descriptor. We were lucky as we did not needed to change its size.
But the most sane approach is to fix the descriptor! as it is the only
stuff needed.
1) dump it from /debug/hid/!!device!!/rdesc
2) copy&edit it leaving only 1st line
3) convert to bin eg. cat descriptor.txt | hex2bin.sh > descriptor.bin
----hex2bin.sh
#!/bin/bash
echo -n -e $(tr -d '[:space:]' | sed 's/../\\x&/g')
4) place in /lib/firmware/hid/... where the location is provided by kern.log
BTW, If someone could fix this descriptor, the mouse could be removed
from hid-sony.c
Q3) Why I want this?
A3) A while back, a year back I thought it would be possible to make
PS3 Sixaxis Controller(over USB, as current BT stack is broken for
this controller) usable with Linux. Just by replacing its descriptor,
the previous solution required static compiled in array and
recompilation after each change, with this one you can edit it,
re-plug device, and see in /debug/hid/ the resultant parse (!).
Q4) Did I managed to do this?
A4) Yes, but it requires a bit more than just HID, it requires
patching the hid-core, and hid-input, and hid-sony.
1)Sixaxis report, provides its accelerometers in reversed to standard
(for hid report) endianes, thus I need to swap those bits in the
report.
2)Create a proper report (now it takes 16 bits for each of the
accelerometers the first two have logical range [512-128,512+127],
with physical [127,-128][inverted by hid-input but we can compensate
this in descriptor inverting it once more] and [-128,127]) the last
two [0,1024] and [-512,512] (done.) + as extra putting buttons in a
proper order.
Soon I will focus more on the other features reported by this device
and investigate how to make it rumble just by playing with its
descriptor.
3)Now the hard bit, we need to use Logical(hardware) and Physical(what
the user wants to see) extrema, the current implementation uses just
Logical one, this requires one step more processing by user-land
software (events are reported in logical terms, I did not seen how to
extract the physical extrema latter, and reimplement its handling in
every software). I had used translation from logical to physical,
based on values from the descriptor (and if this was wrong, we can fix
it by replacing it :D ), I have changed the parser to use signed vales
for both physical extrema, as in case pmax < pmin
translation[(pmax-pmin)*(x-min)/(max-min) + pmin] inverts the axis.
(This fixes EVENTS reporting, and works with jscalibrator)
4) hid-input, just a small change to report not logical but physical
extrema for axes (+handling pmax<pmin +some more handling)
[the patch will come soon I just need to clean it a bit more]
Works!
2009/12/24 Marcin Tolysz <tolysz@gmail.com>:
> It simple yet effective way of changing HID device descriptors
> using kernel firmware loading mechanism.
> Each time kernel will initialise a new hid device it will print
> as INFO the searched location for new descriptor.
>
> Just place your new descriptor in binary format in this location
> i.e. somewhere in /lib/firmware/hid/
> and it will use it in-place of HID descriptor of the device.
>
> This is good enough for now but ideally there should be a way of
> hotswaping it (i.e. while using this device) now we need to reconnect it.
> This would be ideal for some game controllers where you change its layout
> dynamically depending on add-ons you connect to it (i.e. wii)
>
> There are few questions:
> 1) What file name should have in it? What in it: SN, VEN,PROD,BUS,VER,...
> giving the ability to hard code each device, or to rely on "hotplug".
> 2) Should we print the info each time as we can see the info from
> the firmware_class telling us the location.
>
> Signed-off-by: Marcin Tolysz <tolysz@gmail.com>
> ---
> drivers/hid/hid-core.c | 29 ++++++++++++++++++++++++++++-
> 1 files changed, 28 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
> index 80792d3..4ee4299 100644
> --- a/drivers/hid/hid-core.c
> +++ b/drivers/hid/hid-core.c
> @@ -27,6 +27,7 @@
> #include <linux/wait.h>
> #include <linux/vmalloc.h>
> #include <linux/sched.h>
> +#include <linux/firmware.h>
>
> #include <linux/hid.h>
> #include <linux/hiddev.h>
> @@ -640,6 +641,10 @@ int hid_parse_report(struct hid_device *device, __u8 *start,
> struct hid_item item;
> __u8 *end;
> int ret;
> + const struct firmware *fw;
> + int fw_fail;
> + const char *file;
> +
> static int (*dispatch_type[])(struct hid_parser *parser,
> struct hid_item *item) = {
> hid_parser_main,
> @@ -650,10 +655,28 @@ int hid_parse_report(struct hid_device *device, __u8 *start,
>
> if (device->driver->report_fixup)
> device->driver->report_fixup(device, start, size);
> + /* Now try to load a hid descriptor from a file firmware
> + if succesful ignoring this fixup thing */
> + file = kasprintf(GFP_KERNEL, "hid/%04X:%04X:%04X:%04X.bin",
> + device->bus, device->vendor, device->product, device->version);
> +
> + fw_fail = request_firmware(&fw, file, &device->dev);
> +
> + if (fw_fail)
> + pr_info("To relace HID descriptor place it in /lib/firmaware/%s\n", file);
> + else{
> + start = fw->data;
> + size = fw->size;
> + pr_info("HID descriptor relaced with /lib/firmaware/%s\n", file);
> + }
> + kfree(file);
>
> device->rdesc = kmalloc(size, GFP_KERNEL);
> - if (device->rdesc == NULL)
> + if (device->rdesc == NULL) {
> + if (!fw_fail)
> + release_firmware(fw);
> return -ENOMEM;
> + }
> memcpy(device->rdesc, start, size);
> device->rsize = size;
>
> @@ -690,6 +713,8 @@ int hid_parse_report(struct hid_device *device, __u8 *start,
> dbg_hid("unbalanced delimiter at end of report description\n");
> goto err;
> }
> + if (!fw_fail)
> + release_firmware(fw);
> vfree(parser);
> return 0;
> }
> @@ -697,6 +722,8 @@ int hid_parse_report(struct hid_device *device, __u8 *start,
>
> dbg_hid("item fetching failed at offset %d\n", (int)(end - start));
> err:
> + if (!fw_fail)
> + release_firmware(fw);
> vfree(parser);
> return ret;
> }
> --
> 1.6.5.7
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 2+ messages in thread