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

Re: [Linux-fbdev-devel] Alpha blending

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

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 ?

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

Friendly,

Sven Luther

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

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

On Mon, 2 Apr 2001, Alan Cox wrote:
> > Yes this is problem. See my response to Paul about this. The only reason
> > I'm using MMX for the vesa framebuffer because it has no acceleration. MMX
> > gives a big boost for genuine intel chips. Other types of MMX are fast but
> > they don't seemed to be optimized for memory transfers like MMX on intel
> > chips. I also have regular code that does all kinds of tricks to optimize
> 
> Then you are doing something badly wrong.
> 
> 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.

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

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

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.

> Wouldn't we want an Alpha/Transp value to be passed to the three
> accelerated functions?

No, we don't want transparant text consoles :-)

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

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

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

> > >If I use X on an accelerated, normal Matrox screen, my monitor complains
> > >on exit:
> > >
> > >fH 49.4 KHz, fV 39.8 Hz
> > >
> > >(and it doesn't sync at 40 Hz vertical refresh :-( ).
> > >
> > >This is _half_ of the normal 80 Hz. Using fbset -a "1600x1200-80"
> > >before X, of after X, doesn't do anything. Does anybody know what to
> > >hack out in X to get it to _not_ reset my G400 to some unusable
> > >state? 3.3.6 was didn't do this. I can use the framebuffer-screen
> > >just fine, but I miss the DGA extension.
> >
> >Try adding this to your XF86Config file:
> >
> >Section "Device"
> >...
> >Option UseFBDev
> >...
> >EndSection
> >
>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?

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: [linux-fbdev] aty fb

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

>I'm having some difficulties with the ATYFB driver. It breaks the TV
>tuner functionality of my All-In-Wonder PRO video card. The problem is
>that it uses all the available video RAM and doesn't leave ANY for the
>required video overlay. I was wondering if there was any way that I could
>force it to reserve a little memory.

Try using fbset to change the virtual y resolution (i.e fbset -vyres 640).
See the fbset man pages. By default fbdev drivers use all the video memory
they can to perform scrolling. You can change this behavior.

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:[linux-fbdev] 2.4.2: System clock slows down under load

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

>This is a message that i originally posted to the linux-kernel mailing
>list.I would be really glad if someone could give me a hint to run the VESA
>fbcon on 2.4.

linux/Documentation/fb/vesafb.txt

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

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

>Is it possible that "jump scroll" would provide more performance benefit
>than an accelerated driver anyway?

I wouldn't rule it out. If someone wants to wipe up some code I would have
no problem testing it to see if it is worth it.

>Seeing as you bring up this topic of writing a 9525 driver.  It seems to
>me rather wasteful that you (collectively linux framebuffer authors),
>XFree86 and Berlin are all writing drivers for the same, hugely diverse
>class of hardware, to support more or less the same ops on the hardware.
>
>Isn't possible to pool the development effort of video drivers?  Doesn't
>X require basically the same set of operations as the kernel?  I.e.,
>initialise the card and video mode (usually the very complex part); do
>some rendering ops (usually fairly simple).  Sure, X provides a few more
>kinds of rendering op, but that part of the code is usually much simpler
>and smaller than the initialisation code.

Well the goal of each is very much different. Fbcon was developed to deal
the fact that most modern video hardware doesn't support text but graphical
based modes instead. VGA text is slowly going away. Since are goal is to
emulate a text console we just have to provide basic support to provide
just this. We need to

1) Draw basic text -> Glyph operations.

2) scrolling -> hardware panning or a copy area operation.

3) scroll a region of the screen -> copy area operation.

4) Clear the display or region of display -> fillrect

5) Set color palette.

6) Manage a hardware cursor.

7) Manage the current resolution for VC switching or a mode change vi
   VT_RESIZE or TIOCSWINSZ.

So fbcon is out of necessite. Now X you mean XFree86 which is really a OS
in itself. Its goal to do everything itself so it can run everywhere
know to mankind. As for Berlin I don't know the code so I can't say.
As people are finding out XFree86 doing everything itself is having
issues. A good example is the classic problem of X dying and you have to
reboot the machine. Also when under heavy load and you exit X to the
console you don't get the text mode. Well right now its tough luck and
just reboot your machine. A M$ solution but people have been doing it
so long they don't mind it. I hope to fix those problems for 2.5.X.
As you can see I think the OS should handle the transfer from console mode
to text mode and vice versa. Now for programming the accel engine to do
graphics in userland. Well their is nothing wrong that each does their own
thing. What does matter is their is a GIU independent kernel manager of
the graphics engine state. DRI attempts to handle this.

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

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

> Yes this is problem. See my response to Paul about this. The only reason
> I'm using MMX for the vesa framebuffer because it has no acceleration. MMX
> gives a big boost for genuine intel chips. Other types of MMX are fast but
> they don't seemed to be optimized for memory transfers like MMX on intel
> chips. I also have regular code that does all kinds of tricks to optimize

Then you are doing something badly wrong.

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

Alan