linux-fbdev-devel — linux-fbdev mailing list for project developers

Re: [Linux-fbdev-devel] Re: fbcon slowness [was NTP on 2.4.2?]

[<ebi...@xm...>]

James Simmons <jsi...@li...> writes:

> >>> As long as you are copying in real memory. So the PCI bus or the host
> bridge
> >>> implementation may be the actual limit.
> >>
> >> The CyrixIII sits on the same host bridges as the intel processors
> >
> >I don't know if it applies to this case but one thing I have seen make
> >a noticeable difference is whether or not write-combining is enabled.
> >If we have only be enabling MTRR's for intel this could do account
> >for it.
> 
> I think what Geert was trying to point out is does MTRR perform was well
> with normal memory over bus to video memory transfers as compared to
> normal memory to normal memory transfers. MTTRs might not be optimzed for
> these kinds of transfers. I honestly can't say since I haven't tried it. I
> brought the MMX book home from works so I'm going to be experimenting
> with it this weekend to find out. I really like to compare the MMX
> performance to the word aligned transfers over the bus I have going. I had
> a bug in my soft accel code that prevented word alignment. Once I fixed
> that bug I seen a 10 fold improvement in rendering on the framebuffer.
> I'm not kidding about that improvement either :-)
> 
> MTTRs enabled always makes a difference. I liek to try it with and
> without. I will do some benchmarkings.

While I'm thinking about it what we really should be using is the PAT
extension and not MTRR's.  The PAT extension allows you to set the
attributes per page so you don't have the resource contention you do
with MTRR's.  I can just imagine the performance challenges right now
if you try to do a multi-head where multi > number of free MTRR's.

What happens with write-combining is active is that close adjacent
writes are batched together.  Without write-combining you tend to get
32bit writes on a bus with a word size of 64 or more bits.  By the way
does anyone know who didn't implement MTRR's or the equivalent on
alpha so we can shoot them?

Eric

[Linux-fbdev-devel] Re: [linux-fbdev] Frame buffer for a ati rage card on a IBM Walnut

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

>So you have to do that initialization yourself. Which is indeed quite
>hard without help from ATI :-(

Hum. More ammo to get ATI to give us the much needed docs. Please forward
this to ATI.


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-devel] Re: fbcon slowness [was NTP on 2.4.2?]

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

>>> As long as you are copying in real memory. So the PCI bus or the host
bridge
>>> implementation may be the actual limit.
>>
>> The CyrixIII sits on the same host bridges as the intel processors
>
>I don't know if it applies to this case but one thing I have seen make
>a noticeable difference is whether or not write-combining is enabled.
>If we have only be enabling MTRR's for intel this could do account
>for it.

I think what Geert was trying to point out is does MTRR perform was well
with normal memory over bus to video memory transfers as compared to
normal memory to normal memory transfers. MTTRs might not be optimzed for
these kinds of transfers. I honestly can't say since I haven't tried it. I
brought the MMX book home from works so I'm going to be experimenting
with it this weekend to find out. I really like to compare the MMX
performance to the word aligned transfers over the bus I have going. I had
a bug in my soft accel code that prevented word alignment. Once I fixed
that bug I seen a 10 fold improvement in rendering on the framebuffer.
I'm not kidding about that improvement either :-)

MTTRs enabled always makes a difference. I liek to try it with and
without. I will do some benchmarkings.

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

[Linux-fbdev-devel] Re: console.c unblank_screen problem

[Benjamin H. <be...@ke...>]

>
>Thanks for this patch. I've been using it on my Dell Latitude laptop
>for the last 10 days, and it has been a significant improvement.
>
>Before the patch: After a few days with a 2.4 kernel and RH7.0
>(XFree86-4.0.1-1 and XFree86-SVGA-3.3.6-33) the latop would
>misbehave at a resume event: when I opened the lid the screen would
>unblank and then after less than a second the entire screen would
>shift (wrap/rotate) left by about 40% of its width. Restarting X
>would only fix this temporarily, as the next resume would have the
>same problem. This does not occur with a 2.2 kernel or with the
>Accelerated-X server I used before.
>
>With the patch: No problem after 10 days with frequent suspend/resume
>cycles. (2.4.2-ac24 + the patch)
>
>[Alan, mind putting this in the next 2.4.3-ac? I've rediffed it
>against 2.4.3-ac2.]

Glad to get some feedback !

I'm still getting other problems related to console.c power management
however. On the PowerBook, occasionally, if suspend is triggered from
a text console, the machine may hang during the sleep process. I don't
quite understand that code in console.c anyway since it seems to trigger
a timer to later call the VESA blank. That timer thing doesn't makes much
sense to me, especially since when the timer fire (if it ever fires),
the machine will probably be sleeping. 

The problem with it on powerbooks is that we do suspend the graphic chip
from fbdev layer (later on).
So if after this timer expires, the console code tries to access the chip
in any way, bad things will happen (it will die).

I'm working on workaround at the fbdev level, but I'm curious to know
if that PM code in console.c is useful at all in it's current form,
especially since it plays those tricks with timers which don't seem like
a good idea when the machine is going to sleep.

Ben.

[Linux-fbdev-devel] Re: console.c unblank_screen problem

[Mikael P. <mi...@cs...>]

On Sun, 25 Mar 2001 18:40:03 +0200, Benjamin Herrenschmidt wrote:

>There is a problem with the power management code for console.c
>
>The current code calls do_blank_screen(0); on PM_SUSPEND, and
>unblank_screen() on PM_RESUME.
>
>The problem happens when X is the current display while putting the
>machine to sleep. The do_blank_screen(0) code will do nothing as
>the console is not in KD_TEXT mode.
>However, unblank_screen has no such protection. That means that
>on wakeup, the cursor timer & console blank timers will be re-enabled
>while X is frontmost, causing the blinking cursor to be displayed on
>top of X, and other possible issues.
>
>I hacked the following pacth to work around this. It appear to work
>fine, but since the console code is pretty complex, I'm not sure about
>possible side effects and I'd like some comments before submiting it
>to Linus:

Thanks for this patch. I've been using it on my Dell Latitude laptop
for the last 10 days, and it has been a significant improvement.

Before the patch: After a few days with a 2.4 kernel and RH7.0
(XFree86-4.0.1-1 and XFree86-SVGA-3.3.6-33) the latop would
misbehave at a resume event: when I opened the lid the screen would
unblank and then after less than a second the entire screen would
shift (wrap/rotate) left by about 40% of its width. Restarting X
would only fix this temporarily, as the next resume would have the
same problem. This does not occur with a 2.2 kernel or with the
Accelerated-X server I used before.

With the patch: No problem after 10 days with frequent suspend/resume
cycles. (2.4.2-ac24 + the patch)

[Alan, mind putting this in the next 2.4.3-ac? I've rediffed it
against 2.4.3-ac2.]

/Mikael


--- linux-2.4.3-ac2/drivers/char/console.c.~1~	Wed Apr  4 12:15:28 2001
+++ linux-2.4.3-ac2/drivers/char/console.c	Wed Apr  4 12:29:01 2001
@@ -2713,12 +2713,16 @@
 		printk("unblank_screen: tty %d not allocated ??\n", fg_console+1);
 		return;
 	}
+	currcons = fg_console;
+	if (vcmode != KD_TEXT) {
+		console_blanked = 0;
+		return;
+	}
 	console_timer.function = blank_screen;
 	if (blankinterval) {
 		mod_timer(&console_timer, jiffies + blankinterval);
 	}
 
-	currcons = fg_console;
 	console_blanked = 0;
 	if (console_blank_hook)
 		console_blank_hook(0);

Re: [Linux-fbdev-devel] Re: fbcon slowness [was NTP on 2.4.2?]

[Jamie L. <lk...@ta...>]

Eric W. Biederman wrote:
> I don't know if it applies to this case but one thing I have seen make
> a noticeable difference is whether or not write-combining is enabled.
> If we have only be enabling MTRR's for intel this could do account
> for it.

And on some laptops, even on Intel MTRRs are not enabled for 2.5M
framebuffers.

-- Jamie

Re: [Linux-fbdev-devel] Alpha blending (fwd)

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

---------- Forwarded message ----------
Date: Tue, 3 Apr 2001 18:03:38 +0200 (CEST)
From: Geert Uytterhoeven <ge...@li...>
To: Scott A McConnell <sam...@co...>
Cc: Geert Uytterhoeven <ge...@li...>
Subject: Re: [Linux-fbdev-devel] Alpha blending

	Hi Scott,

> > That's something different. `transp' in fbdev is about transparency of the
> > screen (for a video underlay or so), not about transparency of objects to be
> > blended together on the screen.
> 
> I must be missing something...
> 
> My understanding of 32-bit color is [RGBA|ARGB] (8888) where A is the Alpha
> channel.
> 
> "Which is generally normalized to 0/1." But does not have to be.
> "The alpha value is used to control the blending, on a pixel-by-pixel basis, of
> two images.
> new pixel = (alpha)(pixel A color) + (1-alpha)(pixel B color)"
> [Video Demystified, by Keith Jack]

That's correct.

> Looking at skeletonfb.c:xxx_setcolreg...
> 
>  if (is_cfb32)  /* RGBA 8888 */
>      ...fbcon_cmap.cfb32[regno] = ((red & 0xff00) << 16) |
>       ((green & 0xff00) << 8) |
>       (blue & 0xff00) |
>       ((transp & 0xff00) >> 8);
> 
> It looks to me like transp = Alpha.  I call the above: pixel by pixel alpha

Yes.

> blending.
> 
> With the above I can support a 32-bit framebuffer and support pixel-by-pixel alpha
> blending.
> Either in software or hardware and the frame buffer API does not prevent me from
> doing this..
> (Yes? No?)
> 
> I assume the answer is Yes.

Note that `pixel A' in your example above is a pixel from the screen. But
there's no `pixel B' in te equation.

`pixel B' is something from a different source, e.g. video underlay.

It's not for generic alpha blending of 2 two pixels.

> Based on the discussion it appears that your main concern is text/console support.

In the kernel, that is.

> I am wondering if a slightly larger scope should be applied. I am trying to
> understand where the line
> on acceleration and other "advanced  graphics" features should be drawn in
> reference to the frame buffer.
> 
> In the past James S. told me everyone is on their own for acceleration/display
> list...
> 
> But there are now three functions in the API that deal with rectangular areas.

Yes, they are there becasue they are the graphics primitives to support a text
console.

> There is a real desire to be able to set alpha values on rectangular regions.
> Perhaps not in a console ;-) but certainly by widget sets and graphic systems like
> Microwindows and X.
> 
> Which is what prompted my question about adding an alpha value to the rectangular
> region functions.
> Think about hardware that can support multiple surfaces, perhaps one is video
> (like you mentioned) and the other is we want to generate text on top of it.  This
> happens on sports programs all the time.  On some if you look close you can even
> see the video behind the text.

Yes, that's already possible with the current API.

> I guess what I am asking is: Can we design an API that provides access to the most
> common 2-D acceleration functions provided by hardware?

The question here is: what is a `common 2-D acceleration function'? You'll
always have hardware that can do more than the `common 2-D acceleration
functions'. It's far from trivial to define `common 2-D acceleration functions'
that provide good performance and are flexible (future hardware?). That's why
we decided not to impose any restriction on acceleration and do it all in
userspace.

And the picture gets even more complex when talking about 3D...

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-devel] Alpha blending (fwd)

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

---------- Forwarded message ----------
Date: Tue, 03 Apr 2001 09:25:17 -0700
From: Scott A McConnell <sam...@co...>
To: Geert Uytterhoeven <ge...@li...>
Subject: Re: [Linux-fbdev-devel] Alpha blending

Geert Uytterhoeven wrote:

>
> That's something different. `transp' in fbdev is about transparency of the
> screen (for a video underlay or so), not about transparency of objects to be
> blended together on the screen.

I must be missing something...

My understanding of 32-bit color is [RGBA|ARGB] (8888) where A is the Alpha
channel.

"Which is generally normalized to 0/1." But does not have to be.
"The alpha value is used to control the blending, on a pixel-by-pixel basis, of
two images.
new pixel = (alpha)(pixel A color) + (1-alpha)(pixel B color)"
[Video Demystified, by Keith Jack]

Looking at skeletonfb.c:xxx_setcolreg...

 if (is_cfb32)  /* RGBA 8888 */
     ...fbcon_cmap.cfb32[regno] = ((red & 0xff00) << 16) |
      ((green & 0xff00) << 8) |
      (blue & 0xff00) |
      ((transp & 0xff00) >> 8);

It looks to me like transp = Alpha.  I call the above: pixel by pixel alpha
blending.

With the above I can support a 32-bit framebuffer and support pixel-by-pixel alpha
blending.
Either in software or hardware and the frame buffer API does not prevent me from
doing this..
(Yes? No?)

I assume the answer is Yes.

Based on the discussion it appears that your main concern is text/console support.

I am wondering if a slightly larger scope should be applied. I am trying to
understand where the line
on acceleration and other "advanced  graphics" features should be drawn in
reference to the frame buffer.

In the past James S. told me everyone is on their own for acceleration/display
list...

But there are now three functions in the API that deal with rectangular areas.
There is a real desire to be able to set alpha values on rectangular regions.
Perhaps not in a console ;-) but certainly by widget sets and graphic systems like
Microwindows and X.

Which is what prompted my question about adding an alpha value to the rectangular
region functions.
Think about hardware that can support multiple surfaces, perhaps one is video
(like you mentioned) and the other is we want to generate text on top of it.  This
happens on sports programs all the time.  On some if you look close you can even
see the video behind the text.

I guess what I am asking is: Can we design an API that provides access to the most
common 2-D acceleration functions provided by hardware?


Thanks for you consideration,

Scott

Re: [Linux-fbdev-devel] Re: fbcon slowness [was NTP on 2.4.2?]

[<ebi...@xm...>]

Alan Cox <al...@lx...> writes:

> > > The MMX memcpy for CyrixIII and Athlon boxes is something like twice the
> > > speed of rep movs. On most pentium II/III boxes the fast paths for rep movs
> > > and for MMX are the same speed
> > 
> > As long as you are copying in real memory. So the PCI bus or the host bridge
> > implementation may be the actual limit.
> 
> The CyrixIII sits on the same host bridges as the intel processors

I don't know if it applies to this case but one thing I have seen make
a noticeable difference is whether or not write-combining is enabled.
If we have only be enabling MTRR's for intel this could do account
for it.

Eric

Re: [Linux-fbdev-devel] Re: [lkml]Re: [lkml]Re: Matrox G400 Dualhead

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

James Simmons wrote:
> >A very neat trick. X can now be ended correctly. Unfortunately, any
> >scrolling on any VT afterwards gives me a corrupted screen - parts of
> >the screen from other VT's are inserted below, or over the cursor
> >position, and at 'half-line' intervals. In typing this email, I've seen
> >it 5 times already.
> >I'm willing to test anything - but the corruption is alway gone after I
> >switch VT's. So getting a screendump is not easy.
> 
> I never have seen this problem before. Petr do you know what it could be?

If you are still running X with enabled DRI, then it is known problem.
When
DRI is enabled in X, mga driver randomly reprograms some Matrox
acceleration
registers (color depth, screen width, byte ordering) - so you must use
same depth and resolution in both X and on console if you are using DRI.
I believe that it is problem which thunder7 sees. I never got reported
that
matroxfb just decided itself in the middle of screen to do something
else,
it was always tracked to X running on (invisible) background, but still
playing with accelerator.
								Petr

P.S.: You can try 'fbset -accel false', but fixing X is better.
Unfortunately,
nobody cares...

RE: [Linux-fbdev-devel] Re: CHIPS drivers

[Mike M. <mi...@ci...>]

Sorry, I just got all these emails. I have shifted
projects, doing the accel work is back burner for me.

Mike

-----Original Message-----
From: Tea Age [mailto:th...@vi...]
Sent: Tuesday, April 03, 2001 10:22 AM
To: Jordan Crouse; Adrian Cox
Cc: Linux Fbdev development list; Mike McQuade
Subject: Re: [Linux-fbdev-devel] Re: CHIPS drivers


>
> At some point, the future may include:
>
> * Accelerator support
May be Mike McQuade <mi...@ci...> is active here?

> * NSC/PAL support (ugh!)
If you connect VGA out rgb with scart in rgb of a tv and join vsync and
hsync
thrugh 2 resisors of i.e. 120 Ohms to csync you should get a syncronized
video on the tv screen (after playing with fbset). This should be possible
with every framebuffer driver supporting tv timings. ctfb does and i810fb
does it also now. I'm sure, matroxfb and many others do also the job.
Programming additional registers for a separate video-out is not that
terrible - the interesting thing here is the interface if you do not like to
use special ioctls.

> * Video input (double ugh!)
see http://www.visuelle-maschinen.de/ctfb/fb/video_in_ct69000/ctvi_0.21/
before starting with that - the code fragments may help a little bit.
>
Thomas

Re: [Linux-fbdev-devel] Re: CHIPS drivers

[Tea A. <th...@vi...>]

>
> At some point, the future may include:
>
> * Accelerator support
May be Mike McQuade <mi...@ci...> is active here?

> * NSC/PAL support (ugh!)
If you connect VGA out rgb with scart in rgb of a tv and join vsync and hsync 
thrugh 2 resisors of i.e. 120 Ohms to csync you should get a syncronized 
video on the tv screen (after playing with fbset). This should be possible 
with every framebuffer driver supporting tv timings. ctfb does and i810fb 
does it also now. I'm sure, matroxfb and many others do also the job. 
Programming additional registers for a separate video-out is not that 
terrible - the interesting thing here is the interface if you do not like to 
use special ioctls.

> * Video input (double ugh!)
see http://www.visuelle-maschinen.de/ctfb/fb/video_in_ct69000/ctvi_0.21/ 
before starting with that - the code fragments may help a little bit.
>
Thomas

Re: [Linux-fbdev-devel] Re: CHIPS drivers

[Jordan C. <jo...@Ce...>]

A tarball of the alpha 2.4.X driver and header file is on my website:

http://cosmic.censoft.com

If I can get a chance later, I will provide a patch against 2.4.2-ac25.  

-----

I also have a contract to provide support for 69000s on two flat panels,
so I am willing to help Adrian as much as possible.

As far as the functionality, I think that we should provide suport for
the following:

* full support for the 69000/69030 on i386 and PPC for both CRT and flat
panel
* provide multihead support for both CRT and flat panels (and a
combination of both)
* Provide simple legacy support for the 65550 family (nothing fancy,
just get the thing to show pretty pictures)

At some point, the future may include:

* Accelerator support 
* NSC/PAL support (ugh!)
* Video input (double ugh!)

Adrian Cox wrote:
> 
> I've got a contract to support a machine with two 69030s supporting two
> monitors and two panels. I'm going to have to merge a lot of this code
> anyway over the next few weeks. So yes, I guess I'm volunteering.
> 
> What do people actually want the driver to do? Should we attempt to
> support the entire Chips/Asiliant range in one driver, or separate out
> the early IO based devices from the later memory mapped devices? I don't
> have access to the earlier devices, so I'll be fumbling in the dark with
> them unless somebody is prepared to mail me a card.
> 
> - Adrian
> 
> _______________________________________________
> Linux-fbdev-devel mailing list
> Lin...@li...
> http://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel

Re: [Linux-fbdev-devel] Re: CHIPS drivers

[Tea A. <th...@vi...>]

On Tuesday 03 April 2001 18:03, Adrian Cox wrote:
> Jordan Crouse wrote:
> > Now what we need is a volunteer to help us get all this stuff merged
> > out.  No matter what we finally come up with, I don't think we should
> > let another kernel release go by
> > without some contributions.
>
> I've got a contract to support a machine with two 69030s supporting two
> monitors and two panels. I'm going to have to merge a lot of this code
> anyway over the next few weeks. So yes, I guess I'm volunteering.
>

Sounds good! 

I could offer some testing on a ct65554 and a ct69000 (intel boxes). 

ctfb0.50 is stable on my ct69000 (last versions not testet on the ct65554). 
Feel free to use the code as you like.

> What do people actually want the driver to do? Should we attempt to
> support the entire Chips/Asiliant range in one driver, or separate out
> the early IO based devices from the later memory mapped devices? I don't
> have access to the earlier devices, so I'll be fumbling in the dark with
> them unless somebody is prepared to mail me a card.
>

If there is no test posibility for old devices the question is already 
anwered.

Thomas

Re:[Linux-fbdev-devel] Alpha blending

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

Okay I see their is some confusion on what anti-aliasing can and can't do.
Warning this email is long.

>I assume the Transp is for Alpha blending.

transp is the fourth color component. What you can do with the alpha value
depends on the blend factors. Durning blending color values of incoming
fragments (source) are combines in some way with the color values of the
corresponding currently stored pixel (destination) in a 2 stage process.
First you state how to compute the source and destination factors. These
factors are RGBA quadruplets which are multipled by each component of the
RGBA values in the source and destination. Then the two set of RGBA
quadruplets are added together. Lets show this mathimatically.

The source blending factor is represented by:

 (Sr,Sg,Sb,Sa)

The destination blending factor is represented by:

 (Dr, Dg, Db, Da)

Now the color of the source is represented by :

 (Rs, Gs, Bs, As)

Color of the destination is represented by:

 (Rd, Gd, Bd, Ad)

So the final blend is :
  (RsSr + RdDr, GsSg + GdDg, BsSb + BdDd, AsSa + AdDa)

Now the blending factors could be alot of things. The most common which
are defined by OpenGL are:

zero:			Source or destination     (0,0,0,0)
one:			Source or destination     (1,1,1,1)
destination color:	Source			  (Rd, Gd, Bd, Ad)
source color:		destination 		  (Rs, Gs, Bs, As)
1-destination color:	source			  (1,1,1,1)-(Rd,Gd,Bd,Ad)
1-source color:		destination		  (1,1,1,1)-(Rs,Gs,Bs,As)
source alpha:		source or destination 	  (As, As, As, As)
1-source alpha:		"		    "	  (1,1,1,1)-(As, As, As, As)
destination alpha:	"		    "	  (Ad, Ad, Ad, Ad)
1-destination alpha:	"		    "	  (1,1,1,1)-(Ad, Ad, Ad, Ad)
alph saturate:		source			  (f,f,f,1);f=min(As, 1-Ad)

What does this all mean?

Well you can do several effects using the right blend factors. Some are:

One way to draw a picture composed of half of one image and half of
another equally blended is have teh source factor equal to one and the
destination factor equal to zero and draw the first image. Then set the
source factor to source alpha and destination factor to 1 - source alpha.
Now draw the second image with alpha set to 0.5. This is the common
example of a blending operation.

Second example is how to blend three objects together. Set the destination
factor to one and the source factor to source alpha. Draw all 3 images
with alpha set to 1/3. Here where the objects don't overlap the brightness
will be 1/3 of it orginal. Where they do they will be 100% of brigtness.

The 3rd example is the paint brush example. Say you want to gradually add
a color. Here we draw the image with a alpha value of say 10 percent and
use source alpha and destination alpha minus one. Just keep appliing the
brush. Here is a good example of where you wnat to use each alpha value in
each pixel if you want to get a gradient of a color change to the picture.

The fourth one is creating a color filter. This allows one to modulate
each color componet. Say you want to filter out 20% of the red out of
a image. You set the source factor to destination color or destination
color minus one and source color or one minus source color for the
destination factor. So now if multiple the red compenent by %80 you will
effectly block out 20% of the red of teh object.

Fifth technique. The classic example of translucent. Say you want to draw
three objects in front of a solid color wall. Farthest object transmits
80%, next closest object transmits 40% and the closest transmit 90 %.
First draw the wall. Next change the source factor to source alpha and teh
destination factor to 1-source alpha. Draw each object with alpha values
to what you want (.8, .4, .9).

The use of nonrectangular raster images (what Scott was talking about).
Also know as the alpha test. This technique is used to draw "3D" objects
with 2D planes. Image you had 2 planes that are 90 degrees to each other.
On each plane you have a image of a tree. Here you assign alpha 0 to the
invisible parts and 1 to the visible parts on each plane. Now the leaves
in one planes are seen behind the transparent parts in the plane closer to
you giving a three appearance.

Othe uses which I will not go into. Anitaliasing fonts and images. Alpha
blending is used for radiosity and ray tracing algorthims to do shortcuts
to speed up rendering. You can do composting and matting techniques with
fully rendered objects. Blah blah. SO I hope that clears how alpha values
are really used. For those of you that play with OpenGL and openGL
drivers gives try these techniques out. They are pretty neat.

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

[Linux-fbdev-devel] Re: CHIPS drivers

[Adrian C. <ad...@hu...>]

Jordan Crouse wrote:

> Now what we need is a volunteer to help us get all this stuff merged
> out.  No matter what we finally come up with, I don't think we should
> let another kernel release go by
> without some contributions.

I've got a contract to support a machine with two 69030s supporting two 
monitors and two panels. I'm going to have to merge a lot of this code 
anyway over the next few weeks. So yes, I guess I'm volunteering.

What do people actually want the driver to do? Should we attempt to 
support the entire Chips/Asiliant range in one driver, or separate out 
the early IO based devices from the later memory mapped devices? I don't 
have access to the earlier devices, so I'll be fumbling in the dark with 
them unless somebody is prepared to mail me a card.

- Adrian

[Linux-fbdev-devel] Re: CHIPS drivers

[Jordan C. <jo...@Ce...>]

Let me tell you what i have so far - I have taken chipsfb.c on 2.4
heavily modified it to provide dual 69000 support, and then
recently merged it with most of Adrian's code (appropriately modified
for 2.4.X of course).  It seems that we have all been doing the same 
work (where was everyone when I was looking for drivers a month and a
half ago??? :-) ), so I would propose that we all get together and
somehow merge what we've got into a very good driver for 2.2.X and 2.4.X
that we can fire off to Linus and Alan Cox and get it in the tree post
haste.

My driver works well with multiple PCI based 69000 devices on a x86
machine.  I haven't touched the flat panel stuff, in part because my
specific project
uses the default BIOS settings, and partly because I don't have a flat
panel to test with.  In theory, I have support to switch modes on the
fly, but that
is completely untested at this point.

I do know that I have 2 serious fbcon problems:

1) - Every time I recompile, the main console gets shifted to the right
some amount.  Everything works well, its just that the entire screen is
shifted to the right.  I didn't think penguins could fly, but mine sure
can... :)
2) - Every once in a while, while running a framebuffer app on a
console, if I switch to an new console, I still get my app drawing on
the console.  That definitely does not happen with VESA.

Anyway, my code may be redundant or it may not, but at this point it 80%
works and it is available. I will post a URL as soon as I can convince
my IT department
to let my machine extend past the firewall.  

Now what we need is a volunteer to help us get all this stuff merged
out.  No matter what we finally come up with, I don't think we should
let another kernel release go by
without some contributions.

Anybody, anybody?

Jordan

Info about chipsfb, asiliantfb, ctfb, video-in-ct69000 - was: Re:[Linux-fbdev-devel] Re: old chipsfb.c

[Tea A. <th...@vi...>]

On Sunday 01 April 2001 16:49, James Simmons wrote:
> We can always seen in a better driver.
>
> >> avaliable at http://www.visuelle-maschinen.de/ctfb
> >
> >Does the driver still work on PowerMac after that one?
>
> Don't know. Has anyone tried it out on other platforms?
>

Hello,

I just uploaded some framebuffer stuff I found on the web in last months.
Check http://www.visuelle-maschinen.de/ctfb/fb

What I know about chipsfb:

There was a chipsfb which did not run on my i386 - ct65554 machine. I could 
not fix the problem also I did not understand anything about framebuffer 
drivers and the register set of the ct65554. So I decided to write my own 
driver. Of course I started with chipsfb, but most of it is gone and 
replaced. Time went by, i improved the driver and adapted it to the ct69000.
Than asiliantfb apeared on the sceene. Adrian Cox and I exchanged some mails 
with plans to merge both drivers - but, you know, we all have lots of other 
jobs and the project never starts. 

On Tuesday 28 November 2000 12:21, Adrian Cox <ap...@ag...> wrote 
concerning asiliantfb:

> I'll probably be doing some more work on the driver in the new year.
> This may include the video input port and some flat panel support. But
> I've been concentrating on other issues recently. I'll probably be doing
> 2.4 then.

On Wednesday 29 November 2000 22:16,  Susan Kleinmann 
<sg...@ne...> wrote:

> This is just to report that I finally did succeed in loading X 4.0.1f on a
> Toshiba 2515 CDS laptop (which has a C&T 69000 graphics chipset), using:
>
> -- Thomas Hohenleitner's ctfb.c framebuffer driver
>    (http://www.visuelle-maschinen.de/ctfb/ctfb0.40.tgz) with
>
> -- a 2.2 kernel configured with:
>    CONFIG_FB=y
>    CONFIG_FBCON_CFB8=m
>    CONFIG_FBCON_CFB16=m
>    CONFIG_FBCON_CFB24=m
>    (and also one has to follow the instructions at the end of ctfb.c,
>    to manually edit drivers/Makefile so that fbgen.o will be generated),
> and
>
> -- an X configuration file with the Device section set as follows:
>
>     Section "Device"
>        Identifier "Generic Graphics Device"
>        Driver     "fbdev"
>        BusID       "pci:0:4:0"
>     EndSection
>
>     The device wasn't properly recognized til I entered the BusID line
> above.
>
>

From Mike McQuade <mi...@ci...>, I got mail (it is from 13. March 2001):

> I am looking into putting some acceleration into the framebuffer
> for the CT69000 part. We are doing large block copies and need some
> speed.

The ctfb verision 0.50 supports now 2.2 and 2.4 kernels. 
You can find it now under 

http://www.visuelle-maschinen.de/ctfb/fb/drivers/ctfb/

There is also asiliantfb and the old chipsfb available.

I did also some work on the video-in part of the ct69000 - yes I grabbed 
pictures. But it came not to a driver. Just a working userland application.
It is availiable under 

http://www.visuelle-maschinen.de/ctfb/fb/video_in_ct69000/

Actually I work with a i810 chipset and my current interest in ctfb is low.

I can not spent too much time in this but I can offer support and help and do 
also some testing, if nesesary. 

Sorry for the long mail.

Thomas

Re: [Linux-fbdev-devel] Re: fbcon slowness [was NTP on 2.4.2?]

[Alan C. <al...@lx...>]

> > The MMX memcpy for CyrixIII and Athlon boxes is something like twice the
> > speed of rep movs. On most pentium II/III boxes the fast paths for rep movs
> > and for MMX are the same speed
> 
> As long as you are copying in real memory. So the PCI bus or the host bridge
> implementation may be the actual limit.

The CyrixIII sits on the same host bridges as the intel processors

[Linux-fbdev-devel] Re:[linux-fbdev] 2.4.2: System clock slows down under load

[Thomas P. <tp...@gm...>]

On Mon, 2 Apr 2001, James Simmons wrote:

> >I would be really glad if vesa fbcon in 2.4 would run without that
> >problem like in all 2.2 kernels i have installed. It is the easiest way
> >to get X and virtual consoles on my S3 graphic card.
>
> I'm working on it. It is a complex fix. BTW I have seen S3 fbdev drivers.
> Which one do you have?
>

I have an S3 964 VLB card with 4MB.

The S3 fbdev seems rather old and was never included in the official
release. If someone use it please mail me. I give it a try if it posssible
to run with 1024x768-16.

For now i will stay with 2.2.18, but please notice me if you got something
new.

Thanks,

Thomas

Re: [Linux-fbdev-devel] Alpha blending

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

On Tue, 3 Apr 2001, Sven LUTHER wrote:
> On Tue, Apr 03, 2001 at 10:24:25AM +0200, Geert Uytterhoeven wrote:
> > On Tue, 3 Apr 2001, Sven LUTHER wrote:
> > > On Tue, Apr 03, 2001 at 10:05:01AM +0200, Geert Uytterhoeven wrote:
> > > > On Tue, 3 Apr 2001, Sven LUTHER wrote:
> > > > > What about anti-aliasing ?
> > > > 
> > > > Anti-aliasing has nothing to do with transparency on non-transparent text
> > > > consoles.
> > > 
> > > Err, it was my understanding that you use the alpha channel to do
> > > anti-aliasing, even if in the end you don't support transparency, but then i
> > > may be wrong, (mmm, maybe i am).
> > 
> > Yes, for an object that still has to be blended with a background image.
> > 
> > But since a text console has a solid background, you can calculate the
> > resulting RGB values directly:
> > 
> >     [rgb]_res = [rgb] * a + [rgb]_bg * (1-a)
> > 
> > This is indeed equivalent with alpha blending a pixel with transparency a to a
> > solid background pixel.
> 
> Ok, i see that, but what about hardware supported anti-aliasing/alpha
> blending. will providing the value to the chip and let it do stuff not be
> faster (especially as some more advanced chip don't know about 24bpp, treating
> it as 32bpp and ignore the 8bit of the alpha channel ?

For anti-aliased fonts, you either have to use larger fonts (to be downscaled
by hardware), or store pre-anti-aliased fonts at the normal size, but including
an alpha value. For an 8-bit alpha value, this increases storage size by a
factor of 8, compared to monochrome bitmaps.

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-devel] Alpha blending

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

On Tue, Apr 03, 2001 at 10:24:25AM +0200, Geert Uytterhoeven wrote:
> On Tue, 3 Apr 2001, Sven LUTHER wrote:
> > On Tue, Apr 03, 2001 at 10:05:01AM +0200, Geert Uytterhoeven wrote:
> > > On Tue, 3 Apr 2001, Sven LUTHER wrote:
> > > > What about anti-aliasing ?
> > > 
> > > Anti-aliasing has nothing to do with transparency on non-transparent text
> > > consoles.
> > 
> > Err, it was my understanding that you use the alpha channel to do
> > anti-aliasing, even if in the end you don't support transparency, but then i
> > may be wrong, (mmm, maybe i am).
> 
> Yes, for an object that still has to be blended with a background image.
> 
> But since a text console has a solid background, you can calculate the
> resulting RGB values directly:
> 
>     [rgb]_res = [rgb] * a + [rgb]_bg * (1-a)
> 
> This is indeed equivalent with alpha blending a pixel with transparency a to a
> solid background pixel.

Ok, i see that, but what about hardware supported anti-aliasing/alpha
blending. will providing the value to the chip and let it do stuff not be
faster (especially as some more advanced chip don't know about 24bpp, treating
it as 32bpp and ignore the 8bit of the alpha channel ?

Friendly,

Sven Luther

Re: [Linux-fbdev-devel] Alpha blending

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

On Tue, 3 Apr 2001, Sven LUTHER wrote:
> On Tue, Apr 03, 2001 at 10:05:01AM +0200, Geert Uytterhoeven wrote:
> > On Tue, 3 Apr 2001, Sven LUTHER wrote:
> > > What about anti-aliasing ?
> > 
> > Anti-aliasing has nothing to do with transparency on non-transparent text
> > consoles.
> 
> Err, it was my understanding that you use the alpha channel to do
> anti-aliasing, even if in the end you don't support transparency, but then i
> may be wrong, (mmm, maybe i am).

Yes, for an object that still has to be blended with a background image.

But since a text console has a solid background, you can calculate the
resulting RGB values directly:

    [rgb]_res = [rgb] * a + [rgb]_bg * (1-a)

This is indeed equivalent with alpha blending a pixel with transparency a to a
solid background pixel.

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-devel] Alpha blending

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

On Tue, Apr 03, 2001 at 10:05:01AM +0200, Geert Uytterhoeven wrote:
> On Tue, 3 Apr 2001, Sven LUTHER wrote:
> > 
> > What about anti-aliasing ?
> 
> Anti-aliasing has nothing to do with transparency on non-transparent text
> consoles.

Err, it was my understanding that you use the alpha channel to do
anti-aliasing, even if in the end you don't support transparency, but then i
may be wrong, (mmm, maybe i am).

> > > > Wouldn't we want an Alpha/Transp value to be passed to the three
> > > > accelerated functions?
> > > 
> > > No, we don't want transparant text consoles :-)
> > 
> > Why not, it could be fun, with a big pengouin display behind ?
> > 
> > Alternatively, we could have a framework for userland set themable display
> > engines, or something such.
> > 
> > (not really serious here, so don't take it so)
> 
> Sure! And use the YUV-layer on ATI RAGE 3D for a transparent image of `big
> brother^H^H^H^H^H^H^Hpenguin Linus' watching you work from the right top corner
> of the screen :-)

Yes, something such, ...

maybe even a live webcame feed of linus or something such ?

:)))

Friendly,

Sven Luther

Re: [Linux-fbdev-devel] Alpha blending

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

On Tue, 3 Apr 2001, Sven LUTHER wrote:
> On Tue, Apr 03, 2001 at 08:17:41AM +0200, Geert Uytterhoeven wrote:
> > On Mon, 2 Apr 2001, Scott A McConnell wrote:
> > > I assume the Transp is for Alpha blending.
> > > It appears that the  API can support Alpha blending at the pixel level.
> > > 
> > > What about support at the rectangular level?
> > > 
> > > Not that they are an authority.... ;-)
> > > 
> > > http://www.pcwebopedia.com/TERM/a/alpha_channel.html
> > > 
> > > "Typically, you wouldn't define the alpha channel on a pixel-by-pixel
> > > basis, but rather per object. Different parts of the object would have
> > > different levels of transparency depending on how much you wanted the
> > > background to show through. This allows you to
> > > create rectangular objects that appear as if they are irregular in shape
> > > -- you define the rectangular edges as transparent so that the
> > > background shows through. This is especially important for animation,
> > > where the background changes from one frame to the next. "
> > 
> > That's something different. `transp' in fbdev is about transparency of the
> > screen (for a video underlay or so), not about transparency of objects to be
> > blended together on the screen.
> 
> What about anti-aliasing ?

Anti-aliasing has nothing to do with transparency on non-transparent text
consoles.

> > > Wouldn't we want an Alpha/Transp value to be passed to the three
> > > accelerated functions?
> > 
> > No, we don't want transparant text consoles :-)
> 
> Why not, it could be fun, with a big pengouin display behind ?
> 
> Alternatively, we could have a framework for userland set themable display
> engines, or something such.
> 
> (not really serious here, so don't take it so)

Sure! And use the YUV-layer on ATI RAGE 3D for a transparent image of `big
brother^H^H^H^H^H^H^Hpenguin Linus' watching you work from the right top corner
of the screen :-)

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