linuxconsole-dev

iforce.c split

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

Hello,

I have to track down bugs in iforce.c code. As it was too big for me, I
split it into several files:
iforce-main.c: every exported functions from iforce.c
iforce-usb.c: usb-related code (ex: iforce-usb-xmit)
iforce-serio.c: serial-related code
iforce-packets.c: functions dealing with packets (send_packet,
                  dump_packet...)
iforce-ff.c: creation of force feedback packets.
iforce.h: header file common to all previously cited .c files

However, adding/removing files may break many things in Makefiles, and
maybe other parts of the tree. Therefore, I made my changes in another
branch, iforce-split.

-- 
Johann Deneux

Re: Synced to 2.4.10

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

> Or a quick fix would be to include sched.h in vgacon.c. That we can do.

Done!

Re: Synced to 2.4.10

[M. R. B. <mr...@0x...>]

* Johann Deneux <jo...@Do...> on Sun, Oct 07, 2001:

> 
> The best solution would probably be that hw_irq.h included sched.h. That's
> not our job. Or a quick fix would be to include sched.h in vgacon.c. That
> we can do.
> 

No, including sched.h in vgacon.c is better, if you try to include it in
hw_irq.h, you may end up with circular references, etc.  asm/ header files
should never include anything out of linux/, it should always be the other
way around.

M. R.

Re: Synced to 2.4.10

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

On Sat, 6 Oct 2001, James Simmons wrote:

> 
> After alot of work I synced our stuff up with 2.4.10. I tested it and it
> worked. Please test and let me know if you have any problems. Thank you.
> 

I still have this error in include/asm/hw_irq.h:
                 from vgacon.c:44:
/home/johann/linuxconsole/linux/include/asm/hw_irq.h: In function
`x86_do_profile':
/home/johann/linuxconsole/linux/include/asm/hw_irq.h:201: `current'
undeclared (first use in this function)
/home/johann/linuxconsole/linux/include/asm/hw_irq.h:201: (Each undeclared
identifier is reported only once
/home/johann/linuxconsole/linux/include/asm/hw_irq.h:201: for each
function it appears in.)

The best solution would probably be that hw_irq.h included sched.h. That's
not our job. Or a quick fix would be to include sched.h in vgacon.c. That
we can do.

-- 
Johann Deneux

Synced to 2.4.10

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

After alot of work I synced our stuff up with 2.4.10. I tested it and it
worked. Please test and let me know if you have any problems. Thank you.

P.S
   In 2.4.10 their where issues (in dmi_scan.c) with PS/2 and suspend on
certain Dell devices. It might be time to think about more in depth
thinking about power management.

New commit mailing list

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

We now have a mailing lost where all are commits are posted. Just go to
the linuxconsole project website (http://www.sf.net/projects/linuxconsole)
and follow the link to mailing list to join. Thank you.

lin...@li...

Re: Synced to 2.4.9

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

> Hm, I have just tested it now, and... it does not compile.
> - I had to modify module.h to add MODULE_LICENSE

That is in 2.4.10 only. Another reason why I have been on the move to get
it to 2.4.10. 

> - asm/hw_irq.h uses current, but does not include the header declaring it.

I don't touch this file so it must be a bug in standard 2.4.9.

> - drivers/video/vga.c complains:
> vga.c:318: `vga_lock' undeclared (first use in this function)

Really strange. I didn't have problems last night with compiling it except
for the MODULE_LICENCE stuff. Hm. I plan to sync tonoght to 2.4.10. We
need to be on the move now.

> I will try to see how I can fix that later this week end.

I will fix it tonight.

Re: Synced to 2.4.9

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

On Fri, 5 Oct 2001, James Simmons wrote:

> 
> > > Next to update to 2.4.10 tomorrow night.
> > > 
> > 
> > I tagged ruby with tag "two-four-nine". I still think it would be nice if
> > we regularly tagged files at each sync.
> 
> I agree. Its just I want it tested before I tag it. How did it work for
> you?
> 

Hm, I have just tested it now, and... it does not compile.
- I had to modify module.h to add MODULE_LICENSE
- asm/hw_irq.h uses current, but does not include the header declaring it.
- drivers/video/vga.c complains:
vga.c:318: `vga_lock' undeclared (first use in this function)

I will try to see how I can fix that later this week end.

-- 
Johann Deneux

Re: [Linux-fbdev-devel] Future of Framebuffer

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

> you are
> no longer under the scope of what devfs was designed for, thus a new virtual
> fs makes sense.

I thought so. 

> > Oh yeah. Tonight we can discuss some issues then.
> 
> Sounds good.

Okay. I will be online around 7:30 tonight.

Re: [linux-usb-devel] Anything new about Logitech IFeel-Mouse ForceFeedback-Support?

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

On Fri, 5 Oct 2001, James Simmons wrote:

> 
> > Part 2 doesn't exist yet, because we don't have Part 1... ;)
> 
> Well we pretty much do. 

Indeed. At least, we have an API that should not be to hard to extend for
mice support. Of course, we also need a driver behind the API !

> 
> >  a) The lack of a good way to send interrupt messages to USB devices
> >     from userspace (like libusb, but someone suggested this isn't too
> >     hard to fix),
> 
> By interrupt messages what do you mean exactly.
> 
> >  b) the somewhat more troubling problem of where to fit the iFeel driver.
> >     The iFeel mouse is a regular old HID device, and I think that the
> >     HID driver does a wonderful job in controlling it. But the iFeel has
> >     an extra interrupt endpoint which takes the force feedback commands,
> >     and I wasn't sure the best way to put this nonstandard extension
> >     into the current USB framework without rewriting or duplicating a
> >     lot of code nicely implemented in the HID driver.

I guess you could simply extend the existing hid driver. There are
callbacks in the input_dev structure, which are currently not used in hid.
These callbacks are:
* upload_effect to upload a new effect to the device or update an existing 
one
* erase_effect to suppress an effect
* event is used to play and stop effects

> 
> > Problem b is a more complicated issue, and I think this needs to be resolved
> > before we can move forward. I don't think it's a huge issue, but it needs
> > to be addressed. The place to do it is with the linuxconsole folks...
> 
> Hm. Do you have documentation on the iFeel protocol to how we can fit
> things together?
> 

I guess Adam knows pretty well the protocol. Anyway, I found this:
http://moore.cx/out/ifeel/


-- 
Johann Deneux

Re: Synced to 2.4.9

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

> > Next to update to 2.4.10 tomorrow night.
> > 
> 
> I tagged ruby with tag "two-four-nine". I still think it would be nice if
> we regularly tagged files at each sync.

I agree. Its just I want it tested before I tag it. How did it work for
you?

Re: Synced to 2.4.9

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

On Thu, 4 Oct 2001, James Simmons wrote:

> 
> Test and have fun!!!
> 
> Next to update to 2.4.10 tomorrow night.
> 

I tagged ruby with tag "two-four-nine". I still think it would be nice if
we regularly tagged files at each sync.

-- 
Johann Deneux

Re: [Linux-fbdev-devel] Future of Framebuffer

[Paul M. <pm...@mv...>]

On Fri, Oct 05, 2001 at 11:30:12AM -0700, James Simmons wrote:
> I'm thinking devfs was designed with the one file decriptor to hardware
> model. As you know I plan to expand this.
>=20
devfs works fine with the one file descriptor per registered device model,
as that's what it was designed for. For any kind of specialized requirements
such as multiple file descriptors per registered device component, you are
no longer under the scope of what devfs was designed for, thus a new virtual
fs makes sense.

> > It would make more sense to implement it as its
> > own native virtual fs. As an example.. could have something like /dev/g=
fx
> > as a top level mountpoint for the fs, and then just mount on that (woul=
dn't
> > matter if it were devfs or not).
>=20
> True. Perhaps we should start off this way with a few device filesystems
> and see the commonality in them to figure out a common backbone. I just
> don't want to end up duplicating alot of what devfs has done.
>=20
There really shouldn't be too much duplication of devfs at all. I think the
only thing we really need to deal with devfs for would be for /dev/fb/0
registration.. at which point we can just register with devfs and have it
generate a symlink to the appropriate dentry under the gfxfs.. in this case
/dev/gfx/0/fb. Other than that, devfs has no reason to care about anything
else.

> > laying out the API would really be the biggest trick.
>=20
> Oh yeah. Tonight we can discuss some issues then.

Sounds good.

Regards,

--=20
Paul Mundt <pm...@mv...>
MontaVista Software, Inc.

Re: [Linux-fbdev-devel] Future of Framebuffer

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

> Why deal with devfs tinkering? 

I'm thinking devfs was designed with the one file decriptor to hardware
model. As you know I plan to expand this.

> It would make more sense to implement it as its
> own native virtual fs. As an example.. could have something like /dev/gfx as a
> top level mountpoint for the fs, and then just mount on that (wouldn't matter
> if it were devfs or not).

True. Perhaps we should start off this way with a few device filesystems
and see the commonality in them to figure out a common backbone. I just
don't want to end up duplicating alot of what devfs has done.

[snip..
> /dev/fb{,/}0 would simply be a symlink to /dev/gfx/0/fb.

Yeap. 

[snip]... 

Wow!! I see you have put serious thought into this. More than I have. 

> laying out the API would really be the biggest trick.

Oh yeah. Tonight we can discuss some issues then.

Re: [linux-usb-devel] Anything new about Logitech IFeel-Mouse ForceFeedback-Support?

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

> Part 2 doesn't exist yet, because we don't have Part 1... ;)

Well we pretty much do. 

>  a) The lack of a good way to send interrupt messages to USB devices
>     from userspace (like libusb, but someone suggested this isn't too
>     hard to fix),

By interrupt messages what do you mean exactly.

>  b) the somewhat more troubling problem of where to fit the iFeel driver.
>     The iFeel mouse is a regular old HID device, and I think that the
>     HID driver does a wonderful job in controlling it. But the iFeel has
>     an extra interrupt endpoint which takes the force feedback commands,
>     and I wasn't sure the best way to put this nonstandard extension
>     into the current USB framework without rewriting or duplicating a
>     lot of code nicely implemented in the HID driver.

> Problem b is a more complicated issue, and I think this needs to be resolved
> before we can move forward. I don't think it's a huge issue, but it needs
> to be addressed. The place to do it is with the linuxconsole folks...

Hm. Do you have documentation on the iFeel protocol to how we can fit
things together?

Synced to 2.4.9

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

Test and have fun!!!

Next to update to 2.4.10 tomorrow night.

Re: [linux-usb-devel] Anything new about Logitech IFeel-Mouse ForceFeedback-Support?

[Adam G. <ad...@ev...>]

I started my SF page with the intent to make 2 items:

 1. The low level kernel drivers,

 2. the higher level userspace libraries and integration with Qt/GTK+.


Part 1 more rightfully belongs in the linuxconsole project, I think. They
have done an excellent job so far with all things USB, and I think they
will have something excellent for 2.5. They also have a force feedback
framework in place.

Part 2 doesn't exist yet, because we don't have Part 1... ;)

For now, it makes sense to focus resources on linuxconsole, because
that is where all the good stuff will happen. I looked at doing this,
but was somewhat stopped by two things:

 a) The lack of a good way to send interrupt messages to USB devices
    from userspace (like libusb, but someone suggested this isn't too
    hard to fix),

 b) the somewhat more troubling problem of where to fit the iFeel driver.
    The iFeel mouse is a regular old HID device, and I think that the
    HID driver does a wonderful job in controlling it. But the iFeel has
    an extra interrupt endpoint which takes the force feedback commands,
    and I wasn't sure the best way to put this nonstandard extension
    into the current USB framework without rewriting or duplicating a
    lot of code nicely implemented in the HID driver.

Problem a is not a huge problem, it just makes it easier to test and
develop the lowest level stuff.

Problem b is a more complicated issue, and I think this needs to be resolved
before we can move forward. I don't think it's a huge issue, but it needs
to be addressed. The place to do it is with the linuxconsole folks...



Yay, verbosity. Anyway, I hope that this gives you a better idea of 
where I'm at, and what needs to get done before we get some progress.
The actual commands to send to the mouse are dirt simple, we just
need to get them there smoothly... :)

For now, my 'tactile' SF project is sleeping. Once we get the basic kernel
stuff going, I think it would be a good place to work on the higher level
stuff, perhaps in a more device independent way. (That's why I named it
'tactile' and not 'ifeel-linux'.)



Regards,

Adam




On Thu, Oct 04, 2001 at 09:03:36PM +0200, Johann Deneux wrote:
> On Wed, 3 Oct 2001, Adam Goode wrote:
> 
> > Not really, the force feedback stuff has to go into the new Ruby
> > Linuxconsole code, and I haven't had a lot of time to hack around with
> > it...
> > 
> > Maybe this weekend... ha!
> > 
> 
> It seems you opened a project on sourceforge dedicated to this device,
> btw. As it does not look very active, do you expect to use it in the
> future, or do you intend to use the linuxconsole project ? I am asking
> that, because I sometimes receive questions related to force feedback and
> IFeel mice. Should I redirect people to the linux-usb-dev ML, the
> linuxconsole one, or your project page on sourceforge ?
> 
> Did you manage to get any information about the protocol itself ?
> 
> -- 
> Johann Deneux
> 
> 

Re: [Linux-fbdev-devel] Future of Framebuffer

[Paul M. <pm...@mv...>]

On Thu, Oct 04, 2001 at 04:58:53PM -0700, James Simmons wrote:
> > > I have spoken about this before. I like to see both interfaces merge =
in
> > > the future. Especially with the desire to move from traditional device
> > > files to device filesystems. In the future their will be a graphics
> > > frilesystem to replace the two. Well that is my dream. Of course thei=
r are
> > > a few issues on design with DRI which I will not go into here. =20
> > >=20
> > This sounds like a potential Ruby issue to me (well, the FS part anyway=
s)..
> > how about starting a module for it (or hacking it into the existing tre=
e)?
>=20
> We could but it would be a huge job. Alot of devfs tinkering.=20
>=20
Why deal with devfs tinkering? It would make more sense to implement it as =
its
own native virtual fs. As an example.. could have something like /dev/gfx a=
s a
top level mountpoint for the fs, and then just mount on that (wouldn't matt=
er
if it were devfs or not).

As far as general interfaces go.. a drop-in replacement for the ioctl()'s
really wouldn't be that big of a deal.

For each device that registered with the system, things could be done like:

/dev/gfx/
    0/
        fb
	cmap
	...
	mode
    1/
        fb
	cmap
	...
	mode

and so on, and so forth..

/dev/fb{,/}0 would simply be a symlink to /dev/gfx/0/fb.

FBIOGETCMAP/FBIOPUTCMAP can be done away with by doing reads and writes to =
the
/dev/gfx/0/cmap dentry. Just as all other GET/PUT routines can be done away
with.

Instead of trying to do "special" dentry manipulation in the fs itself, I
think it'd make more sense to just provide a few common interfaces.. Devices
only really need to register themselves with the system.. it's up to the
fb layer to deal with creation of the dentrys and dealing with any kind of
special requests. (Just as it would the requirement for any other subsystem
(DRM anyone?) to deal with special files and registering callbacks with
the fs for them).

The fs itself only needs to do a few things.. provide a few routines for
device registration, and for registering callbacks. In the event that no
callback is provided (or no flags like read-only are set on the created
file), generic dcache routines can be utilized instead..

This could all be done with just having a small structure that contained
a pointer to the dentry struct and a pointer to a set of routines that
callbacks can be assigned to. (Then just check for the existance of a provi=
ded
callback registered with the dentry when things were allocated, and either
use those, or fallback on defaults).

Another advantage of this system is that people who have special needs with
the system can simply write a module that sets up the files it wants, and
registers some callbacks and have it either globally applied or limit it
specifically to a specific card.. Reducing the need for adding ioctl()'s.

All in all, this really shouldn't be that big of a deal.. I don't think an
initial implementation should be difficult at all.. laying out the API
would really be the biggest trick.

Comments?

Regards,

--=20
Paul Mundt <pm...@mv...>
MontaVista Software, Inc.

Re: [Linux-fbdev-devel] Future of Framebuffer

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

On Thu, 4 Oct 2001, Paul Mundt wrote:

> On Thu, Oct 04, 2001 at 03:26:26PM -0700, James Simmons wrote:
> > I have spoken about this before. I like to see both interfaces merge in
> > the future. Especially with the desire to move from traditional device
> > files to device filesystems. In the future their will be a graphics
> > frilesystem to replace the two. Well that is my dream. Of course their are
> > a few issues on design with DRI which I will not go into here.  
> > 
> This sounds like a potential Ruby issue to me (well, the FS part anyways)..
> how about starting a module for it (or hacking it into the existing tree)?

We could but it would be a huge job. Alot of devfs tinkering. 

Re: Huge console switching lags

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

> > > > them. It draws pixel by pixel. Slow slow slow!!! I have developed a new
>             ^^^^^^^^^^^^^^^^^^^^^^^
> Where does it draw pixel by pixel?

Okay. Let me say most drivers don't take advantage of the graphics hardware 
to perform console operations. Instead they just draw directly to the
framebuffer which can be slow. 

> Yep. Vesafb started as a nice gimmick to show that it's possible, and turned
> out to be a solution for yet another
> we-don't-release-specs-to-OS/FS-people company.

I know. Same with OFfb.

> Euh, most fbcon-* drivers already do this. Grep for fb_write in e.g.
> drivers/video/fbcon-cfb8.c and count the byte accesses (=> 0).

Yep. The new code I developed came out the merging of all the fbcon-cfb*
drivers. 

Re: [Linux-fbdev-devel] Re: FB, video, FOURCC code

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

On Fri, Sep 28, 2001 at 03:33:17PM +0200, Michel D=E4nzer wrote:
> Sven wrote:
>=20
> > > I'm not sure - but what about having a support of hardware accelera=
ted
> > > decoding? (I mean such things as mpeg1, mpeg2 decoding, de-zigzag a=
nd so
> > > on)
> > > Unfortunatelly I never saw any opensource project which has impleme=
ntation
> > > of such things but if you know how it should be implemented then su=
ch
> > > extensions are gladly accepted too.
> >=20
> > mmm, The Xv extension to X does this.
>=20
> No, all it can do is colorspace conversion and scaling.

Yes, sure i meant XvMC, ...

> The brand new XvMC extension does this, the problem is the lack of
> documentation. There is only one implementation for i81x (done by an In=
tel
> employee) and no players support it yet.

Err ? are you sure of it ? There are some new Xv* stuff in the pm3 driver=
,
altough since pm3 don't support anything fancy beside overlay, this could=
 not
be any help for you.

That said, You know about the document describing XvMC, it is not really =
all
that clear, and i looked at it only once, but it was announced on the xfr=
ee
list some time ago.

Friendly,

Sven Luther

Re: Huge console switching lags

[Geert U. <ge...@li...>]

On Tue, 2 Oct 2001, James Simmons wrote:
> > > Well the reason the framebuffer suck is because the current api sucks for
> > > them. It draws pixel by pixel. Slow slow slow!!! I have developed a new
            ^^^^^^^^^^^^^^^^^^^^^^^
Where does it draw pixel by pixel?

> > > api that takes advantage of the accel engine of graphics hardware. It is
> > 
> > Great. VESAfb doesnt have one. Lots of older machines dont have one.
> 
>    True. Of course VESAfb exist because we lack so fbdev drivers. In time

Yep. Vesafb started as a nice gimmick to show that it's possible, and turned
out to be a solution for yet another
we-don't-release-specs-to-OS/FS-people company.

>    The software accel functions needed by the console layer (copyarea,
> fillrect, and drawimage) have been already written. Okay the drawimage one
> needs alot of work. I haven't benchmarked the new code versus the current
> code but you can see the difference. One of the big changes I have have
> made is that on write data to the framebuffer word aligned and a long at
> a time. For 8bpp you have 4 pixels written at a time. This makes for a
> much tigher loop. On ix86 you can see a huge difference in performance due
> to the word alignment. I knwo because at first I had a bug that wasn't
> doing it right. After I fix that bug you could see the difference. 

Euh, most fbcon-* drivers already do this. Grep for fb_write in e.g.
drivers/video/fbcon-cfb8.c and count the byte accesses (=> 0).

Gr{oetje,eeting}s,

						Geert

P.S. Not to criticize the development in the Ruby tree of the linux-console
     project, but I don't like facts that aren't true.
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Now it works!

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

I have made the improvements I was talking about the VT to tty driver
problem. You need to register a tty_driver before you called
register_console due to the way the console locking works. So now each VT
has it own locking independent of each other. Now that that is done I can
sync up to the newest kernels. I will do this tomorrow. Note fbcon is
broken at present with supporting more than on framebuffer device. I threw
in some static arrays instead of dynamically allocating them. I will fix
that tomorrow as well. Thank you.

Re: TTY discipline for Joypad

[NIIBE Y. <gn...@m1...>]

M. R. Brown wrote:
 > Keyboards and ps/2 adapters for the Dreamcast are a commodity and cheap.
 > What's the problem with requiring those who need keyboard access to the
 > Dreamcast to buy a keyboard?  I know you're going to argue that the ps/2
 > adapter isn't well supported, but it only takes a bit of testing to get
 > that correct.

Basically, I agree with you on that point.  Those who want to run Linux
should buy keyboard.

Other way around, supporting keyboard input by Joypad is good.

Back to Japan (after meeting you), I broke the display of my notebook
computer at airport.  Since then, I do my presentation with Dreamcast
(using DFBpoint).  Some people who have Dreamcast (say, for his
children) are getting interest, they want to "try" it on their Dreamcast
with no keyboard.

 > Using the joypad with it's 6 (max) magical buttons is just plain
 > silly.

I know.  But isn't it fun to implement it?

Well, you'd say I have (many other) things to do, oh, yes.
But I need something fun, sometime.
-- 

RE: TTY discipline for Joypad

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

Just as a idea. With the input api it is possible to feed input events
into a device. What I would do is this:

1) Use TIOCSWINSZ to resize the console. Freeing up the bottom part and 
   draw avirtual keybaord into it.

2) Read the events from the gamepad and see where it it is over this
   viritual keybaord and then feed this value into some "special" input
   device that is not a real device but accepts input evnts from userland
   to feed into the console layer.