Menu
▾
▴
linuxconsole-dev
|
From: Johann D. <jo...@Do...> - 2002-01-16 16:00:17
|
[cc to the linuxconsole list] (Bj|rn is currently working on support for force feedback for microsoft joysticks, and sent a patch to the usb-devel ML concerning the debugging system of the hid driver) On Wed, 16 Jan 2002, Bj|rn Augustsson wrote: > Quoting Johann Deneux <jo...@Do...>: > > On Tue, 15 Jan 2002, Bj|rn Augustsson wrote: > > > > > Hi! > > > > > > Here's a small patch against 2.4.18pre3 that > > > > > >[...] > > > > I do not have the sources of this version, but it seems that the 2.4.17 > > kernel included revision 1.8 of hid-core.c. The most up-to-date release > > can be found in the linuxconsole cvs. The revision here is 1.35 ! > > Unless patches went into 2.4.18pre3, it means you may be working on files > > that are 7 months old. Luckily, your changes are new, and I guess it could > > be interesting to include them anyway. > > Nope, 1.8 is what I've got here. > > I'll certainly look into that. Thanks for the heads up! > > I have quite a lot more written, but there's still some bugs and stuff > that I haven't implemented yet, so I split this part out. How far have you got ? Have you managed to make your joystick move yet ? Please also have a look at the input/event API. It would be nice if it was the one used to download effects to the device. -- Johann Deneux |
|
From: Bj|rn A. <d3a...@dt...> - 2002-01-16 16:39:06
|
Quoting Johann Deneux <jo...@Do...>: > [cc to the linuxconsole list] > (Bj|rn is currently working on support for force feedback for microsoft > joysticks, and sent a patch to the usb-devel ML concerning the debugging > system of the hid driver) > > On Wed, 16 Jan 2002, Bj|rn Augustsson wrote: > > > Nope, 1.8 is what I've got here. > > > > I'll certainly look into that. Thanks for the heads up! > > > > I have quite a lot more written, but there's still some bugs and stuff > > that I haven't implemented yet, so I split this part out. > > How far have you got ? Have you managed to make your joystick move yet ? > Please also have a look at the input/event API. It would be nice if it was > the one used to download effects to the device. No, I haven't, but I'm close. (I think!) OK, longish status update time: I am using the event API. The joystick now reports almost all of it's features to the event stuff, but actually writing stuff to the it doesn't work yet. I haven't started on uploading effects, but I thought I had the "set device gain" thing working last night, but I ran into problems where this happens: Jan 16 03:49:06 localhost kernel: Setting device gain to 127, span = 255 Jan 16 03:49:06 localhost kernel: hid-debug: input PhysicalInterfaceDevice.Device_Gain = 127 Jan 16 03:49:06 localhost kernel: hid-core.c: ctrl urb status -32 received -32 is EPIPE, and I'll have to look into why that happens a bit later today. The joystick actually seems to be a proper PID device, so that's what I'm aiming for, and trying not to hard-code anything MS-FF2-specific in there. There's a few policy type things to consider. There's an Usage called PhysicalInterfaceDevice.Safety_Switch, which is a switch that notices if you hold the joystick or not (and if you let go, it turns the forces off). Since the existing HID-input "parser" reports every one-bit input usage as a button, this gets reported that way (except it's inverted, if you let go of the stick, it goes 0 -> 1). It's not really a button, but it could be useful to a game anyway. You could bind pause to it for example, or something. Do I report it to the API as a button, or do I add a new bit about this somewhere? Also, HID devices (can) have physical units bound to them, as in "This axis measues rotation, +- 30 degrees, 8bit resolution." There is no way for an app to get this information thru the input API, and it should probably be added at some point. It's not critical for game controllers, but other apps might want that information. (But as I said, I'll have to look at the current hid code, as I've been working against what's in 2.4.18pre3. Maybe things have changed.) /August. -- Wrong on most accounts. const Foo *foo; and Foo const *foo; mean the same: foo being a pointer to const Foo. const Foo const *foo; would mean the same but is illegal (double const). You are confusing this with Foo * const foo; and const Foo * const foo; respectively. -David Kastrup, comp.os.linux.development.system |
|
From: Johann D. <jo...@Do...> - 2002-01-16 19:17:00
|
On Wed, 16 Jan 2002, Bj|rn Augustsson wrote: > > How far have you got ? Have you managed to make your joystick move yet ? > > Please also have a look at the input/event API. It would be nice if it was > > the one used to download effects to the device. > > No, I haven't, but I'm close. (I think!) Great ! > > OK, longish status update time: > > [...] > > There's a few policy type things to consider. There's an Usage called > PhysicalInterfaceDevice.Safety_Switch, which is a switch that notices if > you hold the joystick or not (and if you let go, it turns the forces > off). Since the existing HID-input "parser" reports every one-bit input > usage as a button, this gets reported that way (except it's inverted, if > you let go of the stick, it goes 0 -> 1). > > It's not really a button, but it could be useful to a game anyway. You > could bind pause to it for example, or something. Do I report it to the > API as a button, or do I add a new bit about this somewhere? I guess by the name BTN_DEAD (0x12f) could be used for that, but as I said, that's only a guess. -- Johann Deneux |
|
From: Vojtech P. <vo...@su...> - 2002-01-18 21:46:32
|
On Wed, Jan 16, 2002 at 08:16:50PM +0100, Johann Deneux wrote: > On Wed, 16 Jan 2002, Bj|rn Augustsson wrote: > > > > How far have you got ? Have you managed to make your joystick move yet ? > > > Please also have a look at the input/event API. It would be nice if it was > > > the one used to download effects to the device. > > > > No, I haven't, but I'm close. (I think!) > > Great ! > > > > > OK, longish status update time: > > > > [...] > > > > There's a few policy type things to consider. There's an Usage called > > PhysicalInterfaceDevice.Safety_Switch, which is a switch that notices if > > you hold the joystick or not (and if you let go, it turns the forces > > off). Since the existing HID-input "parser" reports every one-bit input > > usage as a button, this gets reported that way (except it's inverted, if > > you let go of the stick, it goes 0 -> 1). > > > > It's not really a button, but it could be useful to a game anyway. You > > could bind pause to it for example, or something. Do I report it to the > > API as a button, or do I add a new bit about this somewhere? > > I guess by the name BTN_DEAD (0x12f) could be used for that, but as I > said, that's only a guess. I-force has this as well (at least the WingMan Force has it). -- Vojtech Pavlik SuSE Labs |
|
From: Vojtech P. <vo...@su...> - 2002-01-18 21:46:02
|
On Wed, Jan 16, 2002 at 05:38:56PM +0100, Bj|rn Augustsson wrote: > Quoting Johann Deneux <jo...@Do...>: > > [cc to the linuxconsole list] > > (Bj|rn is currently working on support for force feedback for microsoft > > joysticks, and sent a patch to the usb-devel ML concerning the debugging > > system of the hid driver) > > > > On Wed, 16 Jan 2002, Bj|rn Augustsson wrote: > > > > > Nope, 1.8 is what I've got here. > > > > > > I'll certainly look into that. Thanks for the heads up! > > > > > > I have quite a lot more written, but there's still some bugs and stuff > > > that I haven't implemented yet, so I split this part out. > > > > How far have you got ? Have you managed to make your joystick move yet ? > > Please also have a look at the input/event API. It would be nice if it was > > the one used to download effects to the device. > > No, I haven't, but I'm close. (I think!) > > OK, longish status update time: > > I am using the event API. The joystick now reports almost all of it's > features to the event stuff, but actually writing stuff to the it > doesn't work yet. I haven't started on uploading effects, but I thought > I had the "set device gain" thing working last night, but I ran into > problems where this happens: > > Jan 16 03:49:06 localhost kernel: Setting device gain to 127, span = 255 > Jan 16 03:49:06 localhost kernel: hid-debug: input PhysicalInterfaceDevice.Device_Gain = 127 > Jan 16 03:49:06 localhost kernel: hid-core.c: ctrl urb status -32 received > > -32 is EPIPE, and I'll have to look into why that happens a bit later today. > > The joystick actually seems to be a proper PID device, so that's what > I'm aiming for, and trying not to hard-code anything MS-FF2-specific in > there. > > There's a few policy type things to consider. There's an Usage called > PhysicalInterfaceDevice.Safety_Switch, which is a switch that notices if > you hold the joystick or not (and if you let go, it turns the forces > off). Since the existing HID-input "parser" reports every one-bit input > usage as a button, this gets reported that way (except it's inverted, if > you let go of the stick, it goes 0 -> 1). > > It's not really a button, but it could be useful to a game anyway. You > could bind pause to it for example, or something. Do I report it to the > API as a button, or do I add a new bit about this somewhere? It's already defined: BTN_DEAD (The 'deadman' switch). > Also, HID devices (can) have physical units bound to them, as in "This > axis measues rotation, +- 30 degrees, 8bit resolution." There is no way > for an app to get this information thru the input API, and it should > probably be added at some point. It's not critical for game controllers, > but other apps might want that information. Yes, we may later add some IOCTLs to report and structures to hold that information. > (But as I said, I'll have to look at the current hid code, as I've been > working against what's in 2.4.18pre3. Maybe things have changed.) There is a lot of differences, namely in the control URB handling. -- Vojtech Pavlik SuSE Labs |
|
From: Bj|rn A. <d3a...@dt...> - 2002-01-18 23:58:27
|
Quoting Vojtech Pavlik <vo...@su...>:
> On Wed, Jan 16, 2002 at 05:38:56PM +0100, Bj|rn Augustsson wrote:
> >
> > OK, longish status update time:
> >
> > It's not really a button, but it could be useful to a game anyway. You
> > could bind pause to it for example, or something. Do I report it to the
> > API as a button, or do I add a new bit about this somewhere?
>
> It's already defined: BTN_DEAD (The 'deadman' switch).
Aha! Good to know. (I thought it meant something like a dead key on a
keyboard...)
Good, that solves that.
> > Also, HID devices (can) have physical units bound to them, as in "This
> > axis measues rotation, +- 30 degrees, 8bit resolution." There is no way
> > for an app to get this information thru the input API, and it should
> > probably be added at some point. It's not critical for game controllers,
> > but other apps might want that information.
>
> Yes, we may later add some IOCTLs to report and structures to hold that
> information.
OK.
> > (But as I said, I'll have to look at the current hid code, as I've been
> > working against what's in 2.4.18pre3. Maybe things have changed.)
>
> There is a lot of differences, namely in the control URB handling.
OK, I got the new code from CVS (Actually, that crashed when init
started on my box, so I went with Johanns input-only patch against
2.4.17 instead) and merged with it.
It doesn't help. I have a few questions:
The joystick has an interrupt output endpoint. The HID spec says an
output pipe is optional, and that if one exists, output reports are to
be sent over it. I can't see any initialization of output pipes in the
HID code though, nor data structures in the hid_device struct.
Question #1: Are there any HID devices with output interrupt pipes that
work with this code?
If I understand this correctly I'll need another urb and some more
stuff. I'll also rename the input URB to add some clarity there.
Second problem. When hid_probe() gets called, often the input pipe is
aleady stalled. (And if it isn't, it stalls after the first call to
hid_submit_report.) Attemting to get any input reports results in
"hid-core.c: ctrl urb status -32 received" messages.
Question #2: Under what circumstances do pipes stall? I've read the
relevant parts of the USB spec, but I'm not sure about
the non-error stalls.
Question #3: How can I clear the stall? Or rather what actually happens
when I do? I tried using usb_clear_halt() from
hid_init_reports() and that wedged the kernel.
I'm guessing I can't do that when TASK_UNINTERRUPTIBLE?
Oh yeah, and
Question #4: Do I send patches here or to usb-devel or where? I'm
confused...
Thanks,
/August.
--
Wrong on most accounts. const Foo *foo; and Foo const *foo; mean the same: foo
being a pointer to const Foo. const Foo const *foo; would mean the same but is
illegal (double const). You are confusing this with Foo * const foo; and const
Foo * const foo; respectively. -David Kastrup, comp.os.linux.development.system
|
|
From: Vojtech P. <vo...@su...> - 2002-01-20 18:28:45
|
On Sat, Jan 19, 2002 at 12:58:16AM +0100, Bj|rn Augustsson wrote: > Quoting Vojtech Pavlik <vo...@su...>: > > On Wed, Jan 16, 2002 at 05:38:56PM +0100, Bj|rn Augustsson wrote: > > > > > > OK, longish status update time: > > > > > > It's not really a button, but it could be useful to a game anyway. You > > > could bind pause to it for example, or something. Do I report it to the > > > API as a button, or do I add a new bit about this somewhere? > > > > It's already defined: BTN_DEAD (The 'deadman' switch). > > Aha! Good to know. (I thought it meant something like a dead key on a > keyboard...) > Good, that solves that. > > > > Also, HID devices (can) have physical units bound to them, as in "This > > > axis measues rotation, +- 30 degrees, 8bit resolution." There is no way > > > for an app to get this information thru the input API, and it should > > > probably be added at some point. It's not critical for game controllers, > > > but other apps might want that information. > > > > Yes, we may later add some IOCTLs to report and structures to hold that > > information. > > OK. > > > > (But as I said, I'll have to look at the current hid code, as I've been > > > working against what's in 2.4.18pre3. Maybe things have changed.) > > > > There is a lot of differences, namely in the control URB handling. > > OK, I got the new code from CVS (Actually, that crashed when init > started on my box, so I went with Johanns input-only patch against > 2.4.17 instead) and merged with it. I've sent some newer input patches to the list, you may as well try those or 2.4.2-dj4 when it comes out (it'll contain all the newest input stuff). > It doesn't help. I have a few questions: > > The joystick has an interrupt output endpoint. The HID spec says an > output pipe is optional, and that if one exists, output reports are to > be sent over it. I can't see any initialization of output pipes in the > HID code though, nor data structures in the hid_device struct. The output pipe isn't implememented. > Question #1: Are there any HID devices with output interrupt pipes that > work with this code? Yes, and no. The WingMan ForceFeedback Mouse is known to work, but without FF. But the driver does communication with it over the control pipe and it works. > If I understand this correctly I'll need another urb and some more > stuff. I'll also rename the input URB to add some clarity there. Yes, this is reasonable. You also should modify the report read/write queue to use the output pipe in cas it's present. > Second problem. When hid_probe() gets called, often the input pipe is > aleady stalled. (And if it isn't, it stalls after the first call to > hid_submit_report.) Attemting to get any input reports results in > "hid-core.c: ctrl urb status -32 received" messages. This isn't the input pipe, this is the control pipe. The stall is bad and probably means we did something the joystick didn't like. > Question #2: Under what circumstances do pipes stall? I've read the > relevant parts of the USB spec, but I'm not sure about > the non-error stalls. I don't think it can happen in a non-error case in HID. > Question #3: How can I clear the stall? Or rather what actually happens > when I do? I tried using usb_clear_halt() from > hid_init_reports() and that wedged the kernel. > I'm guessing I can't do that when TASK_UNINTERRUPTIBLE? No idea, never tried this, ask the USB guys. > Oh yeah, and > > Question #4: Do I send patches here or to usb-devel or where? I'm > confused... Here. Although this is USB code, the main repository for it is here. -- Vojtech Pavlik SuSE Labs |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X