Stefan Lucke wrote:
> On Dienstag 16 Mai 2006 14:20, you wrote:
>
>>Stefan Lucke wrote:
>>
>>>On 2004-04-07 & 29 patches from Vadim Catana added pixel based alpha blending
>>>of the videoLayer with primaryLayer for radeon driver.
>>>This feature seems to be absend now.
>>>
>>>>From video viewing, it had (should have) the same effect as using
>>>SetLevel(-1) of the unichrome driver. I'd like to have this back :-).
>>>But my which is, that both drivers should work in the same manner
>>>(from programmers view).
>>>
>>
>>The new driver doesn't include that option because I think that the
>>ALPHA_MODE_PER_PIXEL mode of the overlay is related to alpha test rather
>>than alpha blend (i.e. it makes the overlay visible if the underlaying
>>pixel has an alpha channel greater/equal to the selected value, at least
>>this is how it works on the R300).
>
>
> Did you test with DLOP_ALPHACHANNEL and DLOP_DST_COLORKEY at the
> same time ? I think both are mutually exclusive.
>
> However it worked for me and the one who originally supplied the patch
> for radeon (Vadim Catana I guess). I made a small patch that brings this
> functionality back. My graphic card is a radeon 9200 with 256MB ram.
>
> (*) DirectFB/Graphics: ATI Radeon 9200 (5961) 1.0 (Claudio Ciccani)
>
> "dmesg|grep -i rade" shows the following:
> [ 44.961401] radeonfb: Found Intel x86 BIOS ROM Image
> [ 44.961406] radeonfb: Retreived PLL infos from BIOS
> [ 44.961410] radeonfb: Reference=27.00 MHz (RefDiv=12) Memory=250.00 Mhz,
> System=200.00 MHz
> [ 44.961413] radeonfb: PLL min 20000 max 40000
> [ 46.207637] radeonfb: Monitor 1 type CRT found
> [ 46.207642] radeonfb: EDID probed
> [ 46.207644] radeonfb: Monitor 2 type no found
> [ 46.208204] radeonfb (0000:01:00.0): ATI Radeon Ya
> [ 62.725347] [drm] Initialized radeon 1.19.0 20050911 on minor 0:
>
> "lspci -v -s 01:00.0" reports:
> 01:00.0 VGA compatible controller: ATI Technologies Inc RV280 [Radeon 9200]
> (rev 01) (prog-if 00 [VGA])
> Subsystem: Connect Components Ltd Unknown device 2801
> Flags: bus master, 66MHz, medium devsel, latency 32, IRQ 19
> Memory at d0000000 (32-bit, prefetchable) [size=256M]
> I/O ports at c000 [size=256]
> Memory at e9000000 (32-bit, non-prefetchable) [size=64K]
> [virtual] Expansion ROM at e8000000 [disabled] [size=128K]
> Capabilities: [58] AGP version 2.0
> Capabilities: [50] Power Management version 2
>
>
>>Hower DLOP_ALPHACHANNEL should not change the layer level, according to me.
>
>
> I would not say that specifying DLOP_ALPHACHANNEL should change the level.
>
> With DirectFB the same functionality for two different cards has to be done
> in two different ways. That's what I don't like. I'm comparing now
> VIA-unichrome
> and ATI-radeon. I can show something on the video layer and an OSD. The OSD
> seems to be on top of the videolayer. OSD is drawn on graphic layer and holds
> the alpha values for full alpha blending. The argumentation for unichrome was:
> to get this mode you have to videolayer->Setlevel(-1) [below graphic layer]
> and
> enable DLOP_ALPHACHANNEL on graphic layer ;-) .
>
>
That's the right way to do that since, after enabling DISP_ALPHA_MODE_PER_PIXEL,
the overlay becomes the underlay and the underlay becomes the OSD.
Another way could be adding a new layer ("Radeon OSD" or "Radeon Subpicture")
that wraps the primary layer, but I will follow the unichrome approach for now.
--
Regards,
Claudio Ciccani
[EMAIL PROTECTED]
http://directfb.org
http://sf.net/projects/php-directfb
_______________________________________________
directfb-dev mailing list
[email protected]
http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
