linuxconsole-dev

Re: [linux-fbdev] Is a FontCache worth implementing ?

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

> That's a more generalized _clear + _clear_margins ?

Yes. Also you can use different ROP with rectfill. Right now XOR and COPY
are supported. XOR is used for fbcon_recv.

> better _bmove ? (if only I could get _that_ one to work
> reliably)

Yep.

> > The last function is fb_imageblit
> > which transfers data from host memory to screen memory.
>
> Thats seems new to me (I only know 2.2 and 2.4, as I only grep'ped
> through Ruby). Could be useful...

Yes it is a ruby thing.

>I calculated that for small fonts, just sending the font data may  require
>less register writes than seting up a blit). This is naturally not true
>for bigger fonts (like 32x32 fonts, but do we use that ?)

Well if we want to draw the penguin (80x80) then yes. Image draw and
except any size image. This is a strenght. We don't have to say you can
only use 8,16,32 fonts. You can use any size. This is much more powerful.

MS: (n) 1. A debilitating and surprisingly widespread affliction that
renders the sufferer barely able to perform the simplest task. 2. A disease.

James Simmons  [jsi...@li...]               ____/|
fbdev/console/gfx developer                             \ o.O|
http://www.linux-fbdev.org                               =(_)=
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net

Re: [linux-fbdev] Is a FontCache worth implementing ?

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

>> Using a image blitter you can translate that data from normal RAM to
>> the video card memory. The nice thing about a image blitter is you can
>> do depth translations (mono to depth X).
>
>Yes, that was killed my current (test) implementation : 16 colors
>mean 16 copies of each glyph. Yuck (8 Mb for 512 glyhs, 16x16 32bpp)

I agree with you about the PCI bus. Slow to go over. I want to maximize
fbcon as much as possible. I'm working on the removal of the
console_spinlock so we can use DMA. This will greatly speed up fbcon. I
need to rename that function. The goal is to draw some image. It depends on
the hardware how you approach it. I like to see AGP used by fbcon to do
the transfering of font images to the console. You can even make them
textures if you want. In fact I was thinking of doing that for the voodoo
1 card. It has 4 megs for the framebuffer, 4 megs for register space and 4
megs for texture space. So I could place font data in the texture space.
The big thing I like is the hardware translation from whatever to the
current depth. Some hardware has this seperate. I leave up to the driver
programmer how to approach this problem.

MS: (n) 1. A debilitating and surprisingly widespread affliction that
renders the sufferer barely able to perform the simplest task. 2. A disease.

James Simmons  [jsi...@li...]               ____/|
fbdev/console/gfx developer                             \ o.O|
http://www.linux-fbdev.org                               =(_)=
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net

Re: [linux-fbdev] Is a FontCache worth implementing ?

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

>Well, but mostly the expensive part of it is passing from the system
>memory to the card memory, where the bus is limiting us.

I know. That is why I'm pushing this fbcon to accel-con move.

>but you could use this 64 glyphs as a cache, or something such, uploading
>only the most used chars or something such.
>
>That said, other cards can use standard FB memory for font cache, and
>then either do a blit or a pattern expansion to the screen.

True. You could do this for cards that have the avaliable memory. If fbcon
is running at a resolution that occupies the entire memory then you are in
trouble. You can do many fancy tricks. I leave it up to the driver writer
to be fancy. The goal is to draw some image. Keep in mind I wanted to also
want to have the function draw the penguin. It is very miss leading the
name of the function. It should be drawimage instead. Also for cards that
lack this function a software emulated drawimage has to be done. Could
people post all the possible ways a "fontcache" could work. I see
imagedraw is going to the touchy one.

>What about pattern fills ? Where you provide a bitmap, and the accel
>engine copies this bitmap, putting 1 color for the 1s and another (or
>transparent) for 0s.

Same thing. The goal of the function is to draw some image. How it is
implemented is up to the driver. Another way to do it is make textures of
fonts and using texture mapping to draw the characters. I seen something
like this used for a X server before. The windowing was done with the z
buffer which was used to act like hardware window IDs. Each window then
was textured mapped with whatever the program was trying to display. The
texture map changed when needed. X term wa steh trickiest. Alot of little
texture maps but it still was fast.

MS: (n) 1. A debilitating and surprisingly widespread affliction that
renders the sufferer barely able to perform the simplest task. 2. A disease.

James Simmons  [jsi...@li...]               ____/|
fbdev/console/gfx developer                             \ o.O|
http://www.linux-fbdev.org                               =(_)=
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net

Updates!!

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

I folks. I just wanted to let you know. I fixed the problem with
take_over_console. With the voodoo 3 driver translated to the new api it
works like a charm. I have it running along side mdacon. Now that
take_over_console now works vesafb can be worked on. I haven't tried out
the cfbfillrect and friends function calls yet. Vesafb needs them to work
for fbcon. The idea was to switch in the cfbfillrect and friends one at a
time to test them against what we know works, the native tdfx accel
funtions. If possible I like someone to test out cfbfillrect and that on a
voodoo 3 card if possible or if you are brave with the vesafb driver try
it with it. I want to work on andrew's removal of the console lock patch
this weekend. With this patch it will be possible to have DMA/irq based
fbdev drivers. BTW with in mind brad could you work on a DMA based aty128
driver. I really like to give it a spin. We shoudl both finish at about
the same time I figure. Take a look at the 3dfx driver for a example
driver. Thanks.

MS: (n) 1. A debilitating and surprisingly widespread affliction that
renders the sufferer barely able to perform the simplest task. 2. A disease.

James Simmons  [jsi...@li...]               ____/|
fbdev/console/gfx developer                             \ o.O|
http://www.linux-fbdev.org                               =(_)=
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net

Re: [linux-fbdev] Is a FontCache worth implementing ?

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

On Thu, 8 Mar 2001, Romain Dolbeau wrote:
> James Simmons wrote:
> > Yes. This is the way the ruby tree handles it. I just got it working in
> > the ruby tree. The only problem is their is some bug in take_over_console
> > I have to chase down but I do have fbcon running using a voodoo 3 along
> > side my MDA. There are 3 functions. One is rectfill which does things like
> > clear the margins etc.
> 
> That's a more generalized _clear + _clear_margins ?

Yep, the drawing primitives for a text console are:
  - rectangular fill (clear)
  - rectangular copy (scroll)
  - bitmap expansion (draw characters)

Gr{oetje,eeting}s,

						Geert

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

Re: [linux-fbdev] Is a FontCache worth implementing ?

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

On Thu, 8 Mar 2001, Romain Dolbeau wrote:
> > What kind of fonts are in use anyway, mostly they are 8x8 or 8x16 or somethign
> > such, isn't it, i think there is also the sunc fonts (22x12 or something
> > such).
> 
> 8x16 seems default, 8x8 works with pm3fb. Don't think Sun22x12 are
> supposed
> to work on anything but Sun FB (cg3, cg6, ffb & friends)

Works fine with all fbcon-cfb* drivers, and many accelerated drivers (atyfb,
matroxfb). I'm using it in 1024x768 on my ATI Rage II+.

Gr{oetje,eeting}s,

						Geert

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

Re: [linux-fbdev] Is a FontCache worth implementing ?

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

Sven LUTHER wrote:

> mostly you do expand a bitmap so that all 1s become the foreground color and
> all 0s are either transparent or background color. look at writebitmap and
> cpu2screencolor expansion code in the glint driver. I cannot say more about
> it.

Maybe it won't be needed to tell in the near future :-) :-)

> mmm, i hope you luck on this.

Thanks, maybe it helped :-)

> Well, yes they work nicely on high resolution fbdevs, try reading 8x8 fonts on
> resolutions above 1024x768 on a 15" monitor ...

1024x768 15" is my setup, and 8x8 font are readable IHMO. Not
comfortable,
but I can read them without much effort...

> glyph should bring that donw to 4 32 bit register writes, and 2 for 8x8 fonts.

that would be a win...

-- 
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] Is a FontCache worth implementing ?

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

On Thu, Mar 08, 2001 at 04:56:01PM +0100, Romain Dolbeau wrote:
> Sven LUTHER wrote:
> > On Thu, Mar 08, 2001 at 10:31:12AM +0100, Romain Dolbeau wrote:
> > > Yes, that was killed my current (test) implementation : 16 colors
> > > mean 16 copies of each glyph. Yuck (8 Mb for 512 glyhs, 16x16 32bpp)
> > 
> > Are you trully using color glyphs ?
> 
> No. I was fbcon_cfb32_putc()'ing in offscreen memory on the first
> call, and pm3fb_cfbX_bmove()'ing to put character in place.
> but:
> 
> 1) it doesn't work
> 2) even if it did, that would eat up half my board memory,
>    plus 512bit for the flags (not-yet-written in offscreen)
> 3) I haven't yet tried to check color, so the current implementation
>    would use the color of the first displayed char (OK, it uses less
>    memory that way - but it would look ugly, given that I use
>    color-ls...)
> 
> So I guess that it's not really worth the hassle, there's likely
> a better way.

:)))

> > the glyphs are mostly just a bitmap, you can store them in system or offscreen
> > memory, and after that, do a pattern fill using any color you want for
> > foreground/background
> 
> I have no yet fully understood pattern fill on the pm3

mostly you do expand a bitmap so that all 1s become the foreground color and
all 0s are either transparent or background color. look at writebitmap and
cpu2screencolor expansion code in the glint driver. I cannot say more about
it.

> > or even use the Glyph stuff ...
> 
> I have no clue how to use it properly

Same here ...

> Maybe 3DLabs will answer m  ...(I've tried contacting specific people
> that I believe are in the tech dpt. mail didn't bounce...).

mmm, i hope you luck on this.

> > What kind of fonts are in use anyway, mostly they are 8x8 or 8x16 or somethign
> > such, isn't it, i think there is also the sunc fonts (22x12 or something
> > such).
> 
> 8x16 seems default, 8x8 works with pm3fb. Don't think Sun22x12 are
> supposed
> to work on anything but Sun FB (cg3, cg6, ffb & friends)

Well, yes they work nicely on high resolution fbdevs, try reading 8x8 fonts on
resolutions above 1024x768 on a 15" monitor ...

> > I calculated that for small fonts, just sending the font data may require less
> > register writes than seting up a blit). This is naturally not true for bigger
> > fonts (like 32x32 fonts, but do we use that ?)
> 
> Non-scissored _bmove is 4 register writes on pm3, where a 8x16 font
> seems to need 8 32 bits memory accesses _per rows_ with cfb32, i.e.
> 128 memory acesses. And 32 in cfb8. So I'm still looking
> for a way to do in-FB memory font rendering...

glyph should bring that donw to 4 32 bit register writes, and 2 for 8x8 fonts.

Friendly,

Sven Luther

Re: [linux-fbdev] Is a FontCache worth implementing ?

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

Sven LUTHER wrote:
> On Thu, Mar 08, 2001 at 10:31:12AM +0100, Romain Dolbeau wrote:
> > Yes, that was killed my current (test) implementation : 16 colors
> > mean 16 copies of each glyph. Yuck (8 Mb for 512 glyhs, 16x16 32bpp)
> 
> Are you trully using color glyphs ?

No. I was fbcon_cfb32_putc()'ing in offscreen memory on the first
call, and pm3fb_cfbX_bmove()'ing to put character in place.
but:

1) it doesn't work
2) even if it did, that would eat up half my board memory,
   plus 512bit for the flags (not-yet-written in offscreen)
3) I haven't yet tried to check color, so the current implementation
   would use the color of the first displayed char (OK, it uses less
   memory that way - but it would look ugly, given that I use
   color-ls...)

So I guess that it's not really worth the hassle, there's likely
a better way.

> the glyphs are mostly just a bitmap, you can store them in system or offscreen
> memory, and after that, do a pattern fill using any color you want for
> foreground/background

I have no yet fully understood pattern fill on the pm3

> or even use the Glyph stuff ...

I have no clue how to use it properly

Maybe 3DLabs will answer m  ...(I've tried contacting specific people
that I believe are in the tech dpt. mail didn't bounce...).

> What kind of fonts are in use anyway, mostly they are 8x8 or 8x16 or somethign
> such, isn't it, i think there is also the sunc fonts (22x12 or something
> such).

8x16 seems default, 8x8 works with pm3fb. Don't think Sun22x12 are
supposed
to work on anything but Sun FB (cg3, cg6, ffb & friends)

> I calculated that for small fonts, just sending the font data may require less
> register writes than seting up a blit). This is naturally not true for bigger
> fonts (like 32x32 fonts, but do we use that ?)

Non-scissored _bmove is 4 register writes on pm3, where a 8x16 font
seems to need 8 32 bits memory accesses _per rows_ with cfb32, i.e.
128 memory acesses. And 32 in cfb8. So I'm still looking
for a way to do in-FB memory font rendering...

-- 
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] fbdev minor and major numbers, which file to believe, and other stuff

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

On Thu, Mar 08, 2001 at 09:51:19AM +0100, Geert Uytterhoeven wrote:
> On Thu, 8 Mar 2001, Sven LUTHER wrote:
> > > Ugh...
> > > 
> > > If you use the old minors, you'll see a warning printed on the console.
> > 
> > That's how i noticed this, will be filling a bug against the dbeian makedev
> > package, unless you want to do it. When was this change done (so i can give
> > more advanced info about this).
> 
> Go ahead! The change is about 1 year old. Support for the old minors will
> disappear in early 2.5.x.

Ok, will do it, but err, when i was speaking about the time of the change, i
was asking about kernel versions. Debian is still supporting 2.2.x kernels.
(especially 2.2.10 on apus)

Friendly,

Sven Luther

Re: [linux-fbdev] Is a FontCache worth implementing ?

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

On Thu, Mar 08, 2001 at 10:31:12AM +0100, Romain Dolbeau wrote:
> James Simmons wrote:
> 
> > If you think about it we already have something like that with teh current
> > system execpt instead of it being in card memory it is in system memory.
> 
> The idea was to avoid going over the bus : PCI is slow (in particular
> the sh*tty implementation in my PM7500)
> 
> > Using a image blitter you can translate that data from normal RAM to the
> > video card memory. The nice thing about a image blitter is you can do
> > depth translations (mono to depth X).
> 
> Yes, that was killed my current (test) implementation : 16 colors
> mean 16 copies of each glyph. Yuck (8 Mb for 512 glyhs, 16x16 32bpp)

Are you trully using color glyphs ?

the glyphs are mostly just a bitmap, you can store them in system or offscreen
memory, and after that, do a pattern fill using any color you want for
foreground/background, or even use the Glyph stuff ...

> > I though about using a Glyhp
> > approach. The voodoo 3 card has a pattern buffer for up to 64 Glyphs which
> > can then be very quickly painted on the display. The problem is the
> > console system supports alot more characters than that. In the future I
> > hope even more.
> 
> There's some "glyph" stuff in the pm3, unfortunately, I can only
> get nice little rectangle ATM. Not very useful. I haven't managed
> to get it to use the glyph data I (try to) send :-(

:)))


> If only 3DLabs would distribute the doc :-(

:(((

> > Yes. This is the way the ruby tree handles it. I just got it working in
> > the ruby tree. The only problem is their is some bug in take_over_console
> > I have to chase down but I do have fbcon running using a voodoo 3 along
> > side my MDA. There are 3 functions. One is rectfill which does things like
> > clear the margins etc.
> 
> That's a more generalized _clear + _clear_margins ?
> 
> > Then their is fb_copyarea which copys a area of the
> > screen to another area of the screen.
> 
> better _bmove ? (if only I could get _that_ one to work
> reliably)
> 
> > The last function is fb_imageblit
> > which transfers data from host memory to screen memory.
> 
> Thats seems new to me (I only know 2.2 and 2.4, as I only grep'ped
> through Ruby). Could be useful...
> 
> > This is used to
> > draw the penguin and text. Yes it is simpler to use the accel engine. A
> > good example is the new tdfx driver in the ruby CVS.
> 
> The idea was to avoid the bus ; maybe I'm biased (or totally wrong),
> but the less things go over the bus, the better I feel...

What kind of fonts are in use anyway, mostly they are 8x8 or 8x16 or somethign
such, isn't it, i think there is also the sunc fonts (22x12 or something
such).

I calculated that for small fonts, just sending the font data may require less
register writes than seting up a blit). This is naturally not true for bigger
fonts (like 32x32 fonts, but do we use that ?)

Friendly,

Sven Luther

Re: [linux-fbdev] Is a FontCache worth implementing ?

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

James Simmons wrote:

> If you think about it we already have something like that with teh current
> system execpt instead of it being in card memory it is in system memory.

The idea was to avoid going over the bus : PCI is slow (in particular
the sh*tty implementation in my PM7500)

> Using a image blitter you can translate that data from normal RAM to the
> video card memory. The nice thing about a image blitter is you can do
> depth translations (mono to depth X).

Yes, that was killed my current (test) implementation : 16 colors
mean 16 copies of each glyph. Yuck (8 Mb for 512 glyhs, 16x16 32bpp)

> I though about using a Glyhp
> approach. The voodoo 3 card has a pattern buffer for up to 64 Glyphs which
> can then be very quickly painted on the display. The problem is the
> console system supports alot more characters than that. In the future I
> hope even more.

There's some "glyph" stuff in the pm3, unfortunately, I can only
get nice little rectangle ATM. Not very useful. I haven't managed
to get it to use the glyph data I (try to) send :-(

If only 3DLabs would distribute the doc :-(

> Yes. This is the way the ruby tree handles it. I just got it working in
> the ruby tree. The only problem is their is some bug in take_over_console
> I have to chase down but I do have fbcon running using a voodoo 3 along
> side my MDA. There are 3 functions. One is rectfill which does things like
> clear the margins etc.

That's a more generalized _clear + _clear_margins ?

> Then their is fb_copyarea which copys a area of the
> screen to another area of the screen.

better _bmove ? (if only I could get _that_ one to work
reliably)

> The last function is fb_imageblit
> which transfers data from host memory to screen memory.

Thats seems new to me (I only know 2.2 and 2.4, as I only grep'ped
through Ruby). Could be useful...

> This is used to
> draw the penguin and text. Yes it is simpler to use the accel engine. A
> good example is the new tdfx driver in the ruby CVS.

The idea was to avoid the bus ; maybe I'm biased (or totally wrong),
but the less things go over the bus, the better I feel...

thanks for the answer,

-- 
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] fbdev minor and major numbers, which file to believe, and other stuff

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

On Thu, 8 Mar 2001, Sven LUTHER wrote:
> > Ugh...
> > 
> > If you use the old minors, you'll see a warning printed on the console.
> 
> That's how i noticed this, will be filling a bug against the dbeian makedev
> package, unless you want to do it. When was this change done (so i can give
> more advanced info about this).

Go ahead! The change is about 1 year old. Support for the old minors will
disappear in early 2.5.x.

Gr{oetje,eeting}s,

						Geert

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

Re: [linux-fbdev] fbdev minor and major numbers, which file to believe, and other stuff

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

On Wed, Mar 07, 2001 at 10:17:03PM +0100, Geert Uytterhoeven wrote:
> On Wed, 7 Mar 2001, Sven LUTHER wrote:
> > linux/Documentation/fb/framebuffer.txt says :
> > 
> > By convention, the following device nodes are used (numbers indicate the
> > device minor numbers):
> > 
> >       0 = /dev/fb0      First frame buffer
> >       1 = /dev/fb1      Second frame buffer
> >       ...
> >      31 = /dev/fb31     32nd frame buffer
> > 
> > but linux/Documentation/devices.txt says :
> > 
> >  29 char        Universal frame buffer
> >                   0 = /dev/fb0          First frame buffer
> >                  32 = /dev/fb1          Second frame buffer
> >                 ...
> >                 224 = /dev/fb7          Eighth frame buffer
> > 
> >                 All additional minor numbers are reserved.  
> > 
> > Which one should i believe ? Notice, that on my debian system, MAKEDEV is
> 
> linux/Documentation/fb/framebuffer.txt.
> 
> Or linux/Documentation/devices.txt in 2.4.2-ac13. Linux just throws away all
> patches to change this I sent so far :-(

:(((

> > building fb# conforming to the devices.txt stuff, (makedev version
> > 2.3.1-50.1). this is from unstable (but a few weeks old already).
> 
> Ugh...
> 
> If you use the old minors, you'll see a warning printed on the console.

That's how i noticed this, will be filling a bug against the dbeian makedev
package, unless you want to do it. When was this change done (so i can give
more advanced info about this).

Friendly,

Sven Luther

Re: [linux-fbdev] fbdev minor and major numbers, which file to believe, and other stuff

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

On Wed, 7 Mar 2001, Sven LUTHER wrote:
> linux/Documentation/fb/framebuffer.txt says :
> 
> By convention, the following device nodes are used (numbers indicate the
> device minor numbers):
> 
>       0 = /dev/fb0      First frame buffer
>       1 = /dev/fb1      Second frame buffer
>       ...
>      31 = /dev/fb31     32nd frame buffer
> 
> but linux/Documentation/devices.txt says :
> 
>  29 char        Universal frame buffer
>                   0 = /dev/fb0          First frame buffer
>                  32 = /dev/fb1          Second frame buffer
>                 ...
>                 224 = /dev/fb7          Eighth frame buffer
> 
>                 All additional minor numbers are reserved.  
> 
> Which one should i believe ? Notice, that on my debian system, MAKEDEV is

linux/Documentation/fb/framebuffer.txt.

Or linux/Documentation/devices.txt in 2.4.2-ac13. Linux just throws away all
patches to change this I sent so far :-(

> building fb# conforming to the devices.txt stuff, (makedev version
> 2.3.1-50.1). this is from unstable (but a few weeks old already).

Ugh...

If you use the old minors, you'll see a warning printed on the console.

Gr{oetje,eeting}s,

						Geert

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

fbdev minor and major numbers, which file to believe, and other stuff

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

Hello, ...

I am running pm3fb wrotten by Romain dolbeau in the 2.4.2 kernel, and looking
trough the documentation file, i noticed the following :

linux/Documentation/fb/framebuffer.txt says :

By convention, the following device nodes are used (numbers indicate the
device minor numbers):

      0 = /dev/fb0      First frame buffer
      1 = /dev/fb1      Second frame buffer
      ...
     31 = /dev/fb31     32nd frame buffer

but linux/Documentation/devices.txt says :

 29 char        Universal frame buffer
                  0 = /dev/fb0          First frame buffer
                 32 = /dev/fb1          Second frame buffer
                ...
                224 = /dev/fb7          Eighth frame buffer

                All additional minor numbers are reserved.  

Which one should i believe ? Notice, that on my debian system, MAKEDEV is
building fb# conforming to the devices.txt stuff, (makedev version
2.3.1-50.1). this is from unstable (but a few weeks old already).

Another 2 question i have, concerning the pm3fb fbdev :

  * pm3fb_setup never does get called, altough it is listed in fbmem.c at the
    right place, i think. As a consequence of this all options are ignored.
    What is wrong here ?
			    
  * i have two pm3 on the same board, which both get allocated a fbdev (well
    fb0 and fb1). But all console are still on fb0, and con2fbmap 2 /dev/fb1,
    which should but console 2 (or 3) on /dev/fb1 does nothing ...


Friendly,

Sven Luther

Re: [linux-fbdev] Is a FontCache worth implementing ?

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

On Wed, Mar 07, 2001 at 02:53:17AM -0800, James Simmons wrote:
> 
> >I was wondering if it could be worthwhile (speedwise) to implement
> >a fonctcache for fast character display.
> 
> If you think about it we already have something like that with teh current
> system execpt instead of it being in card memory it is in system memory.
> Using a image blitter you can translate that data from normal RAM to the

Well, but mostly the expensive part of it is passing from the system memory to
the card memory, where the bus is limiting us.

> video card memory. The nice thing about a image blitter is you can do
> depth translations (mono to depth X). I though about using a Glyhp
> approach. The voodoo 3 card has a pattern buffer for up to 64 Glyphs which
> can then be very quickly painted on the display. The problem is the
> console system supports alot more characters than that. In the future I
> hope even more.

but you could use this 64 glyphs as a cache, or something such, uploading only
the most used chars or something such.

That said, other cards can use satndard FB memory for font cache, and then
either do a blit or a pattern expansion to the screen.

That's how X does it at least.
> >fbcon_cfbXX_putc() in ofscreen memory once per character (on-
> >demand, likely), and just _bmove() them to proper place.
> >
> >On the pm3, that would cost 4 memory access to the registers
> >(in PCI memory space) (6 if not properly aligned, for the
> >scissors stuff) plus the hardware copy, compared to whatever
> >fbcon_cfbXX_putc() use.
> >
> >Would that be worth the hassle of adding the fontcache ?
> >(I have no idea what putc() actually cost).
> >
> >Would that be worth adding a more generalized implemetation
> >on top of existing _bmove() so that every hardware-accelerated
> >board could use it ? (those without HW-accel putc(), that is)
> >
> >Is that already planned for the 2.5.x API ? (haven't seen
> >anything to that extent in 'ruby' but I might have
> >overlooked something)
> 
> Yes. This is the way the ruby tree handles it. I just got it working in
> the ruby tree. The only problem is their is some bug in take_over_console
> I have to chase down but I do have fbcon running using a voodoo 3 along
> side my MDA. There are 3 functions. One is rectfill which does things like
> clear the margins etc. Then their is fb_copyarea which copys a area of the
> screen to another area of the screen. The last function is fb_imageblit
> which transfers data from host memory to screen memory. This is used to
> draw the penguin and text. Yes it is simpler to use the accel engine. A
> good example is the new tdfx driver in the ruby CVS.

What about pattern fills ? Where you provide a bitmap, and the accel engine
copies this bitmap, putting 1 color for the 1s and another (or transparent)
for 0s.

Friendly,

Sven Luther

2.4.2 ruby

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

Just to let you know I have synced up the tree with 2.4.2. I as have a new
tdfx driver in CVS that works. The only problem is take_over_console. This
is what was causing the hang for vesafb. I managed to rewrite most of
take_over_console. The problem is update_screen which is oopsing. Have to
figure it out today. I tried fbcon with 3dfx with a pci mach 64 card.
Nope. I need the BIOS to initialize the voodoo 3 card. I plan to start
working on the voodoo 1 card today as it doesn't need the BIOS to
initialize it :-) I have mdacon working fine along side the 3dfx driver
tho. I don't call take_over_console in this case but run the 3dfx driver
as a seperate VT. I had to hack it up to get mdacon to be my admin VT.
Which brings up the next thing. What is the boot console and what takes
over what. Consider the case of where we want vgacon along side fbcon.
then we don't want fbcon taking over. Then sometimes we do.

MS: (n) 1. A debilitating and surprisingly widespread affliction that
renders the sufferer barely able to perform the simplest task. 2. A disease.

James Simmons  [jsi...@li...]               ____/|
fbdev/console/gfx developer                             \ o.O|
http://www.linux-fbdev.org                               =(_)=
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net

Re: [linux-fbdev] Is a FontCache worth implementing ?

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

>I was wondering if it could be worthwhile (speedwise) to implement
>a fonctcache for fast character display.

If you think about it we already have something like that with teh current
system execpt instead of it being in card memory it is in system memory.
Using a image blitter you can translate that data from normal RAM to the
video card memory. The nice thing about a image blitter is you can do
depth translations (mono to depth X). I though about using a Glyhp
approach. The voodoo 3 card has a pattern buffer for up to 64 Glyphs which
can then be very quickly painted on the display. The problem is the
console system supports alot more characters than that. In the future I
hope even more.

>So I was wondering about a good ol' font cache : using regular
>fbcon_cfbXX_putc() in ofscreen memory once per character (on-
>demand, likely), and just _bmove() them to proper place.
>
>On the pm3, that would cost 4 memory access to the registers
>(in PCI memory space) (6 if not properly aligned, for the
>scissors stuff) plus the hardware copy, compared to whatever
>fbcon_cfbXX_putc() use.
>
>Would that be worth the hassle of adding the fontcache ?
>(I have no idea what putc() actually cost).
>
>Would that be worth adding a more generalized implemetation
>on top of existing _bmove() so that every hardware-accelerated
>board could use it ? (those without HW-accel putc(), that is)
>
>Is that already planned for the 2.5.x API ? (haven't seen
>anything to that extent in 'ruby' but I might have
>overlooked something)

Yes. This is the way the ruby tree handles it. I just got it working in
the ruby tree. The only problem is their is some bug in take_over_console
I have to chase down but I do have fbcon running using a voodoo 3 along
side my MDA. There are 3 functions. One is rectfill which does things like
clear the margins etc. Then their is fb_copyarea which copys a area of the
screen to another area of the screen. The last function is fb_imageblit
which transfers data from host memory to screen memory. This is used to
draw the penguin and text. Yes it is simpler to use the accel engine. A
good example is the new tdfx driver in the ruby CVS.

MS: (n) 1. A debilitating and surprisingly widespread affliction that
renders the sufferer barely able to perform the simplest task. 2. A disease.

James Simmons  [jsi...@li...]               ____/|
fbdev/console/gfx developer                             \ o.O|
http://www.linux-fbdev.org                               =(_)=
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net

new cursor

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

I seen a email about hardware cursor support and I have been giving it
alot of thought. It is heavly based on solaris solution and it works
very nice with X windows. The nice thing about this is the state of
the hardware can be changed in one function call. Unlike some of the
problem we see from fb_fix and fb_var being seperate. Here is what I
purpose:

struct fbcurpos {
	__u16 x;
	__u16 y;
};

#define FB_CUR_SETCUR   0x01
#define FB_CUR_SETPOS   0x02
#define FB_CUR_SETHOT   0x04
#define FB_CUR_SETCMAP  0x08
#define FB_CUR_SETSHAPE 0x10
#define FB_CUR_SETALL   0x1F

struct fbcursor {
	__u16 set;  /* For above values. We tell fbdev what data to use. */
	__u16 enable;            /* Turn cursor on/off */
	struct fbcurpos pos;     /* Where the cursor is */
	struct fbcurpos hotspot; /* The cursors hotspot */
	struct fbcmap cmap;	 /* For those colorful cursors */
	struct fbcurpos size;	 /* Its width and height */
	char *image;		 /* Its bitmap */
	char *mask;		 /* Its mask for XORing */
};

So what do you think?

MS: (n) 1. A debilitating and surprisingly widespread affliction that
renders the sufferer barely able to perform the simplest task. 2. A disease.

James Simmons  [jsi...@li...]               ____/|
fbdev/console/gfx developer                             \ o.O|
http://www.linux-fbdev.org                               =(_)=
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net

New patches for console

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

Hi!

  Do to recent changes I will be working on the new fbdev api at home
until I find new work. So Brad ba...@ne... is in charge of the CVS.
Please send him patches. Especially fbdev drivers updated to the new api.
I plan by the end of next week have fbcon working with the new api and
new console system. I will place this in the CVS once I have it working.
Thank you.

Re: Don't forget

[Jon M. T. <ta...@ec...>]

On Thu, 8 Feb 2001, James Simmons wrote:

> Send email to me at jsi...@li...

	I'm gonna have to hold off on that just a few more days, dude.
There is some _seriously_ strange shit going on here at my work, and I
need to figure it out before I'll know whether to jump ship or not.  I do
have to say that your offer is very attractive, though... I'll keep you
posted.

Jon

---
'Cloning and the reprogramming of DNA is the first serious step in 
becoming one with God.'
	- Scientist G. Richard Seed

Don't forget

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

Send email to me at jsi...@li...

job offerings

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

I like to thank all of you for the job offerings. I just I could work for
all of you. Thank very much!!! I will let everyone know by sometime next
week where I will end up.

						James Simmons

time away

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

Do to recent layoffs at SuSE I might not be avaliable for awhile (hint
to the other idstros out there). I will be around to Friday but I don't 
internet service at home so only here and their I will email people.
Thanks.