linuxconsole-dev

Re: Synced to 2.4.12

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

On Wed, 17 Oct 2001, James Simmons wrote:

> 
> > Good news, it almost worked on my PC. But without smp :(
> 
> Ah. So it is a race condition on SMP. I don't have a SMP box so I haven't
> seen this problem. Do you see anything? 

No, I don't. The problem is that the source would not compile. Still the
same problem with global_irq_lock in bust_spinlocks.
What is global_irq_lock suppose to do, by the way ? To disable irqs on all
cpus ?

> 
> > By almost, I mean that the kernel booted, and X started. Unfortunately, my
> > PS2 keyboard refused to work.
> 
> Hm. Strange. It should of put the "keyboard" in raw mode. The codes sent
> then are the one in drivers/char/keyboard.c. I will have to test it with X
> windows.

It did not work for the console either. But that may just be me who
misconfigured the kernel. I read input.txt several times, but it seems to
focus on USB keyboards and mice. I therefore have some difficulties to
apply it to my "simple" PS2 keyboard. I understand there are a few changes
to do to have the mouse working (patch gpm, change XF86Config). Is there
anything similar to do with the keyboard ?

-- 
Johann Deneux

[PATCH] input-ps2: Put serio and serport in drivers/input

[Chip S. <ch...@po...>]

The recently posted input-ps2 patch breaks if the serio and serport
object files in drivers/char/joystick are required only for PS/2
(i.e. they weren't enabled already for joysticks).  And that brings
up the question: What the heck are those files doing in the joystick
driver dir in the first place?!

It seems to me that serio.c and serport.c belong in drivers/input more
than anywhere else.  I'm enclosing a patch that handles just such a
relocation.  The patch doesn't actually move the files ... that would
just inflate the patch, and it's a lot easier to just "mv" them.

Share & Enjoy!
-- 
Chip Salzenberg               - a.k.a. -              <ch...@po...>
 "We have no fuel on board, plus or minus 8 kilograms."  -- NEAR tech

[PATCH] input-ps2: sprintf() params missing

[Chip S. <ch...@po...>]

The recently advertised input-ps2 patch has a minor repeated bug, in
that sprintf() calls are made without enough parameters.  I'm not sure
what the right fix is, but the attached patch at least calls sprintf()
correctly.
-- 
Chip Salzenberg               - a.k.a. -              <ch...@po...>
 "We have no fuel on board, plus or minus 8 kilograms."  -- NEAR tech

Re: Synced to 2.4.12

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

> Good news, it almost worked on my PC. But without smp :(

Ah. So it is a race condition on SMP. I don't have a SMP box so I haven't
seen this problem. Do you see anything? 

> By almost, I mean that the kernel booted, and X started. Unfortunately, my
> PS2 keyboard refused to work.

Hm. Strange. It should of put the "keyboard" in raw mode. The codes sent
then are the one in drivers/char/keyboard.c. I will have to test it with X
windows.

Re: Synced to 2.4.12

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

On Sun, 14 Oct 2001, James Simmons wrote:

> 
> I completed the syncing to 2.4.12 and tested it out on my local machine.
> It works fine.
> 
> Please NOTE!!!! You must do a make mrproper when sync up our tree or use
> a free tree with ruby ontop. Otherwise you will have problems. I did. This
> week I'm going to start working on ruby at work in the next few days so
> much more coding will be done :-) 
> 

Good news, it almost worked on my PC. But without smp :(
By almost, I mean that the kernel booted, and X started. Unfortunately, my
PS2 keyboard refused to work.

-- 
Johann Deneux

Synced to 2.4.12

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

I completed the syncing to 2.4.12 and tested it out on my local machine.
It works fine.

Please NOTE!!!! You must do a make mrproper when sync up our tree or use
a free tree with ruby ontop. Otherwise you will have problems. I did. This
week I'm going to start working on ruby at work in the next few days so
much more coding will be done :-) 


P.S
   Anyone try ruby on a IBM thinkpad? I did and the touch pad (PS/2 mouse)
didn't work. Also I had the same problem on a Compaq Laptop. 

Re: Synced to 2.4.10

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

On Fri, 12 Oct 2001, James Simmons wrote:

> > Once this was done, I managed to get the bzImage file compiled.
> > Unfortunately, trying to boot it gave nothing at all. It did not even seem
> > to crash, as it hardly started.
> 
> I will test it tonight.
> 
> > After choosing the version to boot on in grub, the screen went blank. The
> > keyboard did not seem to respond. I do not even remember seeing the
> > "Uncompressing kernel image ..........." message.
> 
> Really strange. 

Depending on my .config, I sometimes manage to get this
message. Sometimes, the system even works "properly" except that I cannot
interact with it (keyboard useless, kernel unable to open initial
consoles)

> > > bi-PII-333 
> 
> Try it without SMP support.

I did, and the same behaviour was observed.

I will try to find out what configurations lead to what errors. This may
take some time however, as the all make mrproper; make xconfig; make
dep; make bzImage... takes quite some time

-- 
Johann Deneux

Near future

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

I will sync everything up to 2.4.12 tomorrow. Also 2.5.X will be coming
out soon. I have talked to my employer and after I finish one more project
at work I will be able to send my time on the console project. This way we
can start intergrating our changes into 2.5.X as soon as it comes out.

Re: Synced to 2.4.10

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

> > Fixed. Thanks for picking these bugs up. 
> > 
> We are not finished, yet ;)
> I had to add a few includes to linux/lib/bust_spinlocks.c (asm/smp.h and
> linux/sched.h). 

Ah!! Okay. I put a new file into CVS. Lets see if that works. 

I also had to replace the atomic_set(&global_irq_lock,
> 0) by global_irq_lock=0 (hmm, is that safe ?). Indeed, atomic_set needs an
> atomic_t, while global_irq_lock is an integer.

You got a good point. Let me look...

Ug! The problem is global_irq_lock is atomic on some platforms and a
spinlock on others. 

> Once this was done, I managed to get the bzImage file compiled.
> Unfortunately, trying to boot it gave nothing at all. It did not even seem
> to crash, as it hardly started.

I will test it tonight.

> After choosing the version to boot on in grub, the screen went blank. The
> keyboard did not seem to respond. I do not even remember seeing the
> "Uncompressing kernel image ..........." message.

Really strange. 

> bi-PII-333 

Try it without SMP support.

> Btw, enabling the debug options in "Kernel Hacking" leads to multiple
> definitions of do_BUG. But I guess I can live with that for now.

Will fix tonight.

Re: Synced to 2.4.10

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

On Mon, 8 Oct 2001, James Simmons wrote:

> 
> > I encountered other problems:
> 
> Fixed. Thanks for picking these bugs up. 
> 
We are not finished, yet ;)
I had to add a few includes to linux/lib/bust_spinlocks.c (asm/smp.h and
linux/sched.h). I also had to replace the atomic_set(&global_irq_lock,
0) by global_irq_lock=0 (hmm, is that safe ?). Indeed, atomic_set needs an
atomic_t, while global_irq_lock is an integer.
Once this was done, I managed to get the bzImage file compiled.
Unfortunately, trying to boot it gave nothing at all. It did not even seem
to crash, as it hardly started.
After choosing the version to boot on in grub, the screen went blank. The
keyboard did not seem to respond. I do not even remember seeing the
"Uncompressing kernel image ..........." message.
The logs show nothing at all, as if the kernel was never booted.

My linux box is a bi-PII-333 on an ASUS P2BD. My keyboard is plugged on a
PS2 port, and my graphic card is a Matrox G200. I guess the rest of the
configuration does not really matter for the moment.
The original 2.4.10 kernel works fairly well.

Btw, enabling the debug options in "Kernel Hacking" leads to multiple
definitions of do_BUG. But I guess I can live with that for now.

-- 
Johann Deneux

Re: New device filesystems

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

On Mon, Oct 08, 2001 at 10:33:30AM -0700, James Simmons wrote:
> Okay. You both have had good arguments about keeping it where it is. By
> shared code I mean the code duplication that might occur between gfxfs and
> inputfs and eventually the others. Of course we could create another
> directory under fs/ to store this code.=20

That's a good point, and has me thinking as well.. there will undoubtedly b=
e a
good chunk of duplicate code (as there already is..) between gfxfs and inpu=
tfs
that could likely be almost entirely shared with the exception of a few sma=
ll
routines. Even things like ramfs (which gfxfs is heavily based off of so fa=
r),
could be shared with some common routines.. Perhaps instead of just sharing
between inputfs and gfxfs we should look at things from the greater scope a=
nd
think about what virtual filesystems in general are going to have in common.
Adding generic dcache routines for dealing with virtual filesystems might be
something to consider. (link, unlink, lookup, mknod, etc, etc, can all be
shared).

> Yes that eventually will happen. It was planned for 2.5.X. I like this to
> be the testing ground for these concepts until it matures and it can
> become it own project.
>=20
Maybe we should look into adding these kind of routines into fs/dcache.c or
perhaps a fs/virtdcache.c? We're going to have to have seperate filesystems
regardless.. making it less painful and reducing code duplication as a whole
seems like the best way to go IMO.

> Okay. Well if you can make it network transparent and have scripts able to
> use it then I have no problem with keeping mmap.
>=20
That'll be the end goal.. llseek() support would be handy as well. Even if =
it
breaks on network transparency (which it shouldn't for any logical reason),=
 it
could still be useful for local usage.

James, I saw you started on some of the inputfs stuff, what are your design
goals/thoughts for it?

Regards,

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

PNP and input problems.

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

It appears they removed the device field in struct isapnp_device_id. Does
anyone know what they replaced them with?

Re: New device filesystems

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

> > The reason for this is one we will add more device filesystems. Second
> > most likely we will see merger of shared code. Where will we place that?
> > 
> 
> Wherever it belongs.  Filesystem drivers have always lived in fs/, why put
> them anywhere else?  It only makes the kernel tree less maintainable and
> cluttered (one of the reasons we've been working on cleaning up the mips/
> and sh/ targets).

Okay. You both have had good arguments about keeping it where it is. By
shared code I mean the code duplication that might occur between gfxfs and
inputfs and eventually the others. Of course we could create another
directory under fs/ to store this code. 

> Are you saying you want every subsystem device in driver/ to have it's
> own filesystem?  Hmm, if that's the case, then we should formalize that
> project and develop it independently of linuxconsole, that seems to be
> outside the scope of what we're working on.  Of course, gfxfs and
> inputfs would stay here until the "devfs2" project matures.

Yes that eventually will happen. It was planned for 2.5.X. I like this to
be the testing ground for these concepts until it matures and it can
become it own project.

> > YEs we will need a /dev/gfx/0/frame1 but you will have to use read and
> > write instead of mmap. This is what Linus wants as pointed out in the
> > discussion between me, him and Viro. 
> 
> I'm on my way to read the thread now, but if you don't have the ability to
> mmap the framebuffer, it'll be a pain to use...  and "what Linus wants"
> shouldn't be the determining factor of functionality, esp. when it hinders
> progress ("....VM....VFS....") :P.
> 
> When I read the thread, I'll be back with more comments :).

Okay. Well if you can make it network transparent and have scripts able to
use it then I have no problem with keeping mmap.

Re: New device filesystems

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

* James Simmons <jsi...@tr...> on Mon, Oct 08, 2001:

> 
> > > LANANA: To Pending Device Number 
> > > 
> > > thread on the kernel mailing list. We basically are build filesystems for
> > > each type of device. This allows us to have more than one file represent a
> > > device instead of the traditional UNIX method of one file to one device.
> > 
> > Hmm, is this on the linux-kernel mailing list?  I don't see any thread with
> > that subject.
> 
> You have to look in the archives around May.

Specifically, May 14th, 2001:

"LANANA: To Pending Device Number Registrants"

http://boudicca.tux.org/hypermail/linux-kernel/2001week20/

M. R.

Re: New device filesystems

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

* James Simmons <jsi...@tr...> on Mon, Oct 08, 2001:

> 
> The reason for this is one we will add more device filesystems. Second
> most likely we will see merger of shared code. Where will we place that?
> 

Wherever it belongs.  Filesystem drivers have always lived in fs/, why put
them anywhere else?  It only makes the kernel tree less maintainable and
cluttered (one of the reasons we've been working on cleaning up the mips/
and sh/ targets).

About shared code, it should go where it's appropiate, if it's a character
device, drivers/char/, an input device, drivers/input/, etc.  That has
nothing to do with filesystem placement.

> 
> Sorry about the confusion. By saying devfs2 I mean a full device
> filesystem. We should call it something else. Any ideas?
> 

Huh?  gfxfs is it's own filesystem, it's already been named.  But Paul has
better arguments for keeping it in fs/.  Are you saying you want every
subsystem device in driver/ to have it's own filesystem?  Hmm, if that's
the case, then we should formalize that project and develop it
independently of linuxconsole, that seems to be outside the scope of what
we're working on.  Of course, gfxfs and inputfs would stay here until the
"devfs2" project matures.

> 
> YEs we will need a /dev/gfx/0/frame1 but you will have to use read and
> write instead of mmap. This is what Linus wants as pointed out in the
> discussion between me, him and Viro. 

I'm on my way to read the thread now, but if you don't have the ability to
mmap the framebuffer, it'll be a pain to use...  and "what Linus wants"
shouldn't be the determining factor of functionality, esp. when it hinders
progress ("....VM....VFS....") :P.

When I read the thread, I'll be back with more comments :).

M. R.

Re: Synced to 2.4.10

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

> I encountered other problems:

Fixed. Thanks for picking these bugs up. 

Re: New device filesystems

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

> > LANANA: To Pending Device Number 
> > 
> > thread on the kernel mailing list. We basically are build filesystems for
> > each type of device. This allows us to have more than one file represent a
> > device instead of the traditional UNIX method of one file to one device.
> 
> Hmm, is this on the linux-kernel mailing list?  I don't see any thread with
> that subject.

You have to look in the archives around May.

Re: New device filesystems

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

> I don't think creating a new directory is a good idea.  What's wrong with
> keeping gfxfs where it is in fs/gfxfs?  What isn't clean about that?

The reason for this is one we will add more device filesystems. Second
most likely we will see merger of shared code. Where will we place that?

> When describing this, please keep
> devfs and gfxfs seperate to reduce confusion.

Sorry about the confusion. By saying devfs2 I mean a full device
filesystem. We should call it something else. Any ideas?

> > For this filesystem to be truly network transparent we also need to remove
> > mmap support as well as ioctl support. Read and write only. 
> 
> Er, these would still be needed for /dev/gfx/0/fb, since they'll be
> translated into the fb_mmap() call (I'm not so sure what llseek would be
> used for, but it would probably be useful in other gfxfs files).

YEs we will need a /dev/gfx/0/frame1 but you will have to use read and
write instead of mmap. This is what Linus wants as pointed out in the
discussion between me, him and Viro. 

Re: New device filesystems

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

On Sun, Oct 07, 2001 at 09:52:26PM -0700, James Simmons wrote:
>    A few commits about the code entered into CVS. I really like to create
> a directory devfs2 and place gfxfs in their. The reason is I like to write
> the inputfs as well. Plus in time we probable will add more device
> classes like sound to this directory. I just like to keep the fs directory
> clean.

Convulting different filesystems with different things in mind into a common
code base doesn't seem like the best way to keep the fs directory "clean".
A good majority of subsystems deal with their own filesystems, it's only a
select few that touch anything in fs/. The usbdevfs for example, is kept fu=
lly
inclusive to the drivers/usb heirarchy. Something similar could be done with
the inputfs (and maybe even the gfxfs) if there was valid reasoning behind
keeping it out of fs/.

Personally, I prefer sticking things where they belong, and fs/ is the logi=
cal
place to dump filesystems, whether they're virtual or not. Think ramfs,
theoretically it's MM bound, but sticking it in mm/ would be appaling.
Likewise, limiting a fs to a subsystem bound directory when there's better
places to put it, are equally disturbing. Hardly the clean image one wants.

Provided there's a good reason for adding a new fs, there's absolutely noth=
ing
wrong with sticking it in fs/. Adding a new fs simply for the purpose of
adding a new fs is another matter entirely, and I don't think that applies =
to
gfxfs or inputfs. Maybe what's really needed is some clarification in the f=
s/
directory to differentiate between virtual filesystems and filesystems that
actually deal with devices. But that's just a cosmetic issue, and is purely=
 a
matter of opinion.

>    The second thing is you have=20
>=20
> struct file_operations gfxfs_file_ops =3D {
>         mmap:           generic_file_mmap,
>         llseek:         generic_file_llseek,
> };
>=20
> For this filesystem to be truly network transparent we also need to remove
> mmap support as well as ioctl support. Read and write only.=20
>=20
ioctl support I don't want either, seeing as how the whole idea is to get
_away_ from the mess of ioctl()'s in the first place. mmap() support has its
uses though.. especially with things like network transparency in mind. It's
not uncommon to want to mmap() the framebuffer (/dev/fb/0), and being able =
to
do so from a remote machine far outweighs any disadvantages to supporting i=
t.
Naturally, we can do our own gfxfs_mmap() incase there's any special concer=
ns
that need addressing.. though I haven't quite gotten that far in development
of the system to really be heavily concerned about mmap/llseek support yet.
(They're just there as generic placeholders, as the comments suggest).

Regards,

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

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 encountered other problems:
1.
in drivers/video/vga.c, line 318:
                spin_unlock_irqrestore(&vga_lock, flags);
vga_lock is not known. I guessed a fix, but I don't know if it works. At
least, it compiles. The fix is to replace &vga_lock by &state->vga_lock.

2.
In lib/bust_spinlocks.c, line 25:
#ifdef CONFIG_SMP
                atomic_set(&global_irq_lock,0);
#endif
global_irq_lock isn't known.

-- 
Johann Deneux

Re: New device filesystems

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

* James Simmons <jsi...@tr...> on Sun, Oct 07, 2001:

> 
> As some might have noticed we are starting work on devices filesystems.
> For those that don't know what this is about look at the 
> 
> LANANA: To Pending Device Number 
> 
> thread on the kernel mailing list. We basically are build filesystems for
> each type of device. This allows us to have more than one file represent a
> device instead of the traditional UNIX method of one file to one device.

Hmm, is this on the linux-kernel mailing list?  I don't see any thread with
that subject.

M. R.

Re: New device filesystems

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

* James Simmons <jsi...@tr...> on Sun, Oct 07, 2001:

> 
>    A few commits about the code entered into CVS. I really like to create
> a directory devfs2 and place gfxfs in their. The reason is I like to write
> the inputfs as well. Plus in time we probable will add more device
> classes like sound to this directory. I just like to keep the fs directory
> clean.

I don't think creating a new directory is a good idea.  What's wrong with
keeping gfxfs where it is in fs/gfxfs?  What isn't clean about that?
That's the standard spot for all vfs drivers and it's self-contained.  Also
(and Paul can explain this better than I can), gfxfs is just a vfs layer
for the fb, it isn't devfs.  You seem to think they're related, when gfxfs
is intended to perform a different role.  When describing this, please keep
devfs and gfxfs seperate to reduce confusion.

IMO, inputfs should go into fs/inputfs as well.

>    The second thing is you have 
> 
> struct file_operations gfxfs_file_ops = {
>         mmap:           generic_file_mmap,
>         llseek:         generic_file_llseek,
> };
> 
> For this filesystem to be truly network transparent we also need to remove
> mmap support as well as ioctl support. Read and write only. 

Er, these would still be needed for /dev/gfx/0/fb, since they'll be
translated into the fb_mmap() call (I'm not so sure what llseek would be
used for, but it would probably be useful in other gfxfs files).

M. R.

New device filesystems

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

As some might have noticed we are starting work on devices filesystems.
For those that don't know what this is about look at the 

LANANA: To Pending Device Number 

thread on the kernel mailing list. We basically are build filesystems for
each type of device. This allows us to have more than one file represent a
device instead of the traditional UNIX method of one file to one device.
As you can image this gives much more power to the driver writer. 
   One advantage to such a design is network transprancy. You can program
devices remotely. This means for example on embedded devices, even a cell
phone, you could have a kernel image a just NFS some machine remotely. On
that remote machine you could program the hardware on the cell phone.
   Another advantage is you could write basic scripts to preform hardware
functions. For example we could do a 

echo "640x480-16@70" > /dev/gfx/card0/mode1



P.S

   A few commits about the code entered into CVS. I really like to create
a directory devfs2 and place gfxfs in their. The reason is I like to write
the inputfs as well. Plus in time we probable will add more device
classes like sound to this directory. I just like to keep the fs directory
clean.
   The second thing is you have 

struct file_operations gfxfs_file_ops = {
        mmap:           generic_file_mmap,
        llseek:         generic_file_llseek,
};

For this filesystem to be truly network transparent we also need to remove
mmap support as well as ioctl support. Read and write only. 

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

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

Excellent, this sounds like a great start. Can you just split off this
file in CVS? Then I can sync up with it and (eventually, once I get my
laptop net card) manually send you the patches.

Sound good?



Adam



On Mon, Oct 08, 2001 at 01:15:38AM +0200, Vojtech Pavlik wrote:
> I have no problem with just adding an hid-ifeel.c driver with reasonable
> hooks into the hid-core and hid-input.
> 
> -- 
> Vojtech Pavlik
> SuSE Labs
> 

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

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

On Thu, Oct 04, 2001 at 08:44:32PM -0400, Adam Goode wrote:
> 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),

You don't need this, if you do b)

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

I have no problem with just adding an hid-ifeel.c driver with reasonable
hooks into the hid-core and hid-input.

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

-- 
Vojtech Pavlik
SuSE Labs