linuxconsole-dev

Re: fatal bug VGA

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

> Uninicialized variable in  "vga_do_font_op" : "vc->display_fg->data_hook"
> 
> Patch:
> 
> 
> --- ruby-files/drivers/video/vgacon.c    Thu Jan 24 20:18:04 2002
> +++ linr/drivers/video/vgacon.c    Sun Jan 27 17:43:12 2002
> @@ -486,7 +486,7 @@
>           vc->vc_font.height = ORIG_VIDEO_POINTS;
>      }
>      vgacon_state.mode = MODE_TEXT;
> -
> +    vc->display_fg->data_hook = (void *) &vgacon_state;
>      if (init) {
>           /* Use default font */
>           if (vga_512_chars)


Thank you for finding this bug. Patch applied. Now I can try out using non
default fonts with vgacon. Acorn fonts here I come :-)
 

Re: BUG when USB devices disconnected ?

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

On Tue, Jan 29, 2002 at 04:53:42PM -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.

-- 
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? 

Re: BUG when USB devices disconnected ?

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

On Tue, 29 Jan 2002, Johann Deneux wrote:

> I see another possible problem. After a usb disconnect, the usb_device is
> "closed" by the usb system. Is it ok then to unregister it (again ?) in
> hid_exit ?

This one is OK.
I've just mistaken "unregistering a device" and "unregistering a
driver". 

-- 
Johann Deneux

Re: BUG when USB devices disconnected ?

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

On Tue, 29 Jan 2002, Vojtech Pavlik wrote:

> On Mon, Jan 28, 2002 at 09:58:39PM +0100, Johann Deneux wrote:
> > Hi,
> > 
> > When I turn off my I-Force wheel while a process having opened its
> > /dev/input/eventX entry is still running, strange things happen. I made
> > trials with evtest and fftest. Both crash. They either crash immediately,
> > on exit or when I press a key on my keyboard. Other strange behaviours are
> > mouse clicks being uneffective, the wm unwilling to change focus (I use
> > sloppy focus). The pointer of the mouse goes on moving, however.
> > 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 ...

After sending the mail yesterday, I fetched the dj6 patch. I see a few
differences here and there (do_gettimeofday instead of get_fast_time, for
example).
Perhaps it would be a good idea to keep the tree in sync with dave jones'
tree (instead of linus' one). This will have the side effect that the work
of dave will become easier, as we commit back the changes he did. If
I understand the plans, linuxconsole is going to go through dave's tree
before getting to linus anyway, or ?

> 
> > Anyway, I think there should be a test on evdev->exist in every entry
> > function (evdev_read, ioctl, write, release, flush ...). Adding these
> > tests did not solve the problem, though.
> 
> That shouldn't be needed. The structs associated are freed only after
> the file descriptor is closed.

Yes, but some input_* functions may be called. Depending on how input.c is
coded, that could be ok, but I have no idea right now. Let's have a look.
Imagine a process tries to send events to a non-existing device. It writes
to the dev entry. evdev_write is called, which calls
input_event. Is the struct input_dev *dev parameter correct ? In the case
of hid, it seems ok, as the hid pointer in hid_disconnect isn not kfreed
(isn't that a memory leak ?). In iforce, it is, which most certainly
causes problems.
I see another possible problem. After a usb disconnect, the usb_device is
"closed" by the usb system. Is it ok then to unregister it (again ?) in
hid_exit ?

-- 
Johann Deneux

Re: BUG when USB devices disconnected ?

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

On Mon, Jan 28, 2002 at 09:58:39PM +0100, Johann Deneux wrote:
> Hi,
> 
> When I turn off my I-Force wheel while a process having opened its
> /dev/input/eventX entry is still running, strange things happen. I made
> trials with evtest and fftest. Both crash. They either crash immediately,
> on exit or when I press a key on my keyboard. Other strange behaviours are
> mouse clicks being uneffective, the wm unwilling to change focus (I use
> sloppy focus). The pointer of the mouse goes on moving, however.
> 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 ...

> Anyway, I think there should be a test on evdev->exist in every entry
> function (evdev_read, ioctl, write, release, flush ...). Adding these
> tests did not solve the problem, though.

That shouldn't be needed. The structs associated are freed only after
the file descriptor is closed.

> 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.

-- 
Vojtech Pavlik
SuSE Labs

VSTATUS, VDISCARD etc.

[Yedidyah Bar-D. <di...@po...>]

Hello all,

I used to be a VMS sysadmin, and missed Ctrl-T (which outputs a status
line). I started to implement support for this for Linux, and sent
email to lkml and linux-serial, which got only one reply.
See <http://www.cs.tau.ac.il/~didi/ctrl-t> for my current patch,
which is probably not-too-bad (I use it on my home machine for
many months).
Today I saw (on Kernel-Threads) that this project (Linuxconsole) exists.

My questions:

1. Is this On-Topic here?

2. Is anyone interested? Is there a good chance that such features
will eventually get in? The current termios(3) says 8 times that
'something' is not supported under Linux. For completeness, I
might implement them all, in addition to anything that exists
elsewhere (e.g. *BSD) and someone wants.

3. Is it now a good time to start working on this now? Is the
new tty interface stable? I searched (briefly) the archives
for 'n_tty' and 'vstatus', and found nothing.

4. From the questions I asked in the mail to lkml, you see I
am far from being an experienced kernel programmer. With the
new architecture, will I need to be (especially locking issues),
or will it be taken care of in some other levels? Not that
I am afraid, but I realize there is no chance such patches
will be accepted by anyone if they make problems, since clearly
everyone can live well without them.

Thanks,
	Didi

BUG when USB devices disconnected ?

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

Hi,

When I turn off my I-Force wheel while a process having opened its
/dev/input/eventX entry is still running, strange things happen. I made
trials with evtest and fftest. Both crash. They either crash immediately,
on exit or when I press a key on my keyboard. Other strange behaviours are
mouse clicks being uneffective, the wm unwilling to change focus (I use
sloppy focus). The pointer of the mouse goes on moving, however.
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.

Anyway, I think there should be a test on evdev->exist in every entry
function (evdev_read, ioctl, write, release, flush ...). Adding these
tests did not solve the problem, though.

Can someone try to reproduce the bug with another USB device ?
(Advice: sync your disks before! The crash is actually a complete freeze)

-- 
Johann Deneux

Forgotten VGA

[<Aiv...@un...>]

Hi
A line seems it lost.

--- ruby-files/drivers/video/vgacon.c    Thu Jan 24 20:18:04 2002
+++ linr/drivers/video/vgacon.c    Sun Jan 27 17:43:12 2002
@@ -486,7 +486,7 @@
          vc->vc_font.height = ORIG_VIDEO_POINTS;
     }
     vgacon_state.mode = MODE_TEXT;
-
+    vc->display_fg->data_hook = (void *) &vgacon_state;
     if (init) {
          /* Use default font */
          if (vga_512_chars)


VGA worked, but I could not login.
If kernel command line "init=/bin/bash" given, I could interact with
linux-2.5.1-ruby.

mingetty, agetty will not work?

Serial console stop when VGA console is initialized.
Ctrl-Alt-Del Ooops.

How to bind second (third ... ) keyboard-videocard pair?

Driver/Device names in XF86Config?

Aivils

Re: interactive effects

[Rodrigo D. <cu...@uo...>]

Johann Deneux wrote:

>On Sat, 26 Jan 2002, Rodrigo Damazio wrote:
>
>>Bj|rn Augustsson wrote:
>>
>>>Quoting Johann Deneux <jo...@Do...>:
>>>
>>>>About interactive effects: See these effects as functions from someth=
ing
>>>>to a force.
>>>>Position -> Force : That's a spring
>>>>Velocity -> Force : That's friction (or damping, why does pid define=20
>>>>both
>>>>as different effects ???)
>>>>
>>>No idea. Note how the spec avoids talking about that about halfway thr=
u
>>>section 5.3, on page 12.
>>>
>>       It's just like he said...take a look at Immersion Studio...
>>
>
>The point was: what's the difference between friction and damping ? PID
>define both effect types, but on page 12 they use both terms to refer to
>the same function (force =3D f(Velocity)).
>
        Actually, I think that's not really up to us to discuss...if it=20
has two different IDs which can be sent to the device, then we should=20
implement it, and it's up to the device to make it different(or not)...

>>>>>what would FF_RUMBLE be?? Is it I-force specific?? If it's okay, I'l=
l
>>>>>
>>>>No, this effect is the "force feedback for the poor". It's used in IF=
eel
>>>>mice for example. It's just a simple vibration. You can find it in
>>>>some console joypads, too. For example, the AVB Pegasus joystick has
>>>>(should have, mine has none) a connector to add a joypad supporting=20
>>>>rumble
>>>>effects.
>>>>
>>>Right.  This is not even defined in the PID spec, which is kind of
>>>weird.
>>>
>>       That's why I thought it might be I-force specific...well, if it=20
>>works, just leave it there...
>>
>
>It does not "work" right now, as it's not implemented (none of my device=
s
>support it). But people working on the IFeel mouse will probably use it.
>
>>>>The other solution would be to hide these parameter blocks and let th=
e
>>>>driver optimize its memory usage. This looks pretty ambitious to me,
>>>>though.
>>>>
>>>Absolutely. Again, it could be done in a library.
>>>
>>>Hmm, Rodrigo, did you have a look at what the MS DirectInput looks=20
>>>like? How
>>>do they do this?
>>>
>>       Yes, I have - it seems they use 1-to-many...look at this:
>>
>>http://msdn.microsoft.com/library/default.asp?url=3D/library/en-us/dx8_=
c/directx_cpp/Input/CPP_Tuts/Tut4/Step4CreatingEffect.asp
>>
>
>I also had a look, and found no reference to sharing parameter
>blocks. What they have is basically the following:
>- a struct DIEFFECT describing the basic attributes (direction,
>timing...). This struct has pointers to the two other structures
>- a struct DIPERIODIC, to set the period, phase...
>- a struct DIENVELOPE, for the envelope.
>
>None of these structures has ids. This makes me think parameter blocks
>cannot be shared, or at least the user has no control over it.
>
        There's struct DIPERIODIC, DIENVELOPE, then there's=20
LPDIPERIODIC, LPDIENVELOPE, etc. which are pointers to such=20
structs...that's when it happens...and in DIEFFECT struct, you can see th=
is:

    LPDIENVELOPE lpEnvelope;=20

        (I hate how obscure they make it, but it's a pointer)

>Updating effects is done the same way we do it (by sending the
>changed effect and specifying the id of the effect to change). I see no
>way change a parameter block alone.
>
        No, there isn't one at API level, but inside a program you can=20
use 1-to-n....but you're right, for the driver it seems like it's 1-to-1.=
..

Rodrigo

--=20
*******************************
* Rodrigo Damazio             *
* *************************** *
* cu...@uo...           *
* rod...@po... *
* ICQ: #3560450               *
* http://www.vros.com/cuddly/ *
* *************************** *
* Engenharia da Computa=E7=E3o    *
* Escola Polit=E9cnica          *
* USP - S=E3o Paulo             *
*******************************

Re: HID issues. [ with miniPATCH ]

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

On Sun, 27 Jan 2002, Vojtech Pavlik wrote:

> On Sat, Jan 26, 2002 at 11:55:51PM +0100, Bj|rn Augustsson wrote:
> > 
> > How come you set the output interrupt pipe to be a bulk pipe? That seems 
> > obviously wrong, and it wasn't that way in my patch. 
> 
> I'll have to research this further, but for me it was the only working
> way to generate an one-shot out interrupt. Actually it's the same on the
> USB bus. But I agree that it's non-obvious and that there may be a
> better way to do it.
> 
> > Do you know something I don't?  
> > (It had a "/* FIXME should we use sndint here? */" after it, which was 
> > removed by 1.39)
> 
> See above. You can try with the sndintpipe - if it works, OK. I can't
> check with any HID device right now. Perhaps Johann Deneux can check
> with I-Force - there is also bulk used instead of int and it works OK.

I tried to replace:
FILL_BULK_URB(&iforce->out, dev, usb_sndbulkpipe(dev,  
epout->bEndpointAddress), iforce + 1, 32, iforce_usb_out, iforce);

by:
FILL_INT_URB(&iforce->out, dev, usb_sndintpipe(dev,
epout->bEndpointAddress), iforce + 1, 32, iforce_usb_out, iforce, 0);

It did not work. Maybe there are other changes to do, but I do not see
which ones. The last parameter should tell the driver to use one-shot out
interrupts, which I guess is what we want.

-- 
Johann Deneux

Re: Interactive Effects

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

On Sat, 26 Jan 2002, Rodrigo Damazio wrote:

> Johann Deneux wrote:
> 
> >
> > About interactive effects: See these effects as functions from something
> > to a force.
> > Position -> Force : That's a spring
> > Velocity -> Force : That's friction (or damping, why does pid define both
> > as different effects ???)
> > Acceleration -> Force : That should be inertia. It's not implemented in
> > I-Force. Actually, Immersion seems to consider this to be the same as
> > friction.
> >
>        I knew this...if you look in Immersion Studio, you'll see you can 
> actually see a graph force vs. {position | velocity | acceleration }...
> 
> >
> >
> > I agree that we should add FF_INERTIA and FF_RAMP, but FF_DAMPER looks
> > pretty useless to me. Unless I missed the point ?
> >
>        Well, I've tried creating some Damper effects - it does make a 
> difference...besides, it's in the specs...

The direct input docs describes these condition types in:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dx8_c/directx_cpp/Input/Using/ForceFeedback/EffectConditions.asp
The interesting part is:
"
    *  Friction. The force is applied when the axis is moved and depends
on the defined friction coefficient.
    * Damper. The force increases in proportion to the velocity with which
the user moves the axis.
"
Apparently, the friction does not depend on the speed. And now that I
write it, it hits me: friction is not force = f(Velocity). I should have
known it.
The formula is defined as following:
force.direction = -velocity.direction
force.magnitude = k
Imagine you are pushing a heavy box on the ground. k depends on the type
of the ground, the material of the box and the mass of the box. As those
do not change, k is indeed constant.

I will check again what USBsnoopy says. I seem to recall that for I-Force
devices, friction = damping.

-- 
Johann Deneux

Re: interactive effects

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

On Sat, 26 Jan 2002, Rodrigo Damazio wrote:

> 
> Bj|rn Augustsson wrote:
> 
> > Quoting Johann Deneux <jo...@Do...>:
> >
> >> About interactive effects: See these effects as functions from something
> >> to a force.
> >> Position -> Force : That's a spring
> >> Velocity -> Force : That's friction (or damping, why does pid define 
> >> both
> >> as different effects ???)
> >>
> >
> > No idea. Note how the spec avoids talking about that about halfway thru
> > section 5.3, on page 12.
> >
>        It's just like he said...take a look at Immersion Studio...

The point was: what's the difference between friction and damping ? PID
define both effect types, but on page 12 they use both terms to refer to
the same function (force = f(Velocity)).

> 
> >>> what would FF_RUMBLE be?? Is it I-force specific?? If it's okay, I'll
> >>
> >> No, this effect is the "force feedback for the poor". It's used in IFeel
> >> mice for example. It's just a simple vibration. You can find it in
> >> some console joypads, too. For example, the AVB Pegasus joystick has
> >> (should have, mine has none) a connector to add a joypad supporting 
> >> rumble
> >> effects.
> >>
> >
> > Right.  This is not even defined in the PID spec, which is kind of
> > weird.
> 
>        That's why I thought it might be I-force specific...well, if it 
> works, just leave it there...

It does not "work" right now, as it's not implemented (none of my devices
support it). But people working on the IFeel mouse will probably use it.

> >> The other solution would be to hide these parameter blocks and let the
> >> driver optimize its memory usage. This looks pretty ambitious to me,
> >> though.
> >>
> >
> > Absolutely. Again, it could be done in a library.
> >
> > Hmm, Rodrigo, did you have a look at what the MS DirectInput looks 
> > like? How
> > do they do this?
> >
>        Yes, I have - it seems they use 1-to-many...look at this:
> 
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dx8_c/directx_cpp/Input/CPP_Tuts/Tut4/Step4CreatingEffect.asp

I also had a look, and found no reference to sharing parameter
blocks. What they have is basically the following:
- a struct DIEFFECT describing the basic attributes (direction,
timing...). This struct has pointers to the two other structures
- a struct DIPERIODIC, to set the period, phase...
- a struct DIENVELOPE, for the envelope.

None of these structures has ids. This makes me think parameter blocks
cannot be shared, or at least the user has no control over it.

Updating effects is done the same way we do it (by sending the
changed effect and specifying the id of the effect to change). I see no
way change a parameter block alone.

To me it seems that parameter blocks do not have an existence of their
own.


-- 
Johann Deneux

Re: interactive effects

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

On Sat, Jan 26, 2002 at 11:38:24PM -0200, Rodrigo Damazio wrote:
> 
> Bj|rn Augustsson wrote:
> 
> > Quoting Johann Deneux <jo...@Do...>:
> >
> >> However, I think they should be added in the API. It's up to the 
> >> driver to
> >> decide how to implement this effect.
> >>
> >
> > I agree that they should be added to the API. I don't think a driver
> > should decide to emulate one effect with another, except in extreme
> > cases. This sort of thing is much better done in userspace. (A library
> > for example.)
> 
>        libff...btw, does the API have a way to get the capabilities of a 
> PID device?? Like what effects it can produce??

EVIOCGBIT(EV_FF) ...

-- 
Vojtech Pavlik
SuSE Labs

Re: Interactive Effects

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

On Sat, Jan 26, 2002 at 11:37:56PM -0200, Rodrigo Damazio wrote:
> >> what would FF_RUMBLE be?? Is it I-force specific?? If it's okay, I'll
> >
> >
> > No, this effect is the "force feedback for the poor". It's used in IFeel
> > mice for example. It's just a simple vibration. You can find it in
> > some console joypads, too. For example, the AVB Pegasus joystick has
> > (should have, mine has none) a connector to add a joypad supporting 
> > rumble
> > effects.
> >
>        Oh, okay...doesn't it have any parameters?? Not even magnitude??

No, it doesn't have even magnitude. 

-- 
Vojtech Pavlik
SuSE Labs

Re: Interactive Effects

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

On Sat, Jan 26, 2002 at 11:37:27PM -0200, Rodrigo Damazio wrote:

> >You are right. Anyway, I think we should stick to ANSI C. Not for the
> >driver itself of course, but for the user-visible headers.
> >Yet another solution would be that the user provides a pointer to a buffer
> >describing the custom effect.
> >Isn't this solution nicer ? I personnaly dislike the idea of having
> >several ioctls perform one operation (the uploading of a full-effect)
> >
>         The idea is good...would also need a buffer size in there...is 
> that safe enough? To just invade userspace and take the buffer?? What 
> happens if the user allocated a 1-byte buffer and tells us it has 1000 
> bytes?? Would it be possible that we'd be invading another process's 
> memory?? (excuse me, I hate memory management, hehe)

No, that can't happen. But the process will either crash or the data
transfer will fail with -EFAULT.

-- 
Vojtech Pavlik
SuSE Labs

(no subject)

[Charles C. <cha...@co...>]

lists

Re: interactive effects

[Rodrigo D. <cu...@uo...>]

Bj|rn Augustsson wrote:

> Quoting Johann Deneux <jo...@Do...>:
>
>> However, I think they should be added in the API. It's up to the=20
>> driver to
>> decide how to implement this effect.
>>
>
> I agree that they should be added to the API. I don't think a driver
> should decide to emulate one effect with another, except in extreme
> cases. This sort of thing is much better done in userspace. (A library
> for example.)

       libff...btw, does the API have a way to get the capabilities of a=20
PID device?? Like what effects it can produce??

>> About interactive effects: See these effects as functions from somethi=
ng
>> to a force.
>> Position -> Force : That's a spring
>> Velocity -> Force : That's friction (or damping, why does pid define=20
>> both
>> as different effects ???)
>>
>
> No idea. Note how the spec avoids talking about that about halfway thru
> section 5.3, on page 12.
>
       It's just like he said...take a look at Immersion Studio...

>>> what would FF_RUMBLE be?? Is it I-force specific?? If it's okay, I'll
>>
>> No, this effect is the "force feedback for the poor". It's used in IFe=
el
>> mice for example. It's just a simple vibration. You can find it in
>> some console joypads, too. For example, the AVB Pegasus joystick has
>> (should have, mine has none) a connector to add a joypad supporting=20
>> rumble
>> effects.
>>
>
> Right.  This is not even defined in the PID spec, which is kind of
> weird.

       That's why I thought it might be I-force specific...well, if it=20
works, just leave it there...

>>>> Anyway, we will have to change the API to take custom effects into
>>>> account.
>>>>
>>>   Yes, I know...have you decided how we'll do that?? I guess that
>>
>> No. The "1 parameter block - n effects" is appealing, but we must=20
>> make it
>> hardware independant. Right now, there is no obstacle to doing it, as
>> I-Force and PID seems to share the same view of what to put into=20
>> parameter
>> blocks. Is it a safe bet to assume future specs won't change ?
>>
>
> Actually, having thought about this some more, this is NOT how PID
> works, unless you're in driver-managed mode (which the MS FF2 isn't -
> it uses the "device managed"  memory model. (Maybe it can switch, I
> haven't checked that carefully, but I don't think so.)
>
> Here you get a number (in the FF2 case, 40) "slots" to put effects in,
> and they each have room for whatever extra parameter blocks are needed.
> (Ie, they're often oversized.) You can _not_ share parameter blocks=20
> between effects in this model.

       You're right - I hadn't thought about this...so we have two=20
choices - wec

>> The other solution would be to hide these parameter blocks and let the
>> driver optimize its memory usage. This looks pretty ambitious to me,
>> though.
>>
>
> Absolutely. Again, it could be done in a library.
>
> Hmm, Rodrigo, did you have a look at what the MS DirectInput looks=20
> like? How
> do they do this?
>
       Yes, I have - it seems they use 1-to-many...look at this:

http://msdn.microsoft.com/library/default.asp?url=3D/library/en-us/dx8_c/=
directx_cpp/Input/CPP_Tuts/Tut4/Step4CreatingEffect.asp

       It's a tutorial on how to create effects... and has links to the=20
structs definitions...

>> The last solution is to go for "1 parameter block - 1
>> effect" solution. It's safe, easy to implement, but it kills the
>> possibility to share parameters between several effects.
>>
>
> Right.
> Now for custom effects, I think we should have a separate call to uploa=
d
> those. Having the variable length array thing you suggested is nice, bu=
t
> then we can't add more fields to the strut after that if we choose to
> later. (Or can we? I seem to remember that the variable length array ha=
s
> to be the last member of a struct, but I'm not sure...)
>
       We can add members before the variable-length array...

Rodrigo

--=20
*******************************
* Rodrigo Damazio             *
* *************************** *
* cu...@uo...           *
* rod...@po... *
* ICQ: #3560450               *
* http://www.vros.com/cuddly/ *
* *************************** *
* Engenharia da Computa=E7=E3o    *
* Escola Polit=E9cnica          *
* USP - S=E3o Paulo             *
*******************************

Re: Interactive Effects

[Rodrigo D. <cu...@uo...>]

Johann Deneux wrote:

>On Sat, 26 Jan 2002, Bj|rn Augustsson wrote:
>
>>Quoting Johann Deneux <jo...@Do...>:
>>
>>>On Sat, 26 Jan 2002, Rodrigo Damazio wrote:
>>>
>>>>Johann Deneux wrote:
>>>>
>>>>>On Sat, 26 Jan 2002, Rodrigo Damazio wrote:
>>>>>
>>>>   Okay, will do so...also, is itme who has an outdated version of=20
>>>>input.h, or does it really not have ET Ramp, Damper, and Inertia?? An=
d=20
>>>>
>>>Ramps did not seem to useful to me. Indeed, they can be realised using
>>>other effects, for example, using a shaped constant effect.
>>>
>>You can't emulate a shaped ramp effect that way though.
>>
>
>Right. You can however use sawtooth up or down, though. Set the effect
>length to play for one period only, and set the magnitude and offset to
>the "right" values. It is then still possible to add a shape.
>The point is, it seems there are different ways to achieve one given
>effect. Should we have a "non prime" set of effects ?
>
        There obviously are many ways to achieve a given effect, but I=20
think that decision should not be made by the kernel...the kernel should=20
just give all standard effects...

>>>The last solution is to go for "1 parameter block - 1
>>>effect" solution. It's safe, easy to implement, but it kills the
>>>possibility to share parameters between several effects.
>>>
>>Right.=20
>>=20
>>Now for custom effects, I think we should have a separate call to uploa=
d
>>those. Having the variable length array thing you suggested is nice, bu=
t
>>then we can't add more fields to the strut after that if we choose to
>>later. (Or can we? I seem to remember that the variable length array ha=
s
>>to be the last member of a struct, but I'm not sure...)
>>
>
>You are right. Anyway, I think we should stick to ANSI C. Not for the
>driver itself of course, but for the user-visible headers.
>Yet another solution would be that the user provides a pointer to a buff=
er
>describing the custom effect.
>Isn't this solution nicer ? I personnaly dislike the idea of having
>several ioctls perform one operation (the uploading of a full-effect)
>
        The idea is good...would also need a buffer size in there...is=20
that safe enough? To just invade userspace and take the buffer?? What=20
happens if the user allocated a 1-byte buffer and tells us it has 1000=20
bytes?? Would it be possible that we'd be invading another process's=20
memory?? (excuse me, I hate memory management, hehe)

Rodrigo

--=20
*******************************
* Rodrigo Damazio             *
* *************************** *
* cu...@uo...           *
* rod...@po... *
* ICQ: #3560450               *
* http://www.vros.com/cuddly/ *
* *************************** *
* Engenharia da Computa=E7=E3o    *
* Escola Polit=E9cnica          *
* USP - S=E3o Paulo             *
*******************************

Re: Interactive Effects

[Rodrigo D. <cu...@uo...>]

Johann Deneux wrote:

> On Sat, 26 Jan 2002, Rodrigo Damazio wrote:
>
>> Johann Deneux wrote:
>>
>>> On Sat, 26 Jan 2002, Rodrigo Damazio wrote:
>>>
>>>>   I just realized - the interactive effect struct doesn't allow us=20
>>>> to assign independent parameters to the X and Y axes...it should=20
>>>> though, since the PID spec says there are two condition blocks for=20
>>>> it - one for each axis...is it okay to modify it to include=20
>>>> separate parameters??
>>>>
>>> Definitely yes. I-Force also allows that.
>>>
>>   Okay, will do so...also, is itme who has an outdated version of=20
>> input.h, or does it really not have ET Ramp, Damper, and Inertia?? And
>
>
> Ramps did not seem to useful to me. Indeed, they can be realised using
> other effects, for example, using a shaped constant effect.
> However, I think they should be added in the API. It's up to the=20
> driver to
> decide how to implement this effect.
>
       I'm in favor of implmenting it, to comply with the specs...

>
> About interactive effects: See these effects as functions from somethin=
g
> to a force.
> Position -> Force : That's a spring
> Velocity -> Force : That's friction (or damping, why does pid define bo=
th
> as different effects ???)
> Acceleration -> Force : That should be inertia. It's not implemented in
> I-Force. Actually, Immersion seems to consider this to be the same as
> friction.
>
       I knew this...if you look in Immersion Studio, you'll see you can=20
actually see a graph force vs. {position | velocity | acceleration }...

>
>
> I agree that we should add FF_INERTIA and FF_RAMP, but FF_DAMPER looks
> pretty useless to me. Unless I missed the point ?
>
       Well, I've tried creating some Damper effects - it does make a=20
difference...besides, it's in the specs...

>> what would FF_RUMBLE be?? Is it I-force specific?? If it's okay, I'll
>
>
> No, this effect is the "force feedback for the poor". It's used in IFee=
l
> mice for example. It's just a simple vibration. You can find it in
> some console joypads, too. For example, the AVB Pegasus joystick has
> (should have, mine has none) a connector to add a joypad supporting=20
> rumble
> effects.
>
       Oh, okay...doesn't it have any parameters?? Not even magnitude??

>> add FF_RAMP, FF_DAMPER, and FF_INERTIA since they're defined in the
>> spec(5.1.1)...
>>
>>> Anyway, we will have to change the API to take custom effects into
>>> account.
>>>
>>   Yes, I know...have you decided how we'll do that?? I guess that
>
>
> No. The "1 parameter block - n effects" is appealing, but we must make =
it
> hardware independant. Right now, there is no obstacle to doing it, as
> I-Force and PID seems to share the same view of what to put into=20
> parameter
> blocks. Is it a safe bet to assume future specs won't change ?
>
       Well, if this model is working well, there'd be no reason for=20
them to change it... _if_ they ever do, we'll think about it...even=20
because if they change it, it'll have to be backwards-compatible...

> The other solution would be to hide these parameter blocks and let the
> driver optimize its memory usage. This looks pretty ambitious to me,
> though.
>
       Would even be nice, but I think we should leave this decision to=20
the programmer...

> The last solution is to go for "1 parameter block - 1
> effect" solution. It's safe, easy to implement, but it kills the
> possibility to share parameters between several effects.
>
       I prefer the first one...it's how I'm creating prototypes for=20
libff at least...

>> since(in PID specs at least) custom effect data is sent on one(or=20
>> more) report by itself, saved in a memory position(just like an=20
>> effect), etc., we could just make an IOCTL to upload the custom data,=20
>> then we can normally upload an effect which points to that custom=20
>> data...that would require only minor changes to the existing code...
>>
>> Rodrigo
>>
>> P.S.: I've started libff too...send me all ideas you have for nice=20
>> things it could do...I'm using re-usable parameter blocks(something=20
>> like FF_create_constant(float direction, float magnitude, FF_envelope=20
>> *envelope, FF_trigger *trigger, FF_time *time, FF_flags flags)  )
>>
>
> So you are going towards a user-visible 1-parameter-n-effects approach =
?
>
       Yes(actually it's n-parameters-m-effects)...even if that happens=20
only at a library level, and the kernel works differently...obviously,=20
there will be some convenient functions like to delete an effect and all=20
its related parameter blocks, so if a programmer wants 1-to-1, he can=20
just do something like:

eff =3D FF_create_constant(0, 1, FF_create_envelope(bla bla),=20
FF_create_trigger(bla bla), FF_create_time(bla bla), 0);

and then later a:

FF_delete_effect_related(eff);

   Would free all parameters blocks allocated...obviously it needs some=20
checks like if the user did something like

eff2.envelope =3D eff.envelope;

   Then we'd need to set eff2.envelope to NULL, just so it can't get=20
sent and cause a memory bug...

Rodrigo

--=20
*******************************
* Rodrigo Damazio             *
* *************************** *
* cu...@uo...           *
* rod...@po... *
* ICQ: #3560450               *
* http://www.vros.com/cuddly/ *
* *************************** *
* Engenharia da Computa=E7=E3o    *
* Escola Polit=E9cnica          *
* USP - S=E3o Paulo             *
*******************************

Re: HID issues. [ with miniPATCH ]

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

On Sat, Jan 26, 2002 at 11:55:51PM +0100, Bj|rn Augustsson wrote:
> Quoting Vojtech Pavlik <vo...@su...>:
> > On Sat, Jan 26, 2002 at 08:13:26PM +0100, Bj|rn Augustsson wrote:
> > > Quoting Vojtech Pavlik <vo...@su...>:
> > > > 
> > > > Maybe update, there was a serious rewrite of that part.
> > > 
> > > I'm trying! :)
> > > 
> > > I haven't gotten anything since that to build and boot, that's all...
> > 
> > Use 2.5.2-dj6 if you can, that's probably the easiest (and working as
> > well).
> 
> Good advice, it turns out. A few hours later, I have a working (?)
> kernel, by getting dj6 and then replacing _only_ the
> linux/drivers/usb/hid* files with the stuff from the CVS. 
> 
> Another question!
> 
> How come you set the output interrupt pipe to be a bulk pipe? That seems 
> obviously wrong, and it wasn't that way in my patch. 

I'll have to research this further, but for me it was the only working
way to generate an one-shot out interrupt. Actually it's the same on the
USB bus. But I agree that it's non-obvious and that there may be a
better way to do it.

> Do you know something I don't?  
> (It had a "/* FIXME should we use sndint here? */" after it, which was 
> removed by 1.39)

See above. You can try with the sndintpipe - if it works, OK. I can't
check with any HID device right now. Perhaps Johann Deneux can check
with I-Force - there is also bulk used instead of int and it works OK.

> I've attached a mini-patch as well, that fixes another thing. We only
> want to send outbound output reports over the output pipe - feature
> reports still go over the control pipe.

Ahh, correct. Thanks. In the CVS now.

> 
> /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

> --- /usr/src/joy/ruby/linux/drivers/usb/hid-core.c	Sat Jan 26 21:08:47 2002
> +++ hid-core.c	Sat Jan 26 23:50:53 2002
> @@ -1093,7 +1093,7 @@
>  	int head;
>  	unsigned long flags;
>  
> -	if (dir == USB_DIR_OUT && hid->urbout) {
> +	if (dir == USB_DIR_OUT && hid->urbout && report->type == HID_OUTPUT_REPORT) {
>  
>  		spin_lock_irqsave(&hid->outlock, flags);
>  


-- 
Vojtech Pavlik
SuSE Labs

Re: Interactive Effects

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

On Sat, 26 Jan 2002, Bj|rn Augustsson wrote:

> Quoting Johann Deneux <jo...@Do...>:
> > On Sat, 26 Jan 2002, Rodrigo Damazio wrote:
> > > Johann Deneux wrote:
> > > > On Sat, 26 Jan 2002, Rodrigo Damazio wrote:
> > >    Okay, will do so...also, is itme who has an outdated version of 
> > > input.h, or does it really not have ET Ramp, Damper, and Inertia?? And 
> > 
> > Ramps did not seem to useful to me. Indeed, they can be realised using
> > other effects, for example, using a shaped constant effect.
> 
> You can't emulate a shaped ramp effect that way though.

Right. You can however use sawtooth up or down, though. Set the effect
length to play for one period only, and set the magnitude and offset to
the "right" values. It is then still possible to add a shape.
The point is, it seems there are different ways to achieve one given
effect. Should we have a "non prime" set of effects ?

>[...]
> > The other solution would be to hide these parameter blocks and let the
> > driver optimize its memory usage. This looks pretty ambitious to me,
> > though.
> 
> Absolutely. Again, it could be done in a library.
> 
> Hmm, Rodrigo, did you have a look at what the MS DirectInput looks like? How
> do they do this?
> 
> > The last solution is to go for "1 parameter block - 1
> > effect" solution. It's safe, easy to implement, but it kills the
> > possibility to share parameters between several effects.
> 
> Right. 
>  
> Now for custom effects, I think we should have a separate call to upload
> those. Having the variable length array thing you suggested is nice, but
> then we can't add more fields to the strut after that if we choose to
> later. (Or can we? I seem to remember that the variable length array has
> to be the last member of a struct, but I'm not sure...)

You are right. Anyway, I think we should stick to ANSI C. Not for the
driver itself of course, but for the user-visible headers.
Yet another solution would be that the user provides a pointer to a buffer
describing the custom effect.
Isn't this solution nicer ? I personnaly dislike the idea of having
several ioctls perform one operation (the uploading of a full-effect)

> 
> /August.
> 
By the way, how should we call you ? August or Bj-pipe-rn :) ?

-- 
Johann Deneux

Re: HID issues. [ with miniPATCH ]

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

Quoting Vojtech Pavlik <vo...@su...>:
> On Sat, Jan 26, 2002 at 08:13:26PM +0100, Bj|rn Augustsson wrote:
> > Quoting Vojtech Pavlik <vo...@su...>:
> > > 
> > > Maybe update, there was a serious rewrite of that part.
> > 
> > I'm trying! :)
> > 
> > I haven't gotten anything since that to build and boot, that's all...
> 
> Use 2.5.2-dj6 if you can, that's probably the easiest (and working as
> well).

Good advice, it turns out. A few hours later, I have a working (?)
kernel, by getting dj6 and then replacing _only_ the
linux/drivers/usb/hid* files with the stuff from the CVS. 

Another question!

How come you set the output interrupt pipe to be a bulk pipe? That seems 
obviously wrong, and it wasn't that way in my patch. 
Do you know something I don't?  
(It had a "/* FIXME should we use sndint here? */" after it, which was 
removed by 1.39)

I've attached a mini-patch as well, that fixes another thing. We only
want to send outbound output reports over the output pipe - feature
reports still go over the control pipe.

/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: HID issues.

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

On Sat, Jan 26, 2002 at 08:13:26PM +0100, Bj|rn Augustsson wrote:
> Quoting Vojtech Pavlik <vo...@su...>:
> > On Fri, Jan 25, 2002 at 02:03:34AM +0100, Bj|rn Augustsson wrote:
> > > Sorry for the confusion.
> > 
> > You mean when we time out? Well, yes, then we have a problem. But the
> > timeout is the error case which shouldn't happen. Otherwise, I don't see
> > how any pending 'get report' requests could stay in the queue - we wait
> > for both the control and out queue to clear completely. 
> 
> Don't really know, but I do get output from the "hid_dump_input"
> function after hidinput_connect() has been called (ie too late) every
> now and then, and there's definetly something weird going on there,
> because sometimes I get weird data in them as well, as in
> 
> Jan 17 20:14:39 as22-3-7 kernel: hid-debug: input 6e69.4c20 = 1
> 
> Or some other random-looking value. Oh well.
> 
> > > > And it waits for all the
> > > > report to arrive then - it waits till the queue is empty. Maybe we are
> > > > each reading a different version? I'm looking at the current CVS.
> > > 
> > > Well, I'm not, but fairly close (CVS version tag 1.35).
> > 
> > Maybe update, there was a serious rewrite of that part.
> 
> I'm trying! :)
> 
> I haven't gotten anything since that to build and boot, that's all...

Use 2.5.2-dj6 if you can, that's probably the easiest (and working as
well).

> > Both input and feature reports come over the control pipe. The input
> > interrupt pipe isn't open at that time yet, and thus no reports are
> > coming over it.
> 
> Ah, OK. Well, that sorts that out. The problem must be somewhere else
> then.

If you find any possible reason for it, tell me, I'll take a look.

-- 
Vojtech Pavlik
SuSE Labs

Re: HID issues.

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

Quoting Vojtech Pavlik <vo...@su...>:
> On Fri, Jan 25, 2002 at 02:03:34AM +0100, Bj|rn Augustsson wrote:
> > Sorry for the confusion.
> 
> You mean when we time out? Well, yes, then we have a problem. But the
> timeout is the error case which shouldn't happen. Otherwise, I don't see
> how any pending 'get report' requests could stay in the queue - we wait
> for both the control and out queue to clear completely. 

Don't really know, but I do get output from the "hid_dump_input"
function after hidinput_connect() has been called (ie too late) every
now and then, and there's definetly something weird going on there,
because sometimes I get weird data in them as well, as in

Jan 17 20:14:39 as22-3-7 kernel: hid-debug: input 6e69.4c20 = 1

Or some other random-looking value. Oh well.

> > > And it waits for all the
> > > report to arrive then - it waits till the queue is empty. Maybe we are
> > > each reading a different version? I'm looking at the current CVS.
> > 
> > Well, I'm not, but fairly close (CVS version tag 1.35).
> 
> Maybe update, there was a serious rewrite of that part.

I'm trying! :)

I haven't gotten anything since that to build and boot, that's all...
 
> Both input and feature reports come over the control pipe. The input
> interrupt pipe isn't open at that time yet, and thus no reports are
> coming over it.

Ah, OK. Well, that sorts that out. The problem must be somewhere else
then.

/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