linuxconsole-dev

Re: linux console and force feedback

[Alex D. <ag...@ya...>]

I'm not much of a programmer, but if there is some
script or program you want me to run, etc., I'd be
happy to help.  It's a USB mouse.  I would guess that
it works similarly to the joysticks since the "feel"
technology in the mouse is from immerse corp, who also
makes the stuff for the joysticks.  THe joystick force
feedback stuff could be fairly easily adapted to the
mouse input driver I would imagine, assuming they used
a similar protocol.

Alex

--- Johann Deneux <jo...@Do...> wrote:
> On Wed, 5 Sep 2001, Alex Deucher wrote:
> 
> >     I am starting to look into the linuxconsole
> > project, and I noticed that there was support for
> > force feedback joysticks using the immersion
> > technologies stuff.  I have a logitech ifeel mouse
> > that has a similar sort of thing, that is
> apparently
> > also from immersion corp.  Do you know if they use
> the
> > same protocol off hand?  would there be any chance
> > that the "feel" features of the mouse might be
> > supported by the new input drivers at some point? 
> 
> I have no idea what protocol ifeel mice use, and the
> driver for force
> feedback joysticks is designed for, well, joysticks
> (and wheels), not
> mice. Sorry. Adding support for mice would be nice:
> window managers
> already implement some kind of "resistance" when you
> move windows above
> others, and this effect, among others, would be nice
> to render
> IMO. Anybody with an ifeel mouse willing to have a
> look at the protocol
> used ?
> 
> -- 
> Johann Deneux
> http://www.esil.univ-mrs.fr/~jdeneux/projects/
> 


__________________________________________________
Do You Yahoo!?
Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger
http://im.yahoo.com

Re: linux console and force feedback

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

On Wed, 5 Sep 2001, Alex Deucher wrote:

>     I am starting to look into the linuxconsole
> project, and I noticed that there was support for
> force feedback joysticks using the immersion
> technologies stuff.  I have a logitech ifeel mouse
> that has a similar sort of thing, that is apparently
> also from immersion corp.  Do you know if they use the
> same protocol off hand?  would there be any chance
> that the "feel" features of the mouse might be
> supported by the new input drivers at some point? 

I have no idea what protocol ifeel mice use, and the driver for force
feedback joysticks is designed for, well, joysticks (and wheels), not
mice. Sorry. Adding support for mice would be nice: window managers
already implement some kind of "resistance" when you move windows above
others, and this effect, among others, would be nice to render
IMO. Anybody with an ifeel mouse willing to have a look at the protocol
used ?

-- 
Johann Deneux
http://www.esil.univ-mrs.fr/~jdeneux/projects/

linux console and force feedback

[Alex D. <ag...@ya...>]

    I am starting to look into the linuxconsole
project, and I noticed that there was support for
force feedback joysticks using the immersion
technologies stuff.  I have a logitech ifeel mouse
that has a similar sort of thing, that is apparently
also from immersion corp.  Do you know if they use the
same protocol off hand?  would there be any chance
that the "feel" features of the mouse might be
supported by the new input drivers at some point? 
Just curious.

Also what is the status of the new console stuff;
i.e., is multi-head, etc., workable yet?

Thanks,

Alex

__________________________________________________
Do You Yahoo!?
Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger
http://im.yahoo.com

Re: [Linux-fbdev-devel] ruby on pm3/i386

[Romain D. <do...@ir...>]

James Simmons wrote:

> That sounds like a bug in the check_var function. When I get the chance I
> will go threw the code.

Dunno if it was the bug, but my ugly code had an ugly bug that
needed an ugly fix (commited). if set_par was ever called prior
to that check_var, then it was the bug (the pointer
to the hardware-specific state got erased and never restored...)

HTH

-- 
DOLBEAU Romain               | l'histoire est entierement vraie, puisque
ENS Cachan / Ker Lann        |     je l'ai imaginee d'un bout a l'autre
do...@ir...             |           -- Boris Vian

Re: [Linux-fbdev-devel] ruby on pm3/i386

[Sven L. <lu...@la...>]

On Tue, Sep 04, 2001 at 10:03:02AM -0700, James Simmons wrote:
> 
> > I added some printk's into the __fb_try_mode function, and the last message
> > displayed before the OOPS was SVEN : 19, which is just before the if line :
> > 
> >     printk ("SVEN : 18\n");
> >     var->vmode = mode->vmode
> >     printk ("SVEN : 19\n");
> >     if (info->fbops->fb_check_var)
> > 	err = info->fbops->fb_check_var(var, info);
> >     printk ("SVEN : 20\n");
> >     return !err;
> > }
> > 
> > So, i hope this gives you more information to tackle this bug.
> 
> That sounds like a bug in the check_var function. When I get the chance I
> will go threw the code. 


mmm, from my reading of the code and the bug and the stack trace and code
pointer, it seems that if fb_check_var was buggy, then the OOPS would happen
after the call to fb_check_var, and the code pointer returned by the OOPS
would be one inside the fb_check_var function.

my guess, but again, i didin't have time to look at it more in detail, would
be either info or info->fbops are null pointer. Or maybe even
info->fbops->fb_check_var is one, not sure if that would have the same
effect.

I will add some tests and printks here and report back.

But then maybe i misinterpreted the OOPS stuff, and it is possible that the
code pointer value is not the real one or something such ? i have no
experience in kernel debugging this kind of stuff.

Friendly,

Sven Luther

Re: pm3 & CVS

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

> > Yeap. It is not present in the standard tree.
> 
> Could we possibly add it to our tree? It makes much easier to avoid
> buffer overruns, which are rather a big problem when they're in the
> kernel.

Sure. Go ahead and added.

Re: pm3 & CVS

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

On Tue, Sep 04, 2001 at 11:22:56AM -0700, James Simmons wrote:

> > Odd.
> > 
> > include/linux/kernel.h:65:extern int snprintf(char * buf, size_t size, const char * fmt, ...);
> 
> Yeap. It is not present in the standard tree.

Could we possibly add it to our tree? It makes much easier to avoid
buffer overruns, which are rather a big problem when they're in the
kernel.

-- 
Vojtech Pavlik
SuSE Labs

Re: pm3 & CVS

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

> Odd.
> 
> include/linux/kernel.h:65:extern int snprintf(char * buf, size_t size, const char * fmt, ...);

Yeap. It is not present in the standard tree.

Re: pm3 & CVS

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

On Tue, Sep 04, 2001 at 09:57:38AM -0700, James Simmons wrote:
> 
> > ####
> > drivers/input/inputdrv.o: In function `usb_make_path':
> > drivers/input/inputdrv.o(.text+0x44c0): undefined reference to
> > `snprintf'
> > ####
> > 
> > I don't thnk I changed anything in .config, and it used to compile...
> > 
> > the offending snprintf come from driver/input/hid_core.c, it
> > seems.
> 
> It didn't compile. It gave me a warning but went on its way. I did notice
> this. It appears the kernel lacks a snprintf function. This might explain
> your crashes. It loks like it will have to be replaced by sprintf.

Odd.

include/linux/kernel.h:65:extern int snprintf(char * buf, size_t size, const char * fmt, ...);

Oops, maybe I used an -ac kernel ...

-- 
Vojtech Pavlik
SuSE Labs

Re: [Linux-fbdev-devel] ruby on pm3/i386

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

> I added some printk's into the __fb_try_mode function, and the last message
> displayed before the OOPS was SVEN : 19, which is just before the if line :
> 
>     printk ("SVEN : 18\n");
>     var->vmode = mode->vmode
>     printk ("SVEN : 19\n");
>     if (info->fbops->fb_check_var)
> 	err = info->fbops->fb_check_var(var, info);
>     printk ("SVEN : 20\n");
>     return !err;
> }
> 
> So, i hope this gives you more information to tackle this bug.

That sounds like a bug in the check_var function. When I get the chance I
will go threw the code. 
 

Re: pm3 & CVS

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

> ####
> drivers/input/inputdrv.o: In function `usb_make_path':
> drivers/input/inputdrv.o(.text+0x44c0): undefined reference to
> `snprintf'
> ####
> 
> I don't thnk I changed anything in .config, and it used to compile...
> 
> the offending snprintf come from driver/input/hid_core.c, it
> seems.

It didn't compile. It gave me a warning but went on its way. I did notice
this. It appears the kernel lacks a snprintf function. This might explain
your crashes. It loks like it will have to be replaced by sprintf.

Re: pm3 & CVS

[Romain D. <do...@ir...>]

James Simmons wrote:
> 
> I did a bunch of changes just a little
> bit ago which I commited. Give the new code a try.


####
drivers/input/inputdrv.o: In function `usb_make_path':
drivers/input/inputdrv.o(.text+0x44c0): undefined reference to
`snprintf'
####

I don't thnk I changed anything in .config, and it used to compile...

the offending snprintf come from driver/input/hid_core.c, it
seems.


-- 
DOLBEAU Romain               | l'histoire est entierement vraie, puisque
ENS Cachan / Ker Lann        |     je l'ai imaginee d'un bout a l'autre
do...@ir...             |           -- Boris Vian

Re: pm3 & CVS

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

Please send me the system map as well.

> Well it's only a xmon output, dunno if it is useful. If yes, ask me for
> the System.map. BTW, xmon display on the screen no matter what, it
> ignores the serial console :-(
> 
> #####
> vector 300 at pc = c0015b14, lr = c0015b0c, msr = 9032, sp = c01a63a0
> [c01a65f0]
> dar = 48, dsisr = 4000000
> current = c01a4490, pid = 0, comm = swapper
> #####

Re: pm3 & CVS

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

> Seriously, without xmon, I get no message. After the BootX messages
> (arch:exit) I usually get the console (framebuffer or serial) to start
> displaying boot messages, but with 2.4.7-ruby I get nothing. The
> computer stand still, doing nothing (the power supply fan audibly slow
> down after a short while...). Serial console works fine with other
> 2.4.x, but I may have forgotten a kernel option in ruby... I'll check
> into that and also try with xmon enabled.

Can you send me your .config file? I like to see your setting.
The only thing that could have caused this problem is the console lock but
I have made that transparent to the console drivers now :-) It could have
been a problem with bust spinlock. I did a bunch of changes just a little
bit ago which I commited. Give the new code a try. 

Re: pm3 & CVS

[<dol...@cl...>]

> I just need detail info from ksymoops and what you did to cause the
> problem. 

Well it's only a xmon output, dunno if it is useful. If yes, ask me for
the System.map. BTW, xmon display on the screen no matter what, it
ignores the serial console :-(

#####
vector 300 at pc = c0015b14, lr = c0015b0c, msr = 9032, sp = c01a63a0
[c01a65f0]
dar = 48, dsisr = 4000000
current = c01a4490, pid = 0, comm = swapper
#####


-- 
DOLBEAU Romain               | You won't break me
ENS Cachan / Ker Lann        | You won't make me
Thesard IRISA / CAPS         | You won't take me
dol...@cl...    | -- Judas Priest in 'Blood Red Skies'

Re: pm3 & CVS

[<dol...@cl...>]

> I just need detail info from ksymoops and what you did to cause the
> problem.=20

Well, I do nothing and I get nothing :-)

Seriously, without xmon, I get no message. After the BootX messages
(arch:exit) I usually get the console (framebuffer or serial) to start
displaying boot messages, but with 2.4.7-ruby I get nothing. The
computer stand still, doing nothing (the power supply fan audibly slow
down after a short while...). Serial console works fine with other
2.4.x, but I may have forgotten a kernel option in ruby... I'll check
into that and also try with xmon enabled.

--=20
Romain DOLBEAU               | Ce que l'on con=E7oit bien s'=E9nonce
ENS Cachan / Ker Lann        | clairement, et les mots pour le dire
Thesard IRISA / CAPS         | arrivent ais=E9ment.
dol...@cl...    |       -- Nicolas Boileau

Re: pm3 & CVS

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

> No, but i have a paper and a pen, is it not enough ?

Yes :-) Also long as I can run it threw ksymoops and I have the System.map
as well.

Re: pm3 & CVS

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

> Well, it was a quick-and-dirty port, I need to fix it, I know :-(
> I'll try ASAP... thanks for the explanation. More docs is always
> good :-)

Thanks. I really need to write a white paper soon for 2.5.X.

> pm2fb but I don't know if it works. Sven tried to talk me into
> taking over pm2fb maintenance and creating a 'glinfb' or 'pmXfb' for
> both chipset, but without doc and hardware there's not much I can do...
> I couldn't even find a card to borrow, it seems pm2 aren't common
> in France (and the people who sold them on french auction sites have
> very strange idea about their value)

I have the card and the docs for it. I can give it a try.

> > Do you have serial console going to record any oops? I really like to make
> > it work on the PPC.
> 
> I have a SPARCstation ELC just for that :-) But I didn't find time
> yet :-(

I just need detail info from ksymoops and what you did to cause the
problem. 

Re: pm3 & CVS

[Sven <lu...@dp...>]

On Sun, Aug 26, 2001 at 09:10:50AM -0700, James Simmons wrote:
> 
> > Done. untested as Ruby won't work on my PPC box.
> 
> Do you have serial console going to record any oops? I really like to make
> it work on the PPC.

No, but i have a paper and a pen, is it not enough ?

Friendly,

Sven Luther

Re: pm3 & CVS

[Romain D. <do...@ir...>]

James Simmons wrote:

> Hm, strange. Lets see. I see what is causing alot of the problems. In the
> new fbdev api you have to do the reverse of how you defined your data.
> 
> The upper fbcon layers only can deal with struct fb_info itself. This is
> one of the big reasons why the fbcon layer shrunk so much in size for
> ruby. You can blindly pass around hardware data without ever touching it
> in the upper layers. What you need is:

Well, it was a quick-and-dirty port, I need to fix it, I know :-(
I'll try ASAP... thanks for the explanation. More docs is always
good :-)

> Will this driver work on a pm2 card? I recently came into possesion of
> one.

No. The chip are similar but not close enough. There's a nold, orhpaned
pm2fb but I don't know if it works. Sven tried to talk me into
taking over pm2fb maintenance and creating a 'glinfb' or 'pmXfb' for
both chipset, but without doc and hardware there's not much I can do...
I couldn't even find a card to borrow, it seems pm2 aren't common
in France (and the people who sold them on french auction sites have
very strange idea about their value)

> Do you have serial console going to record any oops? I really like to make
> it work on the PPC.

I have a SPARCstation ELC just for that :-) But I didn't find time
yet :-(

-- 
DOLBEAU Romain               | l'histoire est entierement vraie, puisque
ENS Cachan / Ker Lann        |     je l'ai imaginee d'un bout a l'autre
do...@ir...             |           -- Boris Vian

Re: pm3 & CVS

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

> No, no luck, ...
> 
> it dies with :
> 
> unable to handle NULL pointer dereference at virtual address 0000000c
> 
> eip is c01e60a1 (__fb_try_mode is c01e6020, next is fb_set_var at c01e60d0).
> 
> call trace seems to be :
> 
> pm3fb_mode_setup
> 
> pm3fb_real_setup
> 
> init
> 
> kernel_thread (not sure about this one, i missed one digit and had to guess
> it.)
> 
> I start the kernel with grub and :
> 
> title linux (2.4.7-ruby pm3fb)
> root (hd0,0)
> kernel (hd0,0)/boot/vmlinuz-2.4.7-ruby root=/dev/hda1
> video=pm3fb:mode:0:800x600-75,mode:1:640x400-60,off
> 
> Hope this is helpfull and i did not mess up some stuff.
> 
> Note, i got ruby from cvs yesterday, and simply copied the linux directory
> over to a fresh 2.4.7 tree.?

Hm, strange. Lets see. I see what is causing alot of the problems. In the
new fbdev api you have to do the reverse of how you defined your data. 
You have:

struct pm3fb_info {
        struct fb_info gen;
        unsigned long board_num; /* internal board number */
        unsigned long use_current;
        struct pm3fb_par *current_par;
        struct pci_dev *dev;    /* PCI device */
        unsigned long board_type; /* index in the cardbase */
        unsigned char *fb_base; /* framebuffer memory base */
        u32 fb_size;            /* framebuffer memory size */
        unsigned char *p_fb;    /* physical address of frame buffer */
        unsigned char *v_fb;    /* virtual add
...

The upper fbcon layers only can deal with struct fb_info itself. This is
one of the big reasons why the fbcon layer shrunk so much in size for
ruby. You can blindly pass around hardware data without ever touching it
in the upper layers. What you need is:

struct fb_info pm3fb_info.

struct pm3_par { 
 	....
	/* Anything hardware specific and we can't shove into struct
	 * fb_info */
	....
}


xxxfb_init()
{
     /* fill in par values */
     par->fjfjfjf = hjfhfhf;
     ....
     pm2fb_info.par = par;
}

Will this driver work on a pm2 card? I recently came into possesion of
one.

Re: pm3 & CVS

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

> Done. untested as Ruby won't work on my PPC box.

Do you have serial console going to record any oops? I really like to make
it work on the PPC.

Re: pm3 & CVS

[Sven <lu...@dp...>]

On Fri, Aug 24, 2001 at 10:40:33AM +0200, Romain Dolbeau wrote:
> Sven wrote:
> > That said, i suppose the interresting part of the sourceforge project is the
> > cvs server, as noting else seems to be active. Which cvs module should i get,
> > and it is a whole linux kernel tree or only the console subsystem ?
> > 
> > mmm, it seems it is the whole kernel tree, and there is an AGAINST-2.4.7
> >  diff available. Is the stuff i need to test in this patch ? i don't think so
> > since it is 3 weeks old already.
> 
> the relevant module is 'ruby', which include a _partial_ kernel
> tree. you need a regular 2.4.7 and move/copy the ruby files.
> The AGAINST file is only a label to know the proper kernel
> version, it's an empty file...



No, no luck, ...

it dies with :

unable to handle NULL pointer dereference at virtual address 0000000c

eip is c01e60a1 (__fb_try_mode is c01e6020, next is fb_set_var at c01e60d0).

call trace seems to be :

pm3fb_mode_setup

pm3fb_real_setup

init

kernel_thread (not sure about this one, i missed one digit and had to guess
it.)

I start the kernel with grub and :

title linux (2.4.7-ruby pm3fb)
root (hd0,0)
kernel (hd0,0)/boot/vmlinuz-2.4.7-ruby root=/dev/hda1
video=pm3fb:mode:0:800x600-75,mode:1:640x400-60,off

Hope this is helpfull and i did not mess up some stuff.

Note, i got ruby from cvs yesterday, and simply copied the linux directory
over to a fresh 2.4.7 tree.?

Friendly,

Sven Luther

Vacation

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

I will be out from this Staurday until the following Sunday. 

Re: pm3 & CVS

[Sven <lu...@dp...>]

On Fri, Aug 24, 2001 at 10:40:33AM +0200, Romain Dolbeau wrote:
> Sven wrote:
> > That said, i suppose the interresting part of the sourceforge project is the
> > cvs server, as noting else seems to be active. Which cvs module should i get,
> > and it is a whole linux kernel tree or only the console subsystem ?
> > 
> > mmm, it seems it is the whole kernel tree, and there is an AGAINST-2.4.7
> >  diff available. Is the stuff i need to test in this patch ? i don't think so
> > since it is 3 weeks old already.
> 
> the relevant module is 'ruby', which include a _partial_ kernel
> tree. you need a regular 2.4.7 and move/copy the ruby files.
> The AGAINST file is only a label to know the proper kernel
> version, it's an empty file...

Ok, will download it this afternoon, and try it out, don't know if i will have
time for it though until next week.

Friendly,

Sven Luther