Hi,
I'm a kernel newbie so please, pardon my French.
I have a Saitek Cyborg Evo Force, a very good joystick with force-
feedback. Problem is, on Windows it works well (its drivers know its
own idiosyncrasies) but on Linux it gets a bit fuzzy.
The behaviour is that, all axis are working fine, except up/down
(elevator) and left/right (aileron) that gives me "random"
signed/unsigned values.
A smaller problem is that it's reporting 8 axis but have 6 only and 13
buttons but have only 12 and the 12th button is always pressed,
messing fgjs setup utility.
Digging drivers/input/joydev.c I found out that if I remove the
correction (setting
JS_CORR_NONE) the values come correct, in a range from 0 to 4096.
Problem is, on joydev_connect, when defining the corrections for every
axis, the joystick is reporting dev->absmax = 127 and dev->absmin =
-127 for both axis 0 and 1, so the correction is based on a signed
range when the joystick is actually sending an unsigned range.
Also, because the module was expecting up to 127 on value and is getting
4094, when the correction does a left shift it might be setting the
signal bit (leftmost) and that could explain why I'm getting random
signed/unsigned values.
The only way to know what is the real range is when you're actually
pushing and pulling the stick so the change I'm willing to make is to
recalibrate (ie. redefine the correction) whenever the raw value goes
off limits. But that would only extend 127 to 4096 but won't change -127
to 0.
Another alternative is to do a dynamic calibration whenever you move the
stick from the beginning and not do it based on what the joystick is
telling you to (ie. at connect time). But that might be a lot of useless
work when the control gives you the correct range in the first place.
At last, hardcoding "if (saitek)" is quite ugly but can be done for the
sake of performance.
comments, please.
cheers,
--renato
Reclaim your digital rights, eliminate DRM, learn more at
http://www.defectivebydesign.org/what_is_drm
On 18/05/07, Renato Golin <[email protected]> wrote:
> Problem is, on joydev_connect, when defining the corrections for every
> axis, the joystick is reporting dev->absmax = 127 and dev->absmin =
> -127 for both axis 0 and 1, so the correction is based on a signed
> range when the joystick is actually sending an unsigned range.
Quick fix so I can play flightgear:
on joydev_connect, created absmin and absmax to avoid messing dev
variables (pointer)
if current position (dev->abs) is not in range:
if (dev->abs[j] > dev->absmax[j] || dev->abs[j] < dev->absmin[j]) {
absmin = 0;
absmax = dev->abs[j] * 2;
}
problems:
- it only works when joy is centred at connection
- it assumes the joy will report correct positions (instead of uncalibrated)
Now I'll figure out how to turn off button 12...
cheers,
--renato
Reclaim your digital rights, eliminate DRM, learn more at
http://www.defectivebydesign.org/what_is_drm
On Friday 18 May 2007 09:54, Renato Golin wrote:
> Hi,
>
> I'm a kernel newbie so please, pardon my French.
>
> I have a Saitek Cyborg Evo Force, a very good joystick with force-
> feedback. Problem is, on Windows it works well (its drivers know its
> own idiosyncrasies) but on Linux it gets a bit fuzzy.
>
> The behaviour is that, all axis are working fine, except up/down
> (elevator) and left/right (aileron) that gives me "random"
> signed/unsigned values.
>
> A smaller problem is that it's reporting 8 axis but have 6 only and 13
> buttons but have only 12 and the 12th button is always pressed,
> messing fgjs setup utility.
>
> Digging drivers/input/joydev.c I found out that if I remove the
> correction (setting
> JS_CORR_NONE) the values come correct, in a range from 0 to 4096.
>
> Problem is, on joydev_connect, when defining the corrections for every
> axis, the joystick is reporting dev->absmax = 127 and dev->absmin =
> -127 for both axis 0 and 1, so the correction is based on a signed
> range when the joystick is actually sending an unsigned range.
>
> Also, because the module was expecting up to 127 on value and is getting
> 4094, when the correction does a left shift it might be setting the
> signal bit (leftmost) and that could explain why I'm getting random
> signed/unsigned values.
>
> The only way to know what is the real range is when you're actually
> pushing and pulling the stick so the change I'm willing to make is to
> recalibrate (ie. redefine the correction) whenever the raw value goes
> off limits. But that would only extend 127 to 4096 but won't change -127
> to 0.
>
> Another alternative is to do a dynamic calibration whenever you move the
> stick from the beginning and not do it based on what the joystick is
> telling you to (ie. at connect time). But that might be a lot of useless
> work when the control gives you the correct range in the first place.
>
> At last, hardcoding "if (saitek)" is quite ugly but can be done for the
> sake of performance.
>
I think we need to make HID driver to report real range for Saitek.
Jiri, any ideas?
--
Dmitry
On Mon, 21 May 2007, Dmitry Torokhov wrote:
> > I have a Saitek Cyborg Evo Force, a very good joystick with force-
> > feedback. Problem is, on Windows it works well (its drivers know its
> > own idiosyncrasies) but on Linux it gets a bit fuzzy.
> I think we need to make HID driver to report real range for Saitek.
> Jiri, any ideas?
Renato,
could you please turn on the HID debugging support ("Device Drivers -> HID
devices -> HID debugging support" in menuconfig of any reasonably recent
kernel) and show the output that appears when the joystick is plugged in,
and also when you generate the events that are messed up? This would
hopefully avoid any confusion regarding what is really going on and we'll
see what we can do with it.
Thanks,
--
Jiri Kosina
SUSE Labs
On 21/05/07, Jiri Kosina <[email protected]> wrote:
> could you please turn on the HID debugging support ("Device Drivers -> HID
> devices -> HID debugging support" in menuconfig of any reasonably recent
> kernel) and show the output that appears when the joystick is plugged in,
> and also when you generate the events that are messed up? This would
> hopefully avoid any confusion regarding what is really going on and we'll
> see what we can do with it.
Hi Jiri,
I was changing joydev.c in a tainted kernel (ubuntu 2.6.20) but with
an unchanged joy structure. I'm still trying to make the new kernel
(from kernel.org) run on my box but I'm getting a device-mapper error
several times per second and it seems is something related to mdadm
raid software it was installed. Will continue to try and get the HID
debug messages (as ubuntu's source doesn't have it)
Apart from that, I did the auto calibration for two reasons:
1. getting the min/max information from input_dev, the device was
giving me -127/127 instead of 0/4096. The problem can be below the
joydev.c level, on HID (as you say) but there's a second reason.
2. The windows driver, developed by saitek itself (I suppose) have
exactly the same behaviour. Every time I plug the joy in it's
uncalibrated, than I have to move around a few times and play. Not
much harassment, but I believe that, if they did it in their own
driver it's because they don't trust their own hardware.
Anyway, I'll continue with the kernel 2.6.21 in which I have enabled
HID debugging messages and will send you the logs as soon as I have
them.
cheers,
--renato
Reclaim your digital rights, eliminate DRM, learn more at
http://www.defectivebydesign.org/what_is_drm
On 21/05/07, Jiri Kosina <[email protected]> wrote:
> could you please turn on the HID debugging support ("Device Drivers -> HID
> devices -> HID debugging support" in menuconfig of any reasonably recent
> kernel) and show the output that appears when the joystick is plugged in,
> and also when you generate the events that are messed up? This would
> hopefully avoid any confusion regarding what is really going on and we'll
> see what we can do with it.
Hi Jiri,
Couldn't make the generic kernel work on Ubuntu, it's quite a mess.
The distro kernel have USB general debugging instead of HID_DEBUG but
I had to manually redefine DEBUG and DEBUG_DATA on all hid*.c sources
and recompile the modules.
The HID sources are quite different from 2.6.21 and 2.6.20 but I don't
know how much was because Canonical guys and how much it really
changed. :( I will eventually put a Gentoo on my old laptop and try it
for real, sorry I couldn't be of much help now...
The only additional thing I got from debugging hid.ko and usbhid.ko
was right after detecting the mouse so I guess it didn't help at all.
--renato
May 30 00:40:06 jobim kernel: [ 7151.757499] usbcore: deregistering
interface driver usbhid
May 30 00:40:06 jobim kernel: [ 7151.769001] usbcore: deregistering
interface driver hiddev
May 30 00:40:06 jobim kernel: [ 7151.786229] usbcore: registered new
interface driver hiddev
May 30 00:40:06 jobim kernel: [ 7151.792457] input: Dell Dell USB
Mouse as /class/input/input56
May 30 00:40:06 jobim kernel: [ 7151.792816] input: USB HID v1.10
Mouse [Dell Dell USB Mouse] on usb-0000:00:0b.0-3
May 30 00:40:06 jobim kernel: [ 7151.807413] input: Saitek Cyborg Evo
Force as /class/input/input57
May 30 00:40:06 jobim kernel: [ 7151.807766] input: USB HID v1.00
Joystick [Saitek Cyborg Evo Force] on usb-0000:00:0b.0-7
May 30 00:40:06 jobim kernel: [ 7151.808122] usbcore: registered new
interface driver usbhid
May 30 00:40:06 jobim kernel: [ 7151.808328]
drivers/usb/input/hid-core.c: v2.6:USB HID core driver
May 30 00:41:54 jobim kernel: [ 7260.252015] usbcore: deregistering
interface driver usbhid
May 30 00:41:54 jobim kernel: [ 7260.258180] usbcore: deregistering
interface driver hiddev
May 30 00:41:54 jobim kernel: [ 7260.276444] usbcore: registered new
interface driver hiddev
May 30 00:41:54 jobim kernel: [ 7260.293406] input: Dell Dell USB
Mouse as /class/input/input58
May 30 00:41:54 jobim kernel: [ 7260.293709] input: USB HID v1.10
Mouse [Dell Dell USB Mouse] on usb-0000:00:0b.0-3
May 30 00:41:54 jobim kernel: 09 02 26 2b 01 45 00 95 02 91 02 c0 05
0f 09 a7 27 fe ff 00 00 47 fe ff 00 00 95 01 55 fd 66 01 10 91 02 55
00 65 00 c0 09 5a a1 02 85 0c 09 23 26 2b 01 45 00 91 02 09 5c 26 10
27 46 10 27 55 fd 66 01 10 91 02 55 00 65 00 09 5b 25 7f 75 08 91 02
09 5e 26 10 27 75 10 55 fd 66 01 10 91 02 55 00 65 00 09 5d 25 7f 75
08 91 02 c0 09 73 a1 02 85 0d 09 23 26 2b 01 45 00 75 10 91 02 09 70
15 81 25 7f 36 f0 d8 46 10 27 75 08 91 02 c0 09 6e a1 02 85 0e 09 23
15 00 26 2b 01 35 00 45 00 75 10 91 02 09 70 25 7f 46 10 27 75 08 91
02 09 6f 15 81 36 f0 d8 91 02 09 71 15 00 26 ff 00 35 00 46 68 01 91
02 09 72 26 10 27 46 10 27 75 10 55 fd 66 01 10 91 02 55 00 65 00 c0
09 5f a1 02 85 0f 09 23 26 2b 01 45 00 91 02 09 61 15 9c 25 64 36 f0
d8 46 10 27 75 08 91 02 09 62 91 02 09 60 16 0c fe 26 f4 01 75 10 91
02 09 65 15 00 26 e8 03 35 00 91 02 09 63 25 64 75 08 91 02 09 64 91
02 c0 09 77 a1 02 85 51 09 22 25 09 45 00 91 02 09 78 a1 02 09 7b 09
79 09 7a 15 01 25 03 91 00 c0 09 7c 15 00 26 fe 00 91 02 c0
May 30 00:41:54 jobim kernel: 92 a1 02 85 52 09 96 a1 02 09 9a 09 99
09 97 09 98 09 9b 09 9c 15 01 25 06 91 00 c0 c0 05 ff 0a 01 03 a1 02
85 40 0a 02 03 a1 02 1a 11 03 2a 20 03 25 10 91 00 c0 0a 03 03 15 00
27 ff ff 00 00 75 10 91 02 c0 05 0f 09 7d a1 02 85 43 09 7e 26 80 00
46 10 27 75 08 91 02 c0 09 85 a1 02 85 44 09 86 27 ff ff 00 00 45 00
75 10 91 02 09 87 91 02 09 88 91 02 c0 05 ff 0a 00 01 a1 02 85 81 05
01 09 30 15 81 25 7f 36 f0 d8 46 10 27 75 08 91 02 09 31 91 02 c0 05
0f 09 7f a1 02 85 0b 09 80 15 00 26 ff 7f 35 00 45 00 75 0f b1 03 09
a9 25 01 75 01 b1 03 09 83 26 ff 00 75 08 b1 03 09 84 25 10 b1 03 09
a8 a1 02 09 73 09 6e 09 5a 09 5f 95 04 b1 03 c0 c0 c0
May 30 00:41:54 jobim kernel: [ 7260.320561] input: Saitek Cyborg Evo
Force as /class/input/input59
May 30 00:41:54 jobim kernel: [ 7260.320633] input: USB HID v1.00
Joystick [Saitek Cyborg Evo Force] on usb-0000:00:0b.0-7
May 30 00:41:54 jobim kernel: [ 7260.320654] usbcore: registered new
interface driver usbhid
May 30 00:41:54 jobim kernel: [ 7260.320660]
drivers/usb/input/hid-core.c: v2.6:USB HID core driver
On Wed, 30 May 2007, Renato Golin wrote:
> The HID sources are quite different from 2.6.21 and 2.6.20 but I don't
> know how much was because Canonical guys and how much it really changed.
> :( I will eventually put a Gentoo on my old laptop and try it for real,
> sorry I couldn't be of much help now...
Hi Renato,
well I have changed the overall HID code design in 2.6.21 a little bit.
Anyway, just hardcoding '#define DEBUG' and '#define DEBUG_DATA' (that's
also important) in 2.6.20-and-older kernels should have similar result as
CONFIG_HID_DEBUG in post-2.6.21.
In your particular case, the DEBUG_DATA might really be more interesting.
Thanks,
--
Jiri Kosina
SUSE Labs
On 30/05/07, Jiri Kosina <[email protected]> wrote:
> well I have changed the overall HID code design in 2.6.21 a little bit.
> Anyway, just hardcoding '#define DEBUG' and '#define DEBUG_DATA' (that's
> also important) in 2.6.20-and-older kernels should have similar result as
> CONFIG_HID_DEBUG in post-2.6.21.
>
> In your particular case, the DEBUG_DATA might really be more interesting.
Yup, did both on all drivers/hid/*.c and drivers/usb/input/hid*.c
recompiled and reloaded all modules (hid.ko, usbhid.ko and joydev.ko)
But it's pathetic the fact that ubuntu's kernel have an option
USB_DEBUG and on Makefile is says "if USB_DEBUG; aditional_opt=
-DDEBUG" but inside the files all DEBUG flags are hardcoded undefined.
Also, to turn on KERN_DEBUG messages I saw on kernel hacking webpages:
$ echo 15 15 15 15 > /proc/sys/kernel/printk
$ echo 8 > /proc/sys/kernel/printk
I did it and monitored mesasges and syslog and both shows the same
data... I guess that dump after mouse detection is DEBUG_DATA in
place.
cheers,
--renato
Reclaim your digital rights, eliminate DRM, learn more at
http://www.defectivebydesign.org/what_is_drm
On Wed, 30 May 2007, Renato Golin wrote:
> But it's pathetic the fact that ubuntu's kernel have an option USB_DEBUG
> I did it and monitored mesasges and syslog and both shows the same
> data... I guess that dump after mouse detection is DEBUG_DATA in place.
Hi Renato,
do any data appear in the kernel log when you generate events with the
device (i.e. move the joystick, press the buttons, etc)? That should be
reported if DEBUG_DATA is defined properly on the older kernels.
Thanks,
--
Jiri Kosina
On 30/05/07, Jiri Kosina <[email protected]> wrote:
> do any data appear in the kernel log when you generate events with the
> device (i.e. move the joystick, press the buttons, etc)? That should be
> reported if DEBUG_DATA is defined properly on the older kernels.
Not at all... only my own debug messages from joydev (like:
recalibrating for value 2048) when a new limit is reached. I've even
changed "printk(KERN_DEBUG ...)" to a plain printk() as I do on joydev
to avoid fall into the wrong log level but didn't work as well.
I've changed USB DEBUG in menuconfig, saved the new conf.
The files I've changed manually (undef -> define) were:
-> drivers/hid/
hid-core.c:#undef DEBUG
hid-core.c:#undef DEBUG_DATA
hid-input.c:#undef DEBUG
-> drivers/usb/input/
hid-core.c:#undef DEBUG
hid-core.c:#undef DEBUG_DATA
hid-ff.c:#undef DEBUG
hid-tmff.c:#undef DEBUG
than
$ make drivers/hid/hid.ko drivers/usb/input/usbhid.ko
$ rmmod usbhid hid ; modprobe usbhid hid
the output from the last mail was on both /var/log/messages and
syslog, although syslog had other messages from the network card
(using ndiswrapper).
cheers,
--renato
Reclaim your digital rights, eliminate DRM, learn more at
http://www.defectivebydesign.org/what_is_drm
On 30/05/07, Renato Golin <[email protected]> wrote:
> On 30/05/07, Jiri Kosina <[email protected]> wrote:
> > do any data appear in the kernel log when you generate events with the
> > device (i.e. move the joystick, press the buttons, etc)? That should be
> > reported if DEBUG_DATA is defined properly on the older kernels.
Hi Jiri, at last!!
HID is reporting the axis' range correctly:
May 30 23:19:07 jobim kernel: [ 3316.543445] hid-debug: input
GenericDesktop.X = 2044
May 30 23:19:07 jobim kernel: [ 3316.543451] hid-debug: input
GenericDesktop.Y = 2044
(...)
May 30 23:19:07 jobim kernel: [ 3316.545490] INPUT(6)[INPUT]
May 30 23:19:07 jobim kernel: [ 3316.545495] Field(0)
May 30 23:19:07 jobim kernel: [ 3316.545499]
Physical(GenericDesktop.Pointer)
May 30 23:19:07 jobim kernel: [ 3316.545506] Usage(1)
May 30 23:19:07 jobim kernel: [ 3316.545510] GenericDesktop.X
May 30 23:19:07 jobim kernel: [ 3316.545517] Logical Minimum(0)
May 30 23:19:07 jobim kernel: [ 3316.545522] Logical Maximum(4096)
May 30 23:19:07 jobim kernel: [ 3316.545526] Physical Minimum(0)
May 30 23:19:07 jobim kernel: [ 3316.545531] Physical Maximum(4096)
May 30 23:19:07 jobim kernel: [ 3316.545536] Report Size(16)
May 30 23:19:07 jobim kernel: [ 3316.545540] Report Count(1)
May 30 23:19:07 jobim kernel: [ 3316.545545] Report Offset(0)
May 30 23:19:07 jobim kernel: [ 3316.545550] Flags( Variable Absolute )
May 30 23:19:07 jobim kernel: [ 3316.545558] Field(1)
May 30 23:19:07 jobim kernel: [ 3316.545562]
Physical(GenericDesktop.Pointer)
May 30 23:19:07 jobim kernel: [ 3316.545568] Usage(1)
May 30 23:19:07 jobim kernel: [ 3316.545573] GenericDesktop.Y
May 30 23:19:07 jobim kernel: [ 3316.545579] Logical Minimum(0)
May 30 23:19:07 jobim kernel: [ 3316.545584] Logical Maximum(4096)
May 30 23:19:07 jobim kernel: [ 3316.545588] Physical Minimum(0)
May 30 23:19:07 jobim kernel: [ 3316.545593] Physical Maximum(4096)
May 30 23:19:07 jobim kernel: [ 3316.545597] Report Size(16)
May 30 23:19:07 jobim kernel: [ 3316.545602] Report Count(1)
May 30 23:19:07 jobim kernel: [ 3316.545607] Report Offset(16)
May 30 23:19:07 jobim kernel: [ 3316.545611] Flags( Variable Absolute )
Now, why joydev's input_dev is reporting -127, 127 just for the two first axis?
Another problem is that the joystick reports 12 (1-12) buttons and
joydev get's 0-12 (13 buttons):
May 30 23:19:07 jobim kernel: [ 3316.543461] hid-debug: input Button.0001 = 0
May 30 23:19:07 jobim kernel: [ 3316.543466] hid-debug: input Button.0002 = 0
May 30 23:19:07 jobim kernel: [ 3316.543470] hid-debug: input Button.0003 = 0
May 30 23:19:07 jobim kernel: [ 3316.543474] hid-debug: input Button.0004 = 0
May 30 23:19:07 jobim kernel: [ 3316.543478] hid-debug: input Button.0005 = 0
May 30 23:19:07 jobim kernel: [ 3316.543482] hid-debug: input Button.0006 = 0
May 30 23:19:07 jobim kernel: [ 3316.543486] hid-debug: input Button.0007 = 0
May 30 23:19:07 jobim kernel: [ 3316.543490] hid-debug: input Button.0008 = 0
May 30 23:19:07 jobim kernel: [ 3316.543494] hid-debug: input Button.0009 = 0
May 30 23:19:07 jobim kernel: [ 3316.543498] hid-debug: input Button.000a = 0
May 30 23:19:07 jobim kernel: [ 3316.543502] hid-debug: input Button.000b = 0
May 30 23:19:07 jobim kernel: [ 3316.543506] hid-debug: input Button.000c = 0
cheers,
--renato
Reclaim your digital rights, eliminate DRM, learn more at
http://www.defectivebydesign.org/what_is_drm
On 5/30/07, Renato Golin <[email protected]> wrote:
>
> Now, why joydev's input_dev is reporting -127, 127 just for the two first axis?
Is it getting hit with HID_QUIRK_BADPAD? What does evtest utility show
for the device?
--
Dmitry
On Thu, 31 May 2007, Dmitry Torokhov wrote:
> > Now, why joydev's input_dev is reporting -127, 127 just for the two
> > first axis?
> Is it getting hit with HID_QUIRK_BADPAD? What does evtest utility show
> for the device?
Yes, the problem with axis ranges definitely looks like that. Renato,
could you please send me vendor id and product id of the joystick in
question, I will send you a patch to test whether normalizing the values
on hid-level (as we already do for several other joypads) will do the
trick?
I have currently no idea about the incorrect number of buttons, will look
at it a little bit more.
Thanks,
--
Jiri Kosina
SUSE Labs
On Thu, 31 May 2007, Jiri Kosina wrote:
> Yes, the problem with axis ranges definitely looks like that. Renato,
> could you please send me vendor id and product id of the joystick in
> question, I will send you a patch to test whether normalizing the values
> on hid-level (as we already do for several other joypads) will do the
> trick?
... or if you are running reasonably recent kernel (2.6.22-rc1 or newer),
you can add the quirk in runtime without need to recompile, just pass the
parameter in the format
quirks=0xAAAA:0xBBBB:0x20
to usbhid module, where 0xAAAA is vendor ID and 0xBBBB product ID of your
joystick.
Thanks,
--
Jiri Kosina
SUSE Labs
On 31/05/07, Jiri Kosina <[email protected]> wrote:
> Yes, the problem with axis ranges definitely looks like that. Renato,
> could you please send me vendor id and product id of the joystick in
> question, I will send you a patch to test whether normalizing the values
> on hid-level (as we already do for several other joypads) will do the
> trick?
Hi Jiri,
06a3:ffb5 Saitek PLC
I'm using 2.6.20 and compiling new kernels for Ubuntu is a nightmare.
Also, would be good not to need additional parameters for the general
public.
cheers,
--renato
Reclaim your digital rights, eliminate DRM, learn more at
http://www.defectivebydesign.org/what_is_drm
On Fri, 1 Jun 2007, Renato Golin wrote:
> 06a3:ffb5 Saitek PLC
Please try this patch on top of 2.6.20
diff --git a/drivers/usb/input/hid-core.c b/drivers/usb/input/hid-core.c
index c6c9e72..d73f949 100644
--- a/drivers/usb/input/hid-core.c
+++ b/drivers/usb/input/hid-core.c
@@ -692,6 +692,7 @@ void usbhid_init_reports(struct hid_devi
#define USB_DEVICE_ID_IBM_GAMEPAD 0x1101
#define USB_VENDOR_ID_SAITEK 0x06a3
+#define USB_DEVICE_ID_SAITEK_CYBORG 0xffb5
#define USB_DEVICE_ID_SAITEK_RUMBLEPAD 0xff17
#define USB_VENDOR_ID_NEC 0x073e
@@ -941,6 +942,7 @@ static const struct hid_blacklist {
{ USB_VENDOR_ID_HAPP, USB_DEVICE_ID_UGCI_FLYING, HID_QUIRK_BADPAD | HID_QUIRK_MULTI_INPUT },
{ USB_VENDOR_ID_HAPP, USB_DEVICE_ID_UGCI_FIGHTING, HID_QUIRK_BADPAD | HID_QUIRK_MULTI_INPUT },
{ USB_VENDOR_ID_NEC, USB_DEVICE_ID_NEC_USB_GAME_PAD, HID_QUIRK_BADPAD },
+ { USB_VENDOR_ID_SAITEK, USB_DEVICE_ID_SAITEK_CYBORG, HID_QUIRK_BADPAD },
{ USB_VENDOR_ID_SAITEK, USB_DEVICE_ID_SAITEK_RUMBLEPAD, HID_QUIRK_BADPAD },
{ USB_VENDOR_ID_TOPMAX, USB_DEVICE_ID_TOPMAX_COBRAPAD, HID_QUIRK_BADPAD },
> I'm using 2.6.20 and compiling new kernels for Ubuntu is a nightmare.
I have never used ubuntu, but why should that be that difficult? Just
download vanilla kernel from kernel.org, use your distro's .config, make
oldconfig && make ... ?
> Also, would be good not to need additional parameters for the general
> public.
Sure, this was rather a debugging option just to test whether this is the
proper quirk.
Thanks,
--
Jiri Kosina
SUSE Labs
On 03/06/07, Jiri Kosina <[email protected]> wrote:
> Please try this patch on top of 2.6.20
Hi Jiri,
Patched and run, we're almost there... I put an additional printk on
usb/input/hid-core.c and hid/hid-input.c to assure I got the right
copy, got the messages but not the fix.
What joydev reports is a range between 0 and 255, which is better than
-127 to 127 because it's unsigned but still requires further
calibration.
> I have never used ubuntu, but why should that be that difficult? Just
> download vanilla kernel from kernel.org, use your distro's .config, make
> oldconfig && make ... ?
The kernel is really simple, problem is that I use ubuntu since
version 5 and did distupgrade to 6.06, 6.10 and now 7.04. Lots of
configurations were changed, /dev structure, root points, mount, lvm
and lots of changes were made since then.
What's annoying me to get a personalized kernel now running is the lvm
new configuration that I don't master yet (nor am willing to lately)
and that's the only thing that breaks on my ubuntu with a personalized
kernel.
The filesystem changes were quite messy, on 6.10 I lost my swap space
(kernel couldn't mount it) and I didn't have time to investigate
properly. Now, with 7.04 it's back again... I'm too old to investigate
every detail... ;)
I'm sure if I get a fresh installation, kernel.org's kernel will work
like a charm...
cheers,
--renato
Reclaim your digital rights, eliminate DRM, learn more at
http://www.defectivebydesign.org/what_is_drm
On Mon, 4 Jun 2007, Renato Golin wrote:
> Patched and run, we're almost there... I put an additional printk on
> usb/input/hid-core.c and hid/hid-input.c to assure I got the right copy,
> got the messages but not the fix.
Hi Renato,
sorry, don't fully understand - what do you mean by "got the messages but
not the fix"?
> What joydev reports is a range between 0 and 255, which is better than
> -127 to 127 because it's unsigned but still requires further
> calibration.
Well calibration using jscal might be needed, that should be fine. The
question is whether the ranges are now correct and calibration using jscal
works fine.
So please let me know whether the badpad quirk is the correct one for this
joystick. If so, I'll queue it in my tree for upstream.
Thanks,
--
Jiri Kosina
SUSE Labs
On 04/06/07, Jiri Kosina <[email protected]> wrote:
> sorry, don't fully understand - what do you mean by "got the messages but
> not the fix"?
The range "detected" was 0 to 255 but both X and Y axis are reporting 4096.
I think that the code in drivers/hid/hid-input.c:
if ((device->quirks & HID_QUIRK_BADPAD) && (usage->code == ABS_X ||
usage->code == ABS_Y)) {
a = field->logical_minimum = 0;
b = field->logical_maximum = 255;
}
should get what's being reported from the device instead of hard-code
to 0 to 255 (which might not even be an unsigned range).
> Well calibration using jscal might be needed, that should be fine. The
> question is whether the ranges are now correct and calibration using jscal
> works fine.
Ok, so maybe in that case my automatic calibration is still worth to
put on joydev.c
and users from all joysticks in the quirk list would benefit.
> So please let me know whether the badpad quirk is the correct one for this
> joystick. If so, I'll queue it in my tree for upstream.
Well, it did the trick if that's what you mean but would be better to
get the correct range from start... But I don't know how difficult it
is, so maybe we'll have to stick with the automatic calibration
afterwards...
cheers,
--renato
Reclaim your digital rights, eliminate DRM, learn more at
http://www.defectivebydesign.org/what_is_drm
On 04/06/07, Renato Golin <[email protected]> wrote:
> > Well calibration using jscal might be needed, that should be fine. The
> > question is whether the ranges are now correct and calibration using jscal
> > works fine.
>
> Ok, so maybe in that case my automatic calibration is still worth to
> put on joydev.c
> and users from all joysticks in the quirk list would benefit.
Hi Dmitry,
The patch to joydev.c was updated on Andrew's list do you see any
problem with it?
cheers,
--renato
Reclaim your digital rights, eliminate DRM, learn more at
http://www.defectivebydesign.org/what_is_drm
On Mon, 4 Jun 2007, Renato Golin wrote:
> > sorry, don't fully understand - what do you mean by "got the messages
> > but not the fix"?
> The range "detected" was 0 to 255 but both X and Y axis are reporting
> 4096.
> I think that the code in drivers/hid/hid-input.c:
> if ((device->quirks & HID_QUIRK_BADPAD) && (usage->code == ABS_X ||
> usage->code == ABS_Y)) {
> a = field->logical_minimum = 0;
> b = field->logical_maximum = 255;
> }
Hi Renato,
the thing is that the aim of this quirk is to normalize the values that
are being reported by bogus devices, so we don't really want to trust the
values they provide here, do we?
Thanks,
--
Jiri Kosina
SUSE Labs
On 12/06/07, Jiri Kosina <[email protected]> wrote:
> the thing is that the aim of this quirk is to normalize the values that
> are being reported by bogus devices, so we don't really want to trust the
> values they provide here, do we?
Hi Jiri,
I don't know about the other joysticks, but Saitek did reported [0,
4096] which is the right answer, but between HID and Joydev it was
converted to [-127, 127]. I thought that the quirk was about that.
But seeing the quirk code it seems that if the range doesn't match it
forces [0, 256] (not trusting anything the device sends) and that's
not really needed for Saitek.
I'm not at all sure how the other devices behave and I do understand
the difficulty in testing every single one.
My opinion is that we shouldn't fall back to a hard-coded range for
all types of errors and rely on user calibration. Normally, game users
tend to dislike having to quit the game and recalibrate the joystick
to restart the game again (I do, at least). Furthermore, dealing with
every single type of error is impossible unless you have all devices
available for a recursive test every time something change, which is
not true.
Therefore, my view is that the only neat solution to all that is to
report the range as [0, 0] and auto-calibrate afterwards, while the
device is in use and reporting the real range. I found out that, not
all times the range goes to 4096, most of the time it stays as far as
4038, and setting the final range to that value (with
auto-calibration) is even more precise than the reported by the
device.
The drawback is the few calculations done during the first movements
of the joystick (function call and four small formulas) and the two
"IF (a > b)" for every axis event afterwards.
As this is my first kernel mode code I'm not sure how would that
schedule with other kernel processes (normally I rely on kernel's
scheduling process) but for a user-land program (real-time games
included) I wouldn't say it's too much overhead.
Let me know if I got it all backwards... ;)
cheers,
--renato
Reclaim your digital rights, eliminate DRM, learn more at
http://www.defectivebydesign.org/what_is_drm
Hi Renato,
On 6/12/07, Renato Golin <[email protected]> wrote:
> On 12/06/07, Jiri Kosina <[email protected]> wrote:
> > the thing is that the aim of this quirk is to normalize the values that
> > are being reported by bogus devices, so we don't really want to trust the
> > values they provide here, do we?
>
> Hi Jiri,
>
> I don't know about the other joysticks, but Saitek did reported [0,
> 4096] which is the right answer, but between HID and Joydev it was
> converted to [-127, 127]. I thought that the quirk was about that.
>
We need to find out why you see [-127, 127] range, because if joydev
would see [0, 4096] range it would perform automatic correction and
map values like this:
c0: 2048, c1: 2048, c2: 262144, c3: 262144
0 -> -32768
204 -> -29504
408 -> -26240
612 -> -22976
816 -> -19712
1020 -> -16448
1224 -> -13184
1428 -> -9920
1632 -> -6656
1836 -> -3392
2040 -> -128
2244 -> 3136
2448 -> 6400
2652 -> 9664
2856 -> 12928
3060 -> 16192
3264 -> 19456
3468 -> 22720
3672 -> 25984
3876 -> 29248
4080 -> 32512
Which is fine as far as I can see. What utility did you use that
reported [-127; 127] range?
--
Dmitry
On 12/06/07, Dmitry Torokhov <[email protected]> wrote:
> We need to find out why you see [-127, 127] range, because if joydev
> would see [0, 4096] range it would perform automatic correction and
> map values like this:
>
> c0: 2048, c1: 2048, c2: 262144, c3: 262144
Hi Dmitry,
That's the values I got *after* calibration. Before, because the
correction is set to a small signed value, it corrects wrongly and
report a random mix of signed and unsigned values when moving in one
direction...
> Which is fine as far as I can see. What utility did you use that
> reported [-127; 127] range?
At joydev_connect, the last parameter "input_dev" reports me that
range (dev->absmax[i] and dev->absmin[i]). When I turned on HID_DEBUG
it reported [0, 4096] for both axis 0 and 1, which is correct so it
must be between HID and joydev.
My point is that the auto-calibration could automagically solve all
range problems in all devices by zeroing the range and adapting the
ranges afterwards. If it can affect other devices as well as
joysticks, the calibration could happen in HID instead of joydev.
cheers,
--renato
Reclaim your digital rights, eliminate DRM, learn more at
http://www.defectivebydesign.org/what_is_drm
On 6/12/07, Renato Golin <[email protected]> wrote:
> On 12/06/07, Dmitry Torokhov <[email protected]> wrote:
> > We need to find out why you see [-127, 127] range, because if joydev
> > would see [0, 4096] range it would perform automatic correction and
> > map values like this:
> >
> > c0: 2048, c1: 2048, c2: 262144, c3: 262144
>
> Hi Dmitry,
>
> That's the values I got *after* calibration. Before, because the
> correction is set to a small signed value, it corrects wrongly and
> report a random mix of signed and unsigned values when moving in one
> direction...
>
Yes, if correction was calculated for [127; 127] range and the device
would feed [0; 4096] it would of course produce wrong results.
>
> > Which is fine as far as I can see. What utility did you use that
> > reported [-127; 127] range?
>
> At joydev_connect, the last parameter "input_dev" reports me that
> range (dev->absmax[i] and dev->absmin[i]). When I turned on HID_DEBUG
> it reported [0, 4096] for both axis 0 and 1, which is correct so it
> must be between HID and joydev.
>
Any change you could locate and run "evtest" utility and post its results?
> My point is that the auto-calibration could automagically solve all
> range problems in all devices by zeroing the range and adapting the
> ranges afterwards. If it can affect other devices as well as
> joysticks, the calibration could happen in HID instead of joydev.
>
We do not want to fix only joydev as it leaves other nput handlers
(for example access through evdev) still broken. That's why I want to
figure out where [0;4096] is being changed to [-127; 127].
--
Dmitry
On Tue, 12 Jun 2007, Renato Golin wrote:
> At joydev_connect, the last parameter "input_dev" reports me that range
> (dev->absmax[i] and dev->absmin[i]). When I turned on HID_DEBUG it
> reported [0, 4096] for both axis 0 and 1, which is correct so it must be
> between HID and joydev.
Renato,
could you please apply the stupid patch below (against 2.6.20, I know you
are using it :) ) and report the result? It should show us whether the
values 0 and 4096 (which can be seen in your hid parsing debug dump) are
correctly passed from HID to input, or they are garbled inside the hid
layer somewhere already.
Thanks.
diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
index c7a6833..9dea1e8 100644
--- a/drivers/hid/hid-input.c
+++ b/drivers/hid/hid-input.c
@@ -665,9 +665,16 @@ static void hidinput_configure_usage(str
b = field->logical_maximum = 255;
}
- if (field->application == HID_GD_GAMEPAD || field->application == HID_GD_JOYSTICK)
+ if (field->application == HID_GD_GAMEPAD || field->application == HID_GD_JOYSTICK) {
+ printk(KERN_DEBUG "calling input_set_abs_params, code: %x, min: %x, max: %x, fuzz: %x, flat: %x\n",
+ usage->code, a, b, (b - a) >> 8, (b - a) >> 4);
input_set_abs_params(input, usage->code, a, b, (b - a) >> 8, (b - a) >> 4);
- else input_set_abs_params(input, usage->code, a, b, 0, 0);
+ }
+ else {
+ printk(KERN_DEBUG "calling input_set_abs_params, code: %x, min: %x, max: %x, fuzz: %x, flat: %x\n",
+ usage->code, a, b, (b - a) >> 8, (b - a) >> 4);
+ input_set_abs_params(input, usage->code, a, b, 0, 0);
+ }
}
On 12/06/07, Jiri Kosina <[email protected]> wrote:
> could you please apply the stupid patch below (against 2.6.20, I know you
> are using it :) ) and report the result? It should show us whether the
> values 0 and 4096 (which can be seen in your hid parsing debug dump) are
> correctly passed from HID to input, or they are garbled inside the hid
> layer somewhere already.
Hi Jiri,
Applied your patch and the log is below,
thanks!
--renato
[ 6944.776870] input: USB HID v1.00 Joystick [Saitek Cyborg Evo Force]
on usb-0000:00:0b.0-7
[ 6944.777254] usbcore: registered new interface driver usbhid
[ 6944.790141] drivers/usb/input/hid-core.c: v2.6:USB HID core driver
[ 6973.503388] usbcore: deregistering interface driver usbhid
[ 6973.515956] usbcore: deregistering interface driver hiddev
[ 6973.565396] usbcore: registered new interface driver hiddev
[ 6973.571885] Key.LeftBtn
[ 6973.571893] Key.RightBtn
[ 6973.571901] Key.MiddleBtn
[ 6973.571909] Relative.X
[ 6973.571916] Relative.Y
[ 6973.571924] Relative.Wheel
[ 6973.573896] input: Dell Dell USB Mouse as /class/input/input40
[ 6973.574160] input: USB HID v1.10 Mouse [Dell Dell USB Mouse] on
usb-0000:00:0b.0-3
[ 6973.587817] hid-debug: input GenericDesktop.X = 2056
[ 6973.587824] hid-debug: input GenericDesktop.Y = 2064
[ 6973.587829] hid-debug: input Simulation.Throttle = 130
[ 6973.587834] hid-debug: input Button.0001 = 0
[ 6973.587839] hid-debug: input Button.0002 = 0
[ 6973.587843] hid-debug: input Button.0003 = 0
[ 6973.587847] hid-debug: input Button.0004 = 0
[ 6973.587852] hid-debug: input Button.0005 = 0
[ 6973.587856] hid-debug: input Button.0006 = 0
[ 6973.587860] hid-debug: input Button.0007 = 0
[ 6973.587864] hid-debug: input Button.0008 = 0
[ 6973.587868] hid-debug: input Button.0009 = 0
[ 6973.587872] hid-debug: input Button.000a = 0
[ 6973.587876] hid-debug: input Button.000b = 0
[ 6973.587880] hid-debug: input Button.000c = 0
[ 6973.587885] hid-debug: input GenericDesktop.HatSwitch = 15
[ 6973.587889] hid-debug: input Simulation.Rudder = 255
[ 6973.588816] hid-debug: input PhysicalInterfaceDevice.00a6 = 1
[ 6973.588823] hid-debug: input PhysicalInterfaceDevice.00a4 = 1
[ 6973.588827] hid-debug: input PhysicalInterfaceDevice.00a0 = 0
[ 6973.588832] hid-debug: input PhysicalInterfaceDevice.009f = 0
[ 6973.588837] hid-debug: input PhysicalInterfaceDevice.0022 = 7
[ 6973.588841] hid-debug: input PhysicalInterfaceDevice.0094 = 0
[ 6973.589816] hid-debug: input PhysicalInterfaceDevice.0080 = 300
[ 6973.589822] hid-debug: input PhysicalInterfaceDevice.00a9 = 0
[ 6973.589826] hid-debug: input PhysicalInterfaceDevice.0083 = 10
[ 6973.589831] hid-debug: input PhysicalInterfaceDevice.0084 = 2
[ 6973.589836] hid-debug: input PhysicalInterfaceDevice.0073 = 1
[ 6973.589841] hid-debug: input PhysicalInterfaceDevice.006e = 12
[ 6973.589845] hid-debug: input PhysicalInterfaceDevice.005a = 12
[ 6973.589850] hid-debug: input PhysicalInterfaceDevice.005f = 8
[ 6973.596010] calling input_set_abs_params, code: 0, min: 0, max:
1000, fuzz: 10, flat: 100
[ 6973.596013] Absolute.X
[ 6973.596022] calling input_set_abs_params, code: 1, min: 0, max:
1000, fuzz: 10, flat: 100
[ 6973.596024] Absolute.Y
[ 6973.596033] calling input_set_abs_params, code: 6, min: 0, max: ff,
fuzz: 0, flat: f
[ 6973.596035] Absolute.Throttle
[ 6973.596043] Key.Trigger
[ 6973.596050] Key.ThumbBtn
[ 6973.596058] Key.ThumbBtn2
[ 6973.596070] Key.TopBtn
[ 6973.596077] Key.TopBtn2
[ 6973.596084] Key.PinkieBtn
[ 6973.596091] Key.BaseBtn
[ 6973.596099] Key.BaseBtn2
[ 6973.596106] Key.BaseBtn3
[ 6973.596113] Key.BaseBtn4
[ 6973.596120] Key.BaseBtn5
[ 6973.596128] Key.BaseBtn6
[ 6973.596136] calling input_set_abs_params, code: 10, min: 0, max: 7,
fuzz: 0, flat: 0
[ 6973.596139] Absolute.Hat0X
[ 6973.596147] calling input_set_abs_params, code: 7, min: 0, max: ff,
fuzz: 0, flat: f
[ 6973.596149] Absolute.Rudder
[ 6973.596157] IGNORED
[ 6973.596165] Key.BtnDead
[ 6973.596172] IGNORED
[ 6973.596180] IGNORED
[ 6973.596187] IGNORED
[ 6973.596194] IGNORED
[ 6973.596201] IGNORED
[ 6973.596208] IGNORED
[ 6973.596215] IGNORED
[ 6973.596223] IGNORED
[ 6973.596230] IGNORED
[ 6973.596237] IGNORED
[ 6973.596244] IGNORED
[ 6973.596251] IGNORED
[ 6973.596258] IGNORED
[ 6973.596265] IGNORED
[ 6973.596272] IGNORED
[ 6973.596280] calling input_set_abs_params, code: 0, min: 0, max: 1,
fuzz: 0, flat: 0
[ 6973.596282] Absolute.X
[ 6973.596290] calling input_set_abs_params, code: 1, min: 0, max: 1,
fuzz: 0, flat: 0
[ 6973.596292] Absolute.Y
[ 6973.596300] IGNORED
[ 6973.596307] IGNORED
[ 6973.596314] IGNORED
[ 6973.596322] calling input_set_abs_params, code: 28, min: 0, max:
12b, fuzz: 1, flat: 12
[ 6973.596324] Absolute.Misc
[ 6973.596333] calling input_set_abs_params, code: 29, min: 0, max:
12b, fuzz: 1, flat: 12
[ 6973.596335] Absolute.?
[ 6973.596343] IGNORED
[ 6973.596350] IGNORED
[ 6973.596357] IGNORED
[ 6973.596364] IGNORED
[ 6973.596371] IGNORED
[ 6973.596379] IGNORED
[ 6973.596386] IGNORED
[ 6973.596393] IGNORED
[ 6973.596400] IGNORED
[ 6973.596407] IGNORED
[ 6973.596415] IGNORED
[ 6973.596422] IGNORED
[ 6973.596429] IGNORED
[ 6973.596436] IGNORED
[ 6973.596444] IGNORED
[ 6973.596451] IGNORED
[ 6973.596458] IGNORED
[ 6973.596465] IGNORED
[ 6973.596472] IGNORED
[ 6973.596479] IGNORED
[ 6973.596486] IGNORED
[ 6973.596493] IGNORED
[ 6973.596500] IGNORED
[ 6973.596508] IGNORED
[ 6973.596515] IGNORED
[ 6973.596522] IGNORED
[ 6973.596529] IGNORED
[ 6973.596536] IGNORED
[ 6973.596543] IGNORED
[ 6973.596550] IGNORED
[ 6973.596557] IGNORED
[ 6973.596565] IGNORED
[ 6973.596573] IGNORED
[ 6973.596580] IGNORED
[ 6973.596588] IGNORED
[ 6973.596595] IGNORED
[ 6973.596603] IGNORED
[ 6973.596610] IGNORED
[ 6973.596618] IGNORED
[ 6973.596625] IGNORED
[ 6973.596633] IGNORED
[ 6973.596640] IGNORED
[ 6973.596648] IGNORED
[ 6973.596655] IGNORED
[ 6973.596663] IGNORED
[ 6973.596670] IGNORED
[ 6973.596678] IGNORED
[ 6973.596685] IGNORED
[ 6973.596692] IGNORED
[ 6973.596699] IGNORED
[ 6973.596707] IGNORED
[ 6973.596714] IGNORED
[ 6973.596722] calling input_set_abs_params, code: 0, min: ffffff81,
max: 7f, fuzz: 0, flat: f
[ 6973.596724] Absolute.X
[ 6973.596732] calling input_set_abs_params, code: 1, min: ffffff81,
max: 7f, fuzz: 0, flat: f
[ 6973.596735] Absolute.Y
On Thu, 14 Jun 2007, Renato Golin wrote:
> Applied your patch and the log is below,
[...]
> [ 6973.596722] calling input_set_abs_params, code: 0, min: ffffff81,
> max: 7f, fuzz: 0, flat: f
> [ 6973.596724] Absolute.X
> [ 6973.596732] calling input_set_abs_params, code: 1, min: ffffff81,
> max: 7f, fuzz: 0, flat: f
> [ 6973.596735] Absolute.Y
Hi Renato,
this signalizes something is wrong between the device and HID layer - it
could be both the report descriptor of the device being wrong, or some bug
in hid-input that is not triggered by any other device.
Could you please send me the report descriptor of the device, so that I
could debug it locally here?
The report descriptor should be present in your HID_DEBUG dump, but you
don't seem to have provided in any of the previous mails. The relevant
line in dmesg should look similar to:
report descriptor (size 61, read 54) = 05 0b 09 05 a1 01 05 09 19 11 29 18
15 00 25 01 75 01 95 08 81 22 05 08 09 3a a1 02 05 09 19 11 29 17 15 00 25
01 75 01 95 07 b1 a2 c0 06 ff ff 09 01 15 00 25 01 75 01 95 01 b1 22 c0
Thanks,
--
Jiri Kosina
SUSE Labs
On Sat, 21 Jul 2007, Renato Golin wrote:
> sorry for the delay, below the report descriptor and attached is the
> full report when I've connected the joystick.
Hi Renato,
I guess I can now see the problem. The important parts of the dump are
[11165.496717] INPUT(6)[INPUT]
[11165.496722] Field(0)
[11165.496726] Physical(GenericDesktop.Pointer)
[11165.496733] Usage(1)
[11165.496738] GenericDesktop.X
[11165.496744] Logical Minimum(0)
[11165.496749] Logical Maximum(4096)
[11165.496754] Physical Minimum(0)
[11165.496758] Physical Maximum(4096)
[11165.496763] Report Size(16)
[11165.496767] Report Count(1)
[11165.496772] Report Offset(0)
[11165.496776] Flags( Variable Absolute )
[11165.496785] Field(1)
[11165.496788] Physical(GenericDesktop.Pointer)
[11165.496795] Usage(1)
[11165.496799] GenericDesktop.Y
[11165.496806] Logical Minimum(0)
[11165.496810] Logical Maximum(4096)
[11165.496815] Physical Minimum(0)
[11165.496819] Physical Maximum(4096)
[11165.496824] Report Size(16)
[11165.496828] Report Count(1)
[11165.496832] Report Offset(16)
[11165.496837] Flags( Variable Absolute )
... but later on we have
[11165.499897] OUTPUT(129)[OUTPUT]
[11165.499901] Field(0)
[11165.499904] Logical(00ff.0100)
[11165.499912] Usage(1)
[11165.499916] GenericDesktop.X
[11165.499923] Logical Minimum(-127)
[11165.499927] Logical Maximum(127)
[11165.499932] Physical Minimum(-10000)
[11165.499936] Physical Maximum(10000)
[11165.499941] Report Size(8)
[11165.499945] Report Count(1)
[11165.499949] Report Offset(0)
[11165.499954] Flags( Variable Absolute )
[11165.499962] Field(1)
[11165.499965] Logical(00ff.0100)
[11165.499972] Usage(1)
[11165.499976] GenericDesktop.Y
[11165.499983] Logical Minimum(-127)
[11165.499987] Logical Maximum(127)
[11165.499992] Physical Minimum(-10000)
[11165.499996] Physical Maximum(10000)
[11165.500001] Report Size(8)
[11165.500005] Report Count(1)
[11165.500010] Report Offset(8)
[11165.500014] Flags( Variable Absolute )
[11165.500022] FEATURE(11)[FEATURE]
As we call input_set_abs_params() both for input and output fields, I can
easily see how the range gets corrupted.
Renato, does force feedback work properly in Linux with this device? If
so, that would mean that the device has logical maximum and minimum for X
and Y axes different in input and output, and we would need to handle this
properly (we currently don't).
Thanks,
--
Jiri Kosina
SUSE Labs
On Fri, 10 Aug 2007, Jiri Kosina wrote:
> Renato, does force feedback work properly in Linux with this device? If
> so, that would mean that the device has logical maximum and minimum for
> X and Y axes different in input and output, and we would need to handle
> this properly (we currently don't).
Renato,
does the attached patch (against 2.6.23-rc2) fix the problem with axis
ranges for you please?
diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
index 8edbd30..97dbdb6 100644
--- a/drivers/hid/hid-input.c
+++ b/drivers/hid/hid-input.c
@@ -351,6 +351,12 @@ static void hidinput_configure_usage(struct hid_input *hidinput, struct hid_fiel
if (field->flags & HID_MAIN_ITEM_CONSTANT)
goto ignore;
+ if (field->report_type == HID_OUTPUT_REPORT &&
+ (usage->hid & HID_USAGE_PAGE) != HID_UP_LED) {
+ dbg_hid_line(" [non-LED output field ]");
+ goto ignore;
+ }
+
switch (usage->hid & HID_USAGE_PAGE) {
case HID_UP_UNDEFINED:
--
Jiri Kosina
SUSE Labs
On 10/08/07, Jiri Kosina <[email protected]> wrote:
> Renato, does force feedback work properly in Linux with this device? If
> so, that would mean that the device has logical maximum and minimum for X
> and Y axes different in input and output, and we would need to handle this
> properly (we currently don't).
Hi Jiri,
Makes total sense to me.
I've never tried force-feedback with it (or it never worked) as I
don't know which games support it (I thought none did).
I'll apply the patch and let you know.
thanks!
--renato
Reclaim your digital rights, eliminate DRM, learn more at
http://www.defectivebydesign.org/what_is_drm
On Fri, 10 Aug 2007, Renato Golin wrote:
> I've never tried force-feedback with it (or it never worked) as I don't
> know which games support it (I thought none did).
You can use fftest utility (part of input-utils) which can be used to test
FF capabilities of the device.
> I'll apply the patch and let you know.
Thanks,
--
Jiri Kosina
SUSE Labs
On 10/08/07, Jiri Kosina <[email protected]> wrote:
> does the attached patch (against 2.6.23-rc2) fix the problem with axis
> ranges for you please?
Hi Jiri,
fixes perfectly. But it probably breaks the output range and kills the
force-feedback.
I couldn't find fftest for debian (the package with jstest doesn't
have it) but I'll compile and run here to test.
thanks,
--renato
Reclaim your digital rights, eliminate DRM, learn more at
http://www.defectivebydesign.org/what_is_drm
On Sat, 11 Aug 2007, Renato Golin wrote:
> fixes perfectly. But it probably breaks the output range and kills the
> force-feedback.
Thanks for testing.
Force feedback functionality shouldn't be influenced in any means by this
patch - FF implementation doesn't care about the values of the
input_dev->abs{max,min,fuzz,flat}.
But it is questionable whether your joystick is fully compliant with PID
protocol or it implements some sort of vendor-specific one.
> I couldn't find fftest for debian (the package with jstest doesn't
> have it) but I'll compile and run here to test.
Thanks.
--
Jiri Kosina
SUSE Labs
On 11/08/07, Jiri Kosina <[email protected]> wrote:
> Force feedback functionality shouldn't be influenced in any means by this
> patch - FF implementation doesn't care about the values of the
> input_dev->abs{max,min,fuzz,flat}.
So it means the patch should work for all other joysticks as well?
That's good news... ;)
> But it is questionable whether your joystick is fully compliant with PID
> protocol or it implements some sort of vendor-specific one.
I wouldn't be surprised if it's vendor-specific, as their original
driver doesn't work quite well, I had to download a patched driver
from their website. Also, they seem to work it around (as I did) with
the auto-calibration.
Thanks for the help!
cheers,
--renato
Reclaim your digital rights, eliminate DRM, learn more at
http://www.defectivebydesign.org/what_is_drm