linuxconsole-dev

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?

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'

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: 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)

[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)

[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, James Simmons wrote:

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

Here is a rough list of the problems I encountered today with the latest
CVS version:
- SMP: compiles, but hangs at boot time. No message can be seen, the
screen just remains black.
- serial code: failed to compile.
gcc -D__KERNEL__ -I/home/sf/linuxconsole/linux/include -Wall
-Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer
-fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2
-march=i686 -DMODULE -DMODVERSIONS -include
/home/sf/linuxconsole/linux/include/linux/modversions.h   -c -o
serial_8250_pci.o serial_8250_pci.c
serial_8250_pci.c:1079: sizeof applied to an incomplete type
serial_8250_pci.c:1079: warning: initialization from incompatible pointer
type
make[2]: *** [serial_8250_pci.o] Error 1

However, I guess this problem may simply be a configuration-related
problems. Why is this file compiled ? I guess it's only needed for
additional serial  ports using a PCI card. If I am right, I do not think I
need this. Where is the option to disable this file ? I do not see
anything PCI-related in the serial driver seection  of the make menuconfig
step.

- matrox frame buffer: failed to compile.

- key repeat: does not work well. Only 2 characters can be repeated. Is it
a bug, or a default behaviour I can change ?
- imPS2: the vertical wheel is inverted (or was it before ?)

I will try to give more details later. Time to sleep now.

-- 
Johann Deneux

Re: pm3fb (was: pm2fb driver)

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

> Here is a rough list of the problems I encountered today with the latest
> CVS version:
> - SMP: compiles, but hangs at boot time. No message can be seen, the
> screen just remains black.

Using VGA console? Must be a locking issue. I'm going to order another CPU
for my system today. 

> - serial code: failed to compile.
> gcc -D__KERNEL__ -I/home/sf/linuxconsole/linux/include -Wall
> -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer
> -fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2
> -march=i686 -DMODULE -DMODVERSIONS -include
> /home/sf/linuxconsole/linux/include/linux/modversions.h   -c -o
> serial_8250_pci.o serial_8250_pci.c
> serial_8250_pci.c:1079: sizeof applied to an incomplete type
> serial_8250_pci.c:1079: warning: initialization from incompatible pointer
> type
> make[2]: *** [serial_8250_pci.o] Error 1
> 
> However, I guess this problem may simply be a configuration-related
> problems. Why is this file compiled ? I guess it's only needed for
> additional serial  ports using a PCI card. If I am right, I do not think I
> need this. Where is the option to disable this file ? I do not see
> anything PCI-related in the serial driver seection  of the make menuconfig
> step.


I see you are trying out the new serial code. Don't enable the new serial
driver stuff. If you don't enable it the old stuff with reappear. That
stuff is experiemental. I will play with it this weekend.

> - matrox frame buffer: failed to compile.

Note ported over to ruby yet. That is a big job which will take several
days to do. 

> - key repeat: does not work well. Only 2 characters can be repeated. Is it
> a bug, or a default behaviour I can change ?

I believe this caused by the code in kd_mksound in vt_ioctl.c. Try
commenting that out and it should work. 

> - imPS2: the vertical wheel is inverted (or was it before ?)

Hm. Vojtech?

Re: pm3fb (was: pm2fb driver)

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

On Sat, Nov 10, 2001 at 01:03:12AM +0100, Johann Deneux wrote:
> On Tue, 6 Nov 2001, James Simmons wrote:
> 
> > 
> > > Should we try to summarize all the problems encountered so far ?
> > 
> > Please do. 
> 
> Here is a rough list of the problems I encountered today with the latest
> CVS version:
> - SMP: compiles, but hangs at boot time. No message can be seen, the
> screen just remains black.
> - serial code: failed to compile.
> gcc -D__KERNEL__ -I/home/sf/linuxconsole/linux/include -Wall
> -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer
> -fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2
> -march=i686 -DMODULE -DMODVERSIONS -include
> /home/sf/linuxconsole/linux/include/linux/modversions.h   -c -o
> serial_8250_pci.o serial_8250_pci.c
> serial_8250_pci.c:1079: sizeof applied to an incomplete type
> serial_8250_pci.c:1079: warning: initialization from incompatible pointer
> type
> make[2]: *** [serial_8250_pci.o] Error 1
> 
> However, I guess this problem may simply be a configuration-related
> problems. Why is this file compiled ? I guess it's only needed for
> additional serial  ports using a PCI card. If I am right, I do not think I
> need this. Where is the option to disable this file ? I do not see
> anything PCI-related in the serial driver seection  of the make menuconfig
> step.
> 
> - matrox frame buffer: failed to compile.
> 
> - key repeat: does not work well. Only 2 characters can be repeated. Is it
> a bug, or a default behaviour I can change ?

Can you describe it more precisely? The key repeat should be the same as
AT keyboards do.

> - imPS2: the vertical wheel is inverted (or was it before ?)

Possible. I've fixed this a couple times already, but because USB and
PS/2 mice disagree about the direction, it tends to get messed up ...

> I will try to give more details later. Time to sleep now.

-- 
Vojtech Pavlik
SuSE Labs

Re: pm3fb (was: pm2fb driver)

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

> > - key repeat: does not work well. Only 2 characters can be repeated. Is it
> > a bug, or a default behaviour I can change ?
> 
> Can you describe it more precisely? The key repeat should be the same as
> AT keyboards do.

I bet it is the mk_sound function problem. I have disabled it in the
current CVS. I really need to fix that. Some who I need to intergrate the 
beeper code and as such both the keyboard and beeper code need their own
repeat rates. At present the input driver for the console system only has
one rate setting.

Re: pm3fb (was: pm2fb driver)

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

On Wed, 14 Nov 2001, James Simmons wrote:

> 
> > > - key repeat: does not work well. Only 2 characters can be repeated. Is it
> > > a bug, or a default behaviour I can change ?
> > 
> > Can you describe it more precisely? The key repeat should be the same as
> > AT keyboards do.
> 
> I bet it is the mk_sound function problem. I have disabled it in the

It seems it was indeed. Now it works.

-- 
Johann Deneux