joydev.c and saitek cyborg evo force

joydev.c and saitek cyborg evo force

[Renato Golin]

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

Re: joydev.c and saitek cyborg evo force

[Renato Golin]

[-- Attachment #1: Type: text/plain, Size: 935 bytes --]

On 18/05/07, Renato Golin <rengolin@gmail.com> 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

[-- Attachment #2: joydev.patch --]
[-- Type: text/x-patch, Size: 1350 bytes --]

--- joydev.c	2007-04-12 18:15:56.000000000 +0100
+++ /usr/src/linux/drivers/input/joydev.c	2007-05-18 22:21:26.000000000 +0100
@@ -471,6 +471,7 @@
 	struct joydev *joydev;
 	struct class_device *cdev;
 	int i, j, t, minor;
+	int absmin, absmax;
 
 	for (minor = 0; minor < JOYDEV_MINORS && joydev_table[minor]; minor++);
 	if (minor == JOYDEV_MINORS) {
@@ -520,11 +521,20 @@
 			joydev->abs[i] = dev->abs[j];
 			continue;
 		}
+		/* Some joysticks don't report max/min correctly */
+		if (dev->abs[j] > dev->absmax[j] || dev->abs[j] < dev->absmin[j]) {
+			/* assume joystick is centered */
+			absmin = 0;
+			absmax = dev->abs[j] * 2;
+		} else {
+			absmin = dev->absmin[j];
+			absmax = dev->absmax[j];
+		}
 		joydev->corr[i].type = JS_CORR_BROKEN;
 		joydev->corr[i].prec = dev->absfuzz[j];
-		joydev->corr[i].coef[0] = (dev->absmax[j] + dev->absmin[j]) / 2 - dev->absflat[j];
-		joydev->corr[i].coef[1] = (dev->absmax[j] + dev->absmin[j]) / 2 + dev->absflat[j];
-		if (!(t = ((dev->absmax[j] - dev->absmin[j]) / 2 - 2 * dev->absflat[j])))
+		joydev->corr[i].coef[0] = (absmax + absmin) / 2 - dev->absflat[j];
+		joydev->corr[i].coef[1] = (absmax + absmin) / 2 + dev->absflat[j];
+		if (!(t = ((absmax - absmin) / 2 - 2 * dev->absflat[j])))
 			continue;
 		joydev->corr[i].coef[2] = (1 << 29) / t;
 		joydev->corr[i].coef[3] = (1 << 29) / t;

Re: joydev.c and saitek cyborg evo force

[Dmitry Torokhov]

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

Re: joydev.c and saitek cyborg evo force

[Jiri Kosina]

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

Re: joydev.c and saitek cyborg evo force

[Renato Golin]

On 21/05/07, Jiri Kosina <jkosina@suse.cz> 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

Re: joydev.c and saitek cyborg evo force

[Renato Golin]

On 21/05/07, Jiri Kosina <jkosina@suse.cz> 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

Re: joydev.c and saitek cyborg evo force

[Jiri Kosina]

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

Re: joydev.c and saitek cyborg evo force

[Renato Golin]

On 30/05/07, Jiri Kosina <jkosina@suse.cz> 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

Re: joydev.c and saitek cyborg evo force

[Jiri Kosina]

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

Re: joydev.c and saitek cyborg evo force

[Renato Golin]

On 30/05/07, Jiri Kosina <jkosina@suse.cz> 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

Re: joydev.c and saitek cyborg evo force

[Renato Golin]

On 30/05/07, Renato Golin <rengolin@gmail.com> wrote:
> On 30/05/07, Jiri Kosina <jkosina@suse.cz> 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

Re: joydev.c and saitek cyborg evo force

[Dmitry Torokhov]

On 5/30/07, Renato Golin <rengolin@gmail.com> 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

Re: joydev.c and saitek cyborg evo force

[Jiri Kosina]

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

Re: joydev.c and saitek cyborg evo force

[Jiri Kosina]

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

Re: joydev.c and saitek cyborg evo force

[Renato Golin]

On 31/05/07, Jiri Kosina <jkosina@suse.cz> 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

Re: joydev.c and saitek cyborg evo force

[Jiri Kosina]

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

Re: joydev.c and saitek cyborg evo force

[Renato Golin]

On 03/06/07, Jiri Kosina <jkosina@suse.cz> 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

Re: joydev.c and saitek cyborg evo force

[Jiri Kosina]

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

Re: joydev.c and saitek cyborg evo force

[Renato Golin]

On 04/06/07, Jiri Kosina <jkosina@suse.cz> 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

Re: joydev.c and saitek cyborg evo force

[Renato Golin]

On 04/06/07, Renato Golin <rengolin@gmail.com> 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

Re: joydev.c and saitek cyborg evo force

[Jiri Kosina]

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

Re: joydev.c and saitek cyborg evo force

[Renato Golin]

On 12/06/07, Jiri Kosina <jkosina@suse.cz> 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

Re: joydev.c and saitek cyborg evo force

[Dmitry Torokhov]

Hi Renato,

On 6/12/07, Renato Golin <rengolin@gmail.com> wrote:
> On 12/06/07, Jiri Kosina <jkosina@suse.cz> 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

Re: joydev.c and saitek cyborg evo force

[Renato Golin]

On 12/06/07, Dmitry Torokhov <dmitry.torokhov@gmail.com> 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

Re: joydev.c and saitek cyborg evo force

[Dmitry Torokhov]

On 6/12/07, Renato Golin <rengolin@gmail.com> wrote:
> On 12/06/07, Dmitry Torokhov <dmitry.torokhov@gmail.com> 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

Re: joydev.c and saitek cyborg evo force

[Jiri Kosina]

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);
+		}
 
 	}
 

Re: joydev.c and saitek cyborg evo force

[Renato Golin]

On 12/06/07, Jiri Kosina <jkosina@suse.cz> 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

Re: joydev.c and saitek cyborg evo force

[Jiri Kosina]

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

Re: joydev.c and saitek cyborg evo force

[Renato Golin]

[-- Attachment #1: Type: text/plain, Size: 3000 bytes --]

On 20/06/07, Jiri Kosina <jkosina@suse.cz> wrote:
> Could you please send me the report descriptor of the device, so that I
> could debug it locally here?

Hi Jiri,

sorry for the delay, below the report descriptor and attached is the
full report when I've connected the joystick.


report descriptor (size 851, read 851) =  05 01 09 04 a1 01 09 01 a1
00 85 06 09 30 15 00 26 00 10 35 00 46 00 10 75 10 95 01 81 02 09 31
81 02 05 02 09 bb 26 ff 00 46 ff 00 75 08 81 02 05 09 19 01 29 0c 25
01 45 01 75 01 95 0c 81 02 05 01 09 39 25 07 46 3b 01 55 00 65 44 75
04 95 01 81 42 65 00 05 02 09 ba 26 ff 00 46 ff 00 75 08 81 02 c0 05
0f 09 92 a1 02 85 02 09 a6 09 a4 09 a0 09 9f 25 01 45 00 75 01 95 04
81 02 75 04 95 01 81 03 09 22 75 07 25 09 81 02 09 94 75 01 25 01 81
02 75 08 81 03 c0 09 21 a1 02 85 0b 09 22 25 09 91 02 09 25 a1 02 09
26 09 30 09 32 09 31 09 33 09 34 09 40 09 41 15 01 25 08 91 00 c0 09
53 25 0c 75 05 91 02 09 56 15 00 25 01 75 01 91 02 09 55 a1 02 05 01
09 30 09 31 95 02 91 02 c0 05 0f 09 50 27 fe ff 00 00 47 fe ff 00 00
75 10 95 01 55 fd 66 01 10 91 02 55 00 65 00 09 57 26 ff 00 46 68 01
75 08 65 44 91 02 65 00 09 54 27 fe ff 00 00 47 fe ff 00 00 75 10 55
fd 66 01 10 91 02 55 00 65 00 09 58 a1 02 05 0a 09 01 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 09 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

cheers,
--renato

Reclaim your digital rights, eliminate DRM, learn more at
http://www.defectivebydesign.org/what_is_drm

[-- Attachment #2: joy-dmesg.log.gz --]
[-- Type: application/x-gzip, Size: 6261 bytes --]

Re: joydev.c and saitek cyborg evo force

[Jiri Kosina]

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

Re: joydev.c and saitek cyborg evo force

[Jiri Kosina]

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

Re: joydev.c and saitek cyborg evo force

[Renato Golin]

On 10/08/07, Jiri Kosina <jkosina@suse.cz> 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

Re: joydev.c and saitek cyborg evo force

[Jiri Kosina]

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

Re: joydev.c and saitek cyborg evo force

[Renato Golin]

On 11/08/07, Jiri Kosina <jkosina@suse.cz> 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

Re: joydev.c and saitek cyborg evo force

[Renato Golin]

On 10/08/07, Jiri Kosina <jkosina@suse.cz> 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

Re: joydev.c and saitek cyborg evo force

[Jiri Kosina]

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