linuxconsole-dev

Re: Custom-shaped periodic effects in force feedback

[Vojtech P. <vo...@su...>]

On Mon, Jan 21, 2002 at 11:28:33PM +0100, Johann Deneux wrote:

> The parameter block ioctl approach rises the following issues:
> - One parameter block may be used by several effects. One may see that as
> a feature, as it might allow for some memory to be saved. I am not
> convinced it would be very useful, though.
> - What should be put into parameters, and what should be put into the core
> of the effect ? For example, the direction of a constant effect is encoded
> in the core of the effect in the I-Force protocol, while the amplitude is
> stored in a parameter block. It seems PID does the same. What if another
> protocol chooses to put the direction into parameter blocks ?

We have seven force feedback protocols so far:

1) Rumble (in many different pads)
2) I-Force 1.0 (in the CH Products FF stick, mostly similar to 2.0)
3) I-Force 2.0 (most common)
4) MS MIDI-based FF (very similar to PID)
5) PID (New MS devices, and the Logitech WingMan ForceFeedback mouse)
6) Logitech's new host-controlled FF (basically I-Force done mostly
   on the host CPU)
7) Logitech's new iFeel mice (host controlled vibration)

I think the current API still wraps well enough around them, so that's
OK. Just keep in mind that it should be generic enough, but never too
generic. Too generic things become unusable.

-- 
Vojtech Pavlik
SuSE Labs

Logitech Wingman precision usb

[<LU...@te...>]

Thxs for your interest.

i send you 3 files, messages, ksyms, lsmod, they are all the output, 
because they are many lines that could interest you. i have few modules 
loaded for this try, but if you want me to reduce to the max those tell 
me and i will send you again the files.

Bye.

Re: Hi

[Johann D. <jo...@do...>]

On Thu, 7 Feb 2002, Luciano Campal Vazquez wrote:

> 
> I have just buy a Logitech Wingman Precision USB, and i can not make it work on linux.
> 
> i have a debian woody, with 2.4.17 kernel, and all usb support in modules.
> 
> kernel installs usbcore, and then i modprobe usb-uhci after that the gamepad is recognise
> but it doesn't load automatically a driver, it says no driver claims the device but it loads input module, so i try to load the driver manually i do
> 
> modprobe joydev
> 
> it gaves a seg fault and after that it seems to lock, doing a lsmod it appears 

modprobe segfaults ? That should not happen. Check if there is a kernel
oops in your log files. If that's the case, please tell us (using
ksymoops). Do not also forget to send us the list of modules inserted when
the bug occurs.

-- 
Johann Deneux

Hi

[Luciano C. V. <lu...@te...>]

I have just buy a Logitech Wingman Precision USB, and i can not make it work on linux.

i have a debian woody, with 2.4.17 kernel, and all usb support in modules.

kernel installs usbcore, and then i modprobe usb-uhci after that the gamepad is recognise
but it doesn't load automatically a driver, it says no driver claims the device but it loads input module, so i try to load the driver manually i do

modprobe joydev

it gaves a seg fault and after that it seems to lock, doing a lsmod it appears 

joydev	(size)	1	(Initializing)

and the device seems to be there i can do cat /dev/input/js0 and jstest --normal /dev/input/js0 puts some line indicating

jstest --normal /dev/input/js0
Joystick (Logitech Logitech) has 3 axes and 6 buttons. Driver version is 2.1.0.
Testing ... (interrupt to exit)
Axes:  0:     0  1:     0  2:     0 Buttons:  0:off  1:off  2:off  3:off  4:off 
Axes:  0:     0  1:     0  2:     0 Buttons:  0:off  1:off  2:off  3:off  4:off 
Axes:  0:     0  1:     0  2:     0 Buttons:  0:off  1:off  2:off  3:off  4:off 
Axes:  0:     0  1:     0  2:     0 Buttons:  0:off  1:off  2:off  3:off  4:off 
Axes:  0:     0  1:     0  2:     0 Buttons:  0:off  1:off  2:off  3:off  4:off 
Axes:  0:     0  1:     0  2:     0 Buttons:  0:off  1:off  2:off  3:off  4:off 
Axes:  0:-32767  1:     0  2:     0 Buttons:  0:off  1:off  2:off  3:off  4:off 
Axes:  0:-32767  1:-32767  2:     0 Buttons:  0:off  1:off  2:off  3:off  4:off 
Axes:  0:-32767  1:-32767  2:     0 Buttons:  0:off  1:off  2:off  3:off  4:off  
5:off 

Hope you could help me play with my gamepad ni linux.
I can do some beta test if you like.

Thxs for your patience.

Re: [gpm]Reworking the selection API and moving it to userspace (gpm)?

[Nico S. <nic...@pc...>]

On Wed, Feb 06, 2002 at 09:24:15PM +0100 Petr Baudis put his fingers on the=
 keyboard an wrote:
> Hello,
>=20
>   About June 2001, in the era of 2.4.7 kernel, there occured a patch on L=
KML
> (by Salvador Eduardo Tropea <sal...@in...>), which improved the a=
ctual
> selection API of kernel to allow applications to get the content of the
> selection buffer etc. However, James Simmons said that he will be working=
 on
> this for 2.5 and move it to userspace completely, reworking gpm.

Possibly I got a mail about that, but as I have a huge backlog, I didn't
read it.=20
Possibly I have never heard about that and don't know anything particular a=
bout
it.
But in fact, improving something is generally good and if I have/get some
information about that, we could include it in gpm.=20

> [..], I would like to ask if there's any movement in this issue.

Not here.

> I would be even willing to help, > if possible :).

Sounds good, so you're the person wrinting the patch for gpm ;)

--=20
{Greetings,Gruss},
Nico Schottelius

I am some kind of busy -
Do not expect an answer within 24 hours.
Instead use the telephon: +49 (0) 173 - 750 7022.

Reworking the selection API and moving it to userspace (gpm)?

[Petr B. <pa...@pa...>]

Hello,

  About June 2001, in the era of 2.4.7 kernel, there occured a patch on LKML
(by Salvador Eduardo Tropea <sal...@in...>), which improved the actual
selection API of kernel to allow applications to get the content of the
selection buffer etc. However, James Simmons said that he will be working on
this for 2.5 and move it to userspace completely, reworking gpm.

  Nevertheless, I didn't saw a notice about this at all since then - there's no
metion about this on linuxconsole's project homepage, in the 2.5 todo list nor
anywhere else - and as I'm looking forward for this change a lot, I would like
to ask if there's any movement in this issue. I would be even willing to help,
if possible :).

  Kind regards,

-- 

				Petr "Pasky" Baudis

* UN*X programmer && admin         * IPv6 guy (XS26 co-coordinator)
* elinks maintainer                * FreeCiv AI hacker
* IRCnet local operator
.
"Something has fallen on us that falls very seldom on men; perhaps the worst
thing that can fall on them.
We have found the truth; and the truth makes no sense."
		-- Father Brown
.
Public PGP key && geekcode && homepage: http://pasky.ji.cz/~pasky/

IFeel support

[Johann D. <jo...@do...>]

Hi,

Does anyone have an IFeel mouse at hand here ? Information about the
protocol can be found here:
http://moore.cx/out/ifeel/

If no one with an IFeel mouse feels like starting to implement a driver
using the information available above, I may well volunteer to do it, but
that means I would need to buy such a mouse.

-- 
Johann Deneux

Re: input.h changes

[Johann D. <jo...@do...>]

On Mon, 4 Feb 2002, Bj|rn Augustsson wrote:

> Quoting Johann Deneux <jo...@Do...>:
> > On Thu, 31 Jan 2002, Bj|rn Augustsson wrote:
> > > 
> > > According to the PID spec (5.9), it means "Start the effect specified by
> > > the Effect Handle and stop all other effects." As opposed to "Start" which
> > > means "Start the effect specified by the Effect Handle". 
> > 
> > The iforce driver allows several processes to access the device
> > concurrently. However, one process cannot control effects it does not
> > own.
> 
> Uh, several processes concurrently playing effects on one FF device?
> Maybe I'm just being unimaginative, but can you give an example of 
> when that would be useful?  

It was actually Vojtech's idea. His point was that you may want
to use (for example) vibrating effects coupled with alarm clocks. This
does make sense when used with mice, for example.
In that case, you would have X accessing the mouse in read mode, and
ff-enabled applications would also access it (in "write" mode).
You may object that we could as well allow only X to access the device,
and add a force feedback extension to X. That would also be a solution,
but not as good as the first one, IMO.

-- 
Johann Deneux

Re: input.h changes

[Bj|rn A. <d3a...@dt...>]

Quoting Johann Deneux <jo...@Do...>:
> On Thu, 31 Jan 2002, Bj|rn Augustsson wrote:
> > 
> > According to the PID spec (5.9), it means "Start the effect specified by
> > the Effect Handle and stop all other effects." As opposed to "Start" which
> > means "Start the effect specified by the Effect Handle". 
> 
> The iforce driver allows several processes to access the device
> concurrently. However, one process cannot control effects it does not
> own.

Uh, several processes concurrently playing effects on one FF device?
Maybe I'm just being unimaginative, but can you give an example of 
when that would be useful?  

/August, puzzled.
-- 
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

Re: input.h changes

[Bj|rn A. <d3a...@dt...>]

Quoting Johann Deneux <jo...@Do...>:
> On Fri, 1 Feb 2002, Vojtech Pavlik wrote:
> > On Thu, Jan 31, 2002 at 10:44:28PM +0100, Johann Deneux wrote:
> > > On Thu, 31 Jan 2002, Vojtech Pavlik wrote:
> > > 
> > > For FF_ABS, maybe, but FF_BTN is still needed. It is used to trigger
> > > effects when a button is pushed.
> > 
> > Is there ever any difference between EV_KEY defined buttons and those in
> > FF_BTN? Just checking ...
> > 
> No, you are right, a button is a button, no need to have both regular
> buttons and force-feedback buttons.

Well, again I'm at work and haven't got the spec here, but I think it
says that not all buttons are neccessarily available as FF-trigger
buttons. On my joystick they all are, and while that's not exactly a
statistically significant sample, I can't really see any reason not to
have all of them FF-capable.

Ah, The deadman grip, if reported as a button, shouldn't be FF-capable.
(It kills all effects if you drop the stick.)

BTW, if anyone has a MS FF racing wheel, I'd be a happy man if they
would send me the report descriptor for it.

/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

Re: input.h changes

[Johann D. <jo...@Do...>]

On Fri, 1 Feb 2002, Vojtech Pavlik wrote:

> On Thu, Jan 31, 2002 at 10:44:28PM +0100, Johann Deneux wrote:
> > On Thu, 31 Jan 2002, Vojtech Pavlik wrote:
> > 
> > > 
> > > Looks OK. Maybe we should get rid of FF_ABS then? Maybe FF_BTN as well?
> > > 
> > 
> > For FF_ABS, maybe, but FF_BTN is still needed. It is used to trigger
> > effects when a button is pushed.
> 
> Is there ever any difference between EV_KEY defined buttons and those in
> FF_BTN? Just checking ...
> 
No, you are right, a button is a button, no need to have both regular
buttons and force-feedback buttons.

-- 
Johann Deneux

Re: input.h changes

[Vojtech P. <vo...@su...>]

On Thu, Jan 31, 2002 at 10:44:28PM +0100, Johann Deneux wrote:
> On Thu, 31 Jan 2002, Vojtech Pavlik wrote:
> 
> > 
> > Looks OK. Maybe we should get rid of FF_ABS then? Maybe FF_BTN as well?
> > 
> 
> For FF_ABS, maybe, but FF_BTN is still needed. It is used to trigger
> effects when a button is pushed.

Is there ever any difference between EV_KEY defined buttons and those in
FF_BTN? Just checking ...

-- 
Vojtech Pavlik
SuSE Labs

Re: input.h changes

[Johann D. <jo...@Do...>]

On Thu, 31 Jan 2002, Vojtech Pavlik wrote:

> 
> Looks OK. Maybe we should get rid of FF_ABS then? Maybe FF_BTN as well?
> 

For FF_ABS, maybe, but FF_BTN is still needed. It is used to trigger
effects when a button is pushed.

-- 
Johann Deneux

Re: input.h changes

[Johann D. <jo...@Do...>]

On Thu, 31 Jan 2002, Bj|rn Augustsson wrote:

> 
> According to the PID spec (5.9), it means "Start the effect specified by
> the Effect Handle and stop all other effects." As opposed to "Start" which
> means "Start the effect specified by the Effect Handle". 

The iforce driver allows several processes to access the device
concurrently. However, one process cannot control effects it does not
own.

-- 
Johann Deneux

Re: input.h changes

[Bj|rn A. <d3a...@dt...>]

Quoting Johann Deneux <jo...@Do...>:
> On Thu, 31 Jan 2002, Bj|rn Augustsson wrote:
> > Quoting Johann Deneux <jo...@Do...>:
> > > Note the arrays. There is one value for each axis. The axis mumber has
> > > become useless and has therefore been droped.
> > 
> > I wondered about this part when reading the spec. Why two axes? Why not
> > 3? Or "n"?  This seems a bit joystick-centered, I can easily imagine a
> 
> Indeed. Then we would need a list of (parameter/axis id) pairs.
> That sounds doable.

Yes. On the other hand, it's difficult to tell if it's ever going to be
needed... Hmm. I'd like to cheat again, and have a look at what MS
DirectInput does.

> > How would you feel about renaming shape to envelope? It fits the PID
> > spec, and it has some precedent from audio waveforms.
> 
> Ok. I can also change the ff_interactive_effect to ff_condition_effect,
> if you prefer.

OK, that'd be good too.

> > Antother thing we might want to add to the API is supporting the "Start
> > Solo" action on an effect, in addition to the "start" and "stop" that we
> 
> What do you mean ? One can only start one effect at a time ? Or do you
> mean to play an effect to play once ? That's already supported.

According to the PID spec (5.9), it means "Start the effect specified by
the Effect Handle and stop all other effects." As opposed to "Start" which
means "Start the effect specified by the Effect Handle". 

/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

Re: input.h changes

[Vojtech P. <vo...@su...>]

On Thu, Jan 31, 2002 at 12:06:40AM +0100, Johann Deneux wrote:
> Hi,
> 
> I am changing the ff_effect struct. I went for the 1-parameter-1-effect
> scheme (actually it's really (1,2)-parameter(s)-1-effect).
> 
> New effect types:
> * FF_DAMPER
> This effect really is the former FF_FRICTION.
> * FF_INERTIA
> * FF_RAMP
> Note that this effect is not periodic. Reasons:
>  1. PID does not define it as a periodic effect
>  2. A periodic ramp is just a sawtooth up or down
> I wonder if we still need the FF_CONSTANT, as it's just a special case of
> FF_RAMP.

There might be a device which doesn't support RAMP, but does support CONSTANT.

> * FF_CUSTOM
> It's not new actually. I just did not remember it was there.
> 
> New or changed structures:
> * Ramp effects
> struct ff_ramp_effect {
>         _s16 start_level;
>         _s16 end_level;
>         struct ff_shape shape;
> }
> * Friction
> No new structure. We can use the ff_interactive, according to PID. What is
> its meaning is still not clear. I would guess the following:
> force = f(position, direction)
> force.direction = -direction
> force.magnitude = p(position), p being the function described at page 12.
> The ff_interactive_effect structure has changed:
> struct ff_interactive_effect {
>         __u16 right_saturation[2]; /* Max level when joystick is on the
> right */
>         __u16 left_saturation[2];  /* Max level when joystick in on the
> left */
> 
>         __s16 right_coeff[2];   /* Indicates how fast the force grows when
> the
>                                    joystick moves to the right */
>         __s16 left_coeff[2];    /* Same for left side */
> 
>         __u16 deadband[2];      /* Size of area where no force is produced
> */
>         __s16 center[2];        /* Position of dead zone */
> 
> };
> 
> Note the arrays. There is one value for each axis. The axis mumber has
> become useless and has therefore been droped.
> 
> * ff_periodic_effect:
> struct ff_periodic_effect {
>         __u16 waveform;         /* Kind of wave (sine, square...) */
>         __u16 period;           /* in ms */
>         __s16 magnitude;        /* Peak value */
>         __s16 offset;           /* Mean value of wave (roughly) */
>         __u16 phase;            /* 'Horizontal' shift */
> 
>         struct ff_shape shape;
> 
> /* Only used if waveform == FF_CUSTOM */
>         __u32 custom_len;       /* Number of samples  */
>         __s16 *custom_data;     /* Buffer of samples */
> /* Note: the data pointed by custom_data is copied by the driver. You can
>  * therefore dispose of the memory after the upload/update */
> };
> 
> The _u32 for the number of samples is a bit oversized, maybe.
> 
> 
> I think that's all for now. Comments and critics welcome.

Looks OK. Maybe we should get rid of FF_ABS then? Maybe FF_BTN as well?

-- 
Vojtech Pavlik
SuSE Labs

Re: input.h changes

[Johann D. <jo...@Do...>]

On Thu, 31 Jan 2002, Bj|rn Augustsson wrote:

> Quoting Johann Deneux <jo...@Do...>:
> > Hi,
> > 
> > I am changing the ff_effect struct. I went for the 1-parameter-1-effect
> > scheme (actually it's really (1,2)-parameter(s)-1-effect).
> 
> Good. 
> 
> >         __u16 right_saturation[2]; /* Max level when joystick is on the
> > right */
> >         __u16 left_saturation[2];  /* Max level when joystick in on the
> > left */
> > 
> >  [...]
> > Note the arrays. There is one value for each axis. The axis mumber has
> > become useless and has therefore been droped.
> 
> I wondered about this part when reading the spec. Why two axes? Why not
> 3? Or "n"?  This seems a bit joystick-centered, I can easily imagine a

Indeed. Then we would need a list of (parameter/axis id) pairs.
That sounds doable.

> spaceball-like device with FF in all 3 axis. (And rotation This seems a
> bit joystick-centered, I can easily imagine a spaceball-like device 
> with FF in all 3 axis. (And rotational around all as well)
> 
> Oh well.
> 
> >         struct ff_shape shape;
> 
> How would you feel about renaming shape to envelope? It fits the PID
> spec, and it has some precedent from audio waveforms.

Ok. I can also change the ff_interactive_effect to ff_condition_effect,
if you prefer.

>  
> > The _u32 for the number of samples is a bit oversized, maybe.
>  
> Well, 16 bits could be to small in some future, so I think we should go
> with 32.
>  
> Antother thing we might want to add to the API is supporting the "Start
> Solo" action on an effect, in addition to the "start" and "stop" that we

What do you mean ? One can only start one effect at a time ? Or do you
mean to play an effect to play once ? That's already supported.


-- 
Johann Deneux

Re: input.h changes

[Bj|rn A. <d3a...@dt...>]

Quoting Johann Deneux <jo...@Do...>:
> Hi,
> 
> I am changing the ff_effect struct. I went for the 1-parameter-1-effect
> scheme (actually it's really (1,2)-parameter(s)-1-effect).

Good. 

>         __u16 right_saturation[2]; /* Max level when joystick is on the
> right */
>         __u16 left_saturation[2];  /* Max level when joystick in on the
> left */
> 
>  [...]
> Note the arrays. There is one value for each axis. The axis mumber has
> become useless and has therefore been droped.

I wondered about this part when reading the spec. Why two axes? Why not
3? Or "n"?  This seems a bit joystick-centered, I can easily imagine a
spaceball-like device with FF in all 3 axis. (And rotation This seems a
bit joystick-centered, I can easily imagine a spaceball-like device 
with FF in all 3 axis. (And rotational around all as well)

Oh well.

>         struct ff_shape shape;

How would you feel about renaming shape to envelope? It fits the PID
spec, and it has some precedent from audio waveforms.
 
> The _u32 for the number of samples is a bit oversized, maybe.
 
Well, 16 bits could be to small in some future, so I think we should go
with 32.
 
Antother thing we might want to add to the API is supporting the "Start
Solo" action on an effect, in addition to the "start" and "stop" that we
already have. I'm at work now and the spec is at home, but it's in there
somewhere.

/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

Re: BUG when USB devices disconnected ?

[Johann D. <jo...@Do...>]

On Tue, 29 Jan 2002, Vojtech Pavlik wrote:

> > Can someone try to reproduce the bug with another USB device ?
> > (Advice: sync your disks before! The crash is actually a complete freeze)
> 
> It works for me. Evtest just reports:
> 
> evtest: error reading: No such device
> 
> and exits just OK.
> 

With my latest changes to iforce, that's now what I get. However, I keep
getting crashes when or shortly after reconnecting the device :(

-- 
Johann Deneux

input.h changes

[Johann D. <jo...@Do...>]

Hi,

I am changing the ff_effect struct. I went for the 1-parameter-1-effect
scheme (actually it's really (1,2)-parameter(s)-1-effect).

New effect types:
* FF_DAMPER
This effect really is the former FF_FRICTION.
* FF_INERTIA
* FF_RAMP
Note that this effect is not periodic. Reasons:
 1. PID does not define it as a periodic effect
 2. A periodic ramp is just a sawtooth up or down
I wonder if we still need the FF_CONSTANT, as it's just a special case of
FF_RAMP.
* FF_CUSTOM
It's not new actually. I just did not remember it was there.

New or changed structures:
* Ramp effects
struct ff_ramp_effect {
        _s16 start_level;
        _s16 end_level;
        struct ff_shape shape;
}
* Friction
No new structure. We can use the ff_interactive, according to PID. What is
its meaning is still not clear. I would guess the following:
force = f(position, direction)
force.direction = -direction
force.magnitude = p(position), p being the function described at page 12.
The ff_interactive_effect structure has changed:
struct ff_interactive_effect {
        __u16 right_saturation[2]; /* Max level when joystick is on the
right */
        __u16 left_saturation[2];  /* Max level when joystick in on the
left */

        __s16 right_coeff[2];   /* Indicates how fast the force grows when
the
                                   joystick moves to the right */
        __s16 left_coeff[2];    /* Same for left side */

        __u16 deadband[2];      /* Size of area where no force is produced
*/
        __s16 center[2];        /* Position of dead zone */

};

Note the arrays. There is one value for each axis. The axis mumber has
become useless and has therefore been droped.

* ff_periodic_effect:
struct ff_periodic_effect {
        __u16 waveform;         /* Kind of wave (sine, square...) */
        __u16 period;           /* in ms */
        __s16 magnitude;        /* Peak value */
        __s16 offset;           /* Mean value of wave (roughly) */
        __u16 phase;            /* 'Horizontal' shift */

        struct ff_shape shape;

/* Only used if waveform == FF_CUSTOM */
        __u32 custom_len;       /* Number of samples  */
        __s16 *custom_data;     /* Buffer of samples */
/* Note: the data pointed by custom_data is copied by the driver. You can
 * therefore dispose of the memory after the upload/update */
};

The _u32 for the number of samples is a bit oversized, maybe.


I think that's all for now. Comments and critics welcome.

-- 
Johann Deneux

Re: BUG when USB devices disconnected ?

[James S. <jsi...@tr...>]

> > > Go ahead. It'd be nice if the config automatically selected the defaults
> > > based on the architecture, too. (Possibly it wouldn't even need to ask).
> > 
> > The MIPS platform has a habit of doing that. Look at arch/mips/config.in
> > and you will see all the 
> > 
> > if [ "$CONFIG_MIPS_BLAHBLAH" = "y" ]; then
> >    define_bool ..
> >    define_tristate ...
> >    ...	
> > fi
> > 
> > The region for the PS/2 registers various from mips device to mips
> > device!!! So with setups like mips the defaults will show up
> > automatically.
> 
> Good. I's suggest the same with other archs.

Agree. Will make patch.

Re: BUG when USB devices disconnected ?

[Vojtech P. <vo...@su...>]

On Wed, Jan 30, 2002 at 10:31:06AM -0800, James Simmons wrote:
> 
> > > Also I like the i8042
> > > drivers have thier IRQ and IO regions configurable via Config.in.
> > 
> > No problem with that.
> > 
> > > The
> > > reason being is on many platforms it various. I hate to see a ton of
> > > #ifdef in i8042.h. Is that okay? If so I can wipe up a patch for DJ.
> > 
> > Go ahead. It'd be nice if the config automatically selected the defaults
> > based on the architecture, too. (Possibly it wouldn't even need to ask).
> 
> The MIPS platform has a habit of doing that. Look at arch/mips/config.in
> and you will see all the 
> 
> if [ "$CONFIG_MIPS_BLAHBLAH" = "y" ]; then
>    define_bool ..
>    define_tristate ...
>    ...	
> fi
> 
> The region for the PS/2 registers various from mips device to mips
> device!!! So with setups like mips the defaults will show up
> automatically.

Good. I's suggest the same with other archs.

-- 
Vojtech Pavlik
SuSE Labs

Re: BUG when USB devices disconnected ?

[James S. <jsi...@tr...>]

> > Also I like the i8042
> > drivers have thier IRQ and IO regions configurable via Config.in.
> 
> No problem with that.
> 
> > The
> > reason being is on many platforms it various. I hate to see a ton of
> > #ifdef in i8042.h. Is that okay? If so I can wipe up a patch for DJ.
> 
> Go ahead. It'd be nice if the config automatically selected the defaults
> based on the architecture, too. (Possibly it wouldn't even need to ask).

The MIPS platform has a habit of doing that. Look at arch/mips/config.in
and you will see all the 

if [ "$CONFIG_MIPS_BLAHBLAH" = "y" ]; then
   define_bool ..
   define_tristate ...
   ...	
fi

The region for the PS/2 registers various from mips device to mips
device!!! So with setups like mips the defaults will show up
automatically.

Re: BUG when USB devices disconnected ?

[Vojtech P. <vo...@su...>]

On Wed, Jan 30, 2002 at 10:16:23AM -0800, James Simmons wrote:

> > > > > All this happens with a patched 2.4.17 kernel (with my input-only
> > > > > patch). I will try to see what happens with the latest CVS version as soon
> > > > > as I can get it working.
> > > > 
> > > > Just use 2.5.2-dj6, it's all there ...
> > > 
> > > Hm. Prehaps we should put the ruby tree against the dj tree? 
> > 
> > I really hope to start merging to Linus soon, now that the bugs found in
> > the i8042/atkbd combination in Dave's kernel are fixed.
> 
> Great!! Have those fixes made it back into CVS yet.

Yes.

> Also I like the i8042
> drivers have thier IRQ and IO regions configurable via Config.in.

No problem with that.

> The
> reason being is on many platforms it various. I hate to see a ton of
> #ifdef in i8042.h. Is that okay? If so I can wipe up a patch for DJ.

Go ahead. It'd be nice if the config automatically selected the defaults
based on the architecture, too. (Possibly it wouldn't even need to ask).

-- 
Vojtech Pavlik
SuSE Labs

Re: BUG when USB devices disconnected ?

[James S. <jsi...@tr...>]

> > > > All this happens with a patched 2.4.17 kernel (with my input-only
> > > > patch). I will try to see what happens with the latest CVS version as soon
> > > > as I can get it working.
> > > 
> > > Just use 2.5.2-dj6, it's all there ...
> > 
> > Hm. Prehaps we should put the ruby tree against the dj tree? 
> 
> I really hope to start merging to Linus soon, now that the bugs found in
> the i8042/atkbd combination in Dave's kernel are fixed.

Great!! Have those fixes made it back into CVS yet. Also I like the i8042
drivers have thier IRQ and IO regions configurable via Config.in. The
reason being is on many platforms it various. I hate to see a ton of
#ifdef in i8042.h. Is that okay? If so I can wipe up a patch for DJ.