linuxconsole-dev

Re: pm3fb (was: pm2fb driver)

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

> It seems severql people have problems running a ruby kernel. Perhaps we
> should focus our next efforts on trying to stabilize the existing work.

I agree. We need to pounded out the bugs we have before we continue on. 

> something wrong". Once I managed to compile the beast, it would not
> boot. It thought the same thing again. After that, with the help of James,
> I managed to have ruby mostly working.

Well the problem is heavy tested hasn't been going on. It works on the few
machines I have isn't very good enough. So I really need bug reports and
problems reported. If anyone really wants a go at it I will give them CVS
access as well.

> Should we try to summarize all the problems encountered so far ?

Please do. 

> Who tried ruby, and who succeeded ? Who failed, and why ?

Please do.

Re: pm3fb (was: pm2fb driver)

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

On Tue, 6 Nov 2001, Romain Dolbeau wrote:

> I'm _not_ working on offb/matroxfb/controlfb. It's just that
> before I can do anything on pm3fb, I need to be sure that
> Ruby is working on my box, with at least a driver for
> one of my framebuffer. Last time I tried (2.4.12 IIRC),
> a rubyfied kernel wouldn't boot at all.
> 
It seems severql people have problems running a ruby kernel. Perhaps we
should focus our next efforts on trying to stabilize the existing work.
I remember that the first time I tried to get ruby to run, I failed to
compile the tree. I thought "I must be dumb, and I am probably doing
something wrong". Once I managed to compile the beast, it would not
boot. It thought the same thing again. After that, with the help of James,
I managed to have ruby mostly working.

The question is: are there many people giving up after trying ruby,
thinking "I must be dumb" ?

Should we try to summarize all the problems encountered so far ?

Who tried ruby, and who succeeded ? Who failed, and why ?

-- 
Johann Deneux

Re: pm3fb (was: pm2fb driver)

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

James Simmons wrote:

> Okay. So ruby first with offb, matrox. The matrox will be alot of work.
> Since it would be best to run the card in DMA mode it might be better to
> write a whole new driver.

Oups, misunderstanding here I think :-/

I'm _not_ working on offb/matroxfb/controlfb. It's just that
before I can do anything on pm3fb, I need to be sure that
Ruby is working on my box, with at least a driver for
one of my framebuffer. Last time I tried (2.4.12 IIRC),
a rubyfied kernel wouldn't boot at all.

And I have neither the knowledge nor the time to do
the generic ruby or the other drivers work :-(

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

Re: pm3fb (was: pm2fb driver)

[Petr V. <VAN...@vc...>]

On  5 Nov 01 at 12:15, James Simmons wrote:
> > > As for the struct fb_var_screeninfo we can do what I show in skeletonfb.c:
> > 
> > I think I'll wait until I can get first ruby then offb or matroxfb
> > to work on pm3fb (I have an old millenium next to the pm3 now) ; I
> > can't test anything right now...
> 
> Okay. So ruby first with offb, matrox. The matrox will be alot of work.
> Since it would be best to run the card in DMA mode it might be better to
> write a whole new driver. 

Please do some test of speed before you start coding. Last time I played 
with DMA it was much slower than using Matrox command queue, and older 
chips do not do DMA at all, so you must still keep old code somewhere
around.

Except rectangle fill (which happens rarely) and large bitblt (which
also happens rarely if you are using yres != vyres) all other
commands are completed before you can even check accelerator state
on G4x0/G550 hardware.
                                            Best regards,
                                                Petr Vandrovec
                                                van...@vc...
                                                

Re: pm3fb (was: pm2fb driver)

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

> > As for the struct fb_var_screeninfo we can do what I show in skeletonfb.c:
> 
> I think I'll wait until I can get first ruby then offb or matroxfb
> to work on pm3fb (I have an old millenium next to the pm3 now) ; I
> can't test anything right now...

Okay. So ruby first with offb, matrox. The matrox will be alot of work.
Since it would be best to run the card in DMA mode it might be better to
write a whole new driver. 

> No, because I have no idea how to use DMA. I don't have docs
> for the chip, I can only read pm2fb and reverse-engineer
> the XFree86 driver. Formac can't distribute 3Dlabs doc,
> and 3Dlabs apparently doesn't want to hand me the docs
> (I almost got them, but they suddenly stopped answering
> mail and never send the updated NDA).

Oh. That is sad.

Re: New web site

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

> > I have nearly finished up a new version of our web site. You can see it at
> > http://linuxconsole.sf.net/new. Feedback is welcomed. Yes I know some of
> > picture links are broken. I welcome any contributes.
> 
> </lurk>
> 
> Not just the images, the whole site is broken ;p
> I just get a 404....
> 
> James Gibson
> 
> <lurk>

Sorry. After much work this weekend I moved the site to the live web site. 
It now is at http://linuxconsole.sf.net.

Re: New web site

[James G. <twi...@su...>]

On Sat, 3 Nov 2001, James Simmons wrote:

>
> I have nearly finished up a new version of our web site. You can see it at
> http://linuxconsole.sf.net/new. Feedback is welcomed. Yes I know some of
> picture links are broken. I welcome any contributes.

</lurk>

Not just the images, the whole site is broken ;p
I just get a 404....

James Gibson

<lurk>

pm3fb (was: pm2fb driver)

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

James Simmons wrote:

> Looking over the driver the biggest change you could do is get ride of
> struct pm3fb_info. Stuff that is not in struct fb_info should be placed
> into struct pm3fb_par. We need to add the default struct fb_fix_screeninfo.
> As for the struct fb_var_screeninfo we can do what I show in skeletonfb.c:

I think I'll wait until I can get first ruby then offb or matroxfb
to work on pm3fb (I have an old millenium next to the pm3 now) ; I
can't test anything right now...

> P.S
>         Have you considered using the DMA mode of this driver now that
> console sem is in place?

No, because I have no idea how to use DMA. I don't have docs
for the chip, I can only read pm2fb and reverse-engineer
the XFree86 driver. Formac can't distribute 3Dlabs doc,
and 3Dlabs apparently doesn't want to hand me the docs
(I almost got them, but they suddenly stopped answering
mail and never send the updated NDA).

-- 
DOLBEAU Romain               | We'll know for the first time              
ENS Cachan / Ker Lann        |     If we're evil or divine                
Thesard IRISA / CAPS         |          -- Dio,                           
dol...@cl...    |             'The Last In Line'

New web site

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

I have nearly finished up a new version of our web site. You can see it at
http://linuxconsole.sf.net/new. Feedback is welcomed. Yes I know some of
picture links are broken. I welcome any contributes.

Re: Dreamcast stuff

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

> a total rewrite is definately in order..

Good. Remeber you can make it full blown DMA based. 


> > P.S
> >    Since the web pages are being redone any suggestions from the crowd!!!!
> 
> I suggest we follow a similar approach that linux-mips uses. Simplistic yet
> half-way informative, with links to things of interest. There really isn't a
> need for anything past that in my opinion.. An updated list of who's doing
> what might be useful as well..

Working on it as you can see by CVS check ins. 

Re: Dreamcast stuff

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

> Regarding the import of the Dreamcast Maple input drivers and pvr2fb
> framebuffer, well, you should've consulted the maintainers of these files
> before importing.  

Oops. Sorry about that. 

> If you want Ruby to handle Dreamcast input fine, a little later this evening
> I'll pull out Yaegashi's Maple core and replace it with Paul's instead.
> Unless of course, you or Paul want to beat me to it :P.

Go for it. I will be busy redoing are web pages and adding actually 
documents!!!! Yes folks you will be able to understand what is going on. 

P.S
   Since the web pages are being redone any suggestions from the crowd!!!!

Dreamcast stuff

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

James,

Regarding the import of the Dreamcast Maple input drivers and pvr2fb
framebuffer, well, you should've consulted the maintainers of these files
before importing.  Yes, I know I've pledged to work on pvr2fb stuff for
ruby, but the Maple code by Yaegashi *does not* belong.

The latest and official place for Dreamcast drivers (input or otherwise) is
the linux-sh-dc CVS tree at sf.net/projects/linuxdc.  It's a drop-in tree
against the linux (or kernel) CVS tree at sf.net/projects/linuxsh.  Paul
Mundt has begun the work on revamping the Maple input core, and you'll find
his work in the linux-sh-dc tree.

If you want Ruby to handle Dreamcast input fine, a little later this evening
I'll pull out Yaegashi's Maple core and replace it with Paul's instead.
Unless of course, you or Paul want to beat me to it :P.

M. R.

New docs section in CVS.

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

To end the mystery which is ruby I have added a directory called docs
which will contain info on what we are doing and how to write various
drivers. Feel free to add stuff there, improve my docs and others docs. 
I'm not the worlds greatest doc writer. We need feedback to make really
great docs.  

P.S
   The web site will have a face lift soon. I have added a directory to
CVS for this, web. Feel free to edit it as well. I'm attempting to put the
docs their.

pm2fb driver

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

Looking over the driver the biggest change you could do is get ride of
struct pm3fb_info. Stuff that is not in struct fb_info should be placed
into struct pm3fb_par. We need to add the default struct fb_fix_screeninfo. 
As for the struct fb_var_screeninfo we can do what I show in skeletonfb.c:

mode_option = "640x480@60";

P.S
	Have you considered using the DMA mode of this driver now that
console sem is in place?

Back to working on ruby

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

Hi folks!!

	I'm back to working on the ruby tree for some time. At work I have
to work on the iPAQ so I'm using it as a excuse to work on ruby, on a iPAQ.

Re: info on gfxfs

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

On Sun, Oct 21, 2001 at 06:12:59PM -0400, cw...@so... wrote:
> After reviewing the console archives over the month of october, we have s=
een=20
> how much has really happened (more than we expected :^)  however, we havn=
't=20
> seen many details as to what is actually going into the fs, other than fb=
,=20
> frameN, cmap, mode, and perhaps a few other things.  is there a standard =
list=20
> of items in there, and is there any information on what they do/how to us=
e=20
> them?  if nothing else, we would like to become familiar with this featur=
e and=20
> document it to help others put it to good use.
>=20
For the time being, it'll work as a drop-in replacement for the ioctl()
interfaces. (which is where things like cmap/mode/etc. come in). The FS
exports a few symbols that can be used by other drivers (fbmem.c will deal
with the most of the cruft), and people will be able to register new entries
with the filesystem for their own purposes.

In all honesty, a lot of this kind of stuff could be abstracted out into an
"ioctlfs" to reduce code duplication.. especially when we start working on
things like the inputfs.. it might make more sense to just fork the stuff i=
nto
an ioctlfs and then deal with gfxfs and inputfs afterwards, and simply have
them calling hooks from the ioctlfs.

The base idea behind it is you have a registered device which you are grant=
ed
a directory for.. in that directory you have dentrys for your various frame
buffers, cmap, mode, and all the regular ioctl stuff. At the time of
registration, you simply setup your customized read/write routines that you
want to be dealt with as a callback on the dentrys, and hand a pointer to t=
he
structure with the function pointers in it off to the registration routine.
This then inserts the data into a private location so it can be referenced
later (inode->u.generic_ip for example).

fbmem.c will deal with all the core stuff initially.. but if you have your =
own
particular needs, you can simply write a driver that sets up some read/write
routines, registers them with its entry, and then gets invoked when operati=
ons
on the dentry happen.

I'm still tinkering with the gfxfs, though I'm leaning more and more towards
the idea of abstracting things out as an "ioctlfs" and simply having gfxfs
utilize that.. inputfs could then do the same. As the API and such gets
refined and to a point of useability, I'll write documentation on it so oth=
ers
can play with it.

> also, /dev/gfx seems to be a standard device for linux/irix on sgi boxes=
=20
> [iirc].  is creating this fs with the same name going to cause a conflict?
>=20
Right:

                148 =3D /dev/gfx          Linux/SGI graphics effects device

and on IRIX:

crw-rw-rw-   1 root     sys       10,  56 Oct 21 15:58 /dev/gfx

I suppose that could cause some issues, but at the same time, it's just a
mountpoint.. the gfxfs can really be mounted just about anywhere. I'd sugge=
st
keeping /dev/gfx for the mountpoint and trying to get /dev/gfx changed to
something more meaningful like /dev/sgigfx in the case of the graphics effe=
cts
device..

Regards,

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

info on gfxfs

[<cw...@so...>]

Hello yet again!

After reviewing the console archives over the month of october, we have seen 
how much has really happened (more than we expected :^)  however, we havn't 
seen many details as to what is actually going into the fs, other than fb, 
frameN, cmap, mode, and perhaps a few other things.  is there a standard list 
of items in there, and is there any information on what they do/how to use 
them?  if nothing else, we would like to become familiar with this feature and 
document it to help others put it to good use.

also, /dev/gfx seems to be a standard device for linux/irix on sgi boxes 
[iirc].  is creating this fs with the same name going to cause a conflict?

thanks for your patience =), sorry to be so annoying around here =(
Chris

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

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

On Wed, Oct 17, 2001 at 08:23:43PM -0700, Chip Salzenberg wrote:

> 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


The correct lines should look like this:

sprintf(atkbd->phys, "%s/input0", serio->phys);

It's in the CVS, anyway.

> 
> Index: drivers/char/atkbd.c
> --- drivers/char/atkbd.c.old	Wed Oct 17 13:36:43 2001
> +++ drivers/char/atkbd.c	Wed Oct 17 19:13:57 2001
> @@ -493,5 +493,5 @@
>  		sprintf(atkbd->name, "AT Set %d keyboard", atkbd->set);
>  
> -	sprintf(atkbd->phys, "%s/input0\n");
> +	sprintf(atkbd->phys, "/dev/serio%d", serio->number);
>  
>  	if (atkbd->set == 3)
> 
> Index: drivers/char/psmouse.c
> --- drivers/char/psmouse.c.old	Wed Oct 17 13:36:43 2001
> +++ drivers/char/psmouse.c	Wed Oct 17 19:14:11 2001
> @@ -609,5 +609,5 @@
>  	sprintf(psmouse->devname, "%s %s %s",
>  		psmouse_protocols[psmouse->type], psmouse->vendor, psmouse->name);
> -	sprintf(psmouse->phys, "%s/input0\n");
> +	sprintf(psmouse->phys, "/dev/serio%d", serio->number);
>  
>  	psmouse->dev.name = psmouse->devname;
> 
> Index: drivers/char/xtkbd.c
> --- drivers/char/xtkbd.c.old	Wed Oct 17 13:36:43 2001
> +++ drivers/char/xtkbd.c	Wed Oct 17 19:14:07 2001
> @@ -115,5 +115,5 @@
>  	clear_bit(0, xtkbd->dev.keybit);
>  
> -	sprintf(xtkbd->phys, "%s/input0\n");
> +	sprintf(xtkbd->phys, "/dev/serio%d", serio->number);
>  
>  	xtkbd->dev.name = xtkbd_name;


-- 
Vojtech Pavlik
SuSE Labs

Re: Synced to 2.4.12

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

> It indeedd works better. Howeverr, it is still not perrfect. As yoou may
> notice, the key-repeat behaves quite oddly. It is disabledd when I try to
> use it, but some characters are sometimes reepeated more than the
> intenddeed  amount (I am using the linuxconsole tree right now). But at
> least I am making some progress  ;)

I haven't figured it out yet. kbd_rate sets the type rate but it uses
ioperm to change those values. It directly playes with the hardware. So I
moved it out of the way to prevent that. Something else is accessing the
ioctl call for the console system to change the the keyboard rates. I did
change the code for that ioctl to use the input api. Unfortunely theri is
a annoying bug in the code. That has to be worked out anyways since you
have for the console system do things you can set the repeat rate for. The
beep noise and the keyboard. I think it is getting confussed between the
two. Okay off to finish my white paper on the console project. Yes I'm
writing a white paper to explain everything that has been done so far.

Re: Synced to 2.4.12

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

On Thu, 18 Oct 2001, James Simmons wrote:

> 
> > Attached is the .config I used. 
> 
> I see the problem. You have to select one of the controllers. For the PC
> it should be "i8042 aux+kbd controller". The i8042 chipset is used on alot
> of platforms. Each platform is a little different so we have hooks from
> serio to help handle these differences.  
> 
It indeedd works better. Howeverr, it is still not perrfect. As yoou may
notice, the key-repeat behaves quite oddly. It is disabledd when I try to
use it, but some characters are sometimes reepeated more than the
intenddeed  amount (I am using the linuxconsole tree right now). But at
least I am making some progress  ;)

-- 
Johann Deneux

Re: Synced to 2.4.12

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

> > Ah!! Yes it is to disable irqs. I will have to disable it. I really wish
> > global_irq_lock was universal on all platforms. Its not :-(  I will commit
> > it out.
> 
> But isn't it needed ?

Hm. The problem is some serial drivers do a __global_irq_lock. It is only
a issue when the kernel oops.

> Attached is the .config I used. 

I see the problem. You have to select one of the controllers. For the PC
it should be "i8042 aux+kbd controller". The i8042 chipset is used on alot
of platforms. Each platform is a little different so we have hooks from
serio to help handle these differences.  

Re: Synced to 2.4.12

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

On Thu, 18 Oct 2001, James Simmons wrote:

> 
> > > 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 ?
> 
> Ah!! Yes it is to disable irqs. I will have to disable it. I really wish
> global_irq_lock was universal on all platforms. Its not :-(  I will commit
> it out.

But isn't it needed ?

> > 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. 
> 
> True. It is USB centeric but the PS/2 keybaord should still behave as a
> USB keyboard. 
> 
> > 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 ?
> 
> It should behave the same as a USB keyboard. Since X uses the console in
> raw mode for keyboard input it should behave the same. You don't need to
> do anything special. What is your configuration?
>

Attached is the .config I used. If you meant to ask about my hardware, I
am afraid I have no idea what kind of PS2 keyboard it is. I did not even
know there were several kinds. I tried to enable "XT keyboard" and "AT and
PS/2 keyboards" separately and then together in section "PS/2 port input
devices". No success so far.

-- 
Johann Deneux

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

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

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

Oops. It was a quick fix to deal with the extra field we have in struct
serio whcih is not in the standard kernel. Thank you for the fix. 

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

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

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

Well originally the only serial input devices where joysticks. As time
goes on this is not true any longer. We have several non joystick serio
based devices in CVS. Plus we use the serio setup for non serial but PIO 
type input devices. PS/2 is a good example of such hardware. So yes I
agree serio.c and serport.c should be moved into drivers/input. I had this
problem when developing the h3600 touchscreen driver for the iPAQ using
the input api.

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

Actually I like to see all input devices in drivers/input but last time I
suggested that it was shot down. In time they will be moved there. Either
that or drivers/char will be 95% input drivers.

Re: Synced to 2.4.12

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

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

Ah!! Yes it is to disable irqs. I will have to disable it. I really wish
global_irq_lock was universal on all platforms. Its not :-(  I will commit
it out.

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

True. It is USB centeric but the PS/2 keybaord should still behave as a
USB keyboard. 

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

It should behave the same as a USB keyboard. Since X uses the console in
raw mode for keyboard input it should behave the same. You don't need to
do anything special. What is your configuration?