To Andre: patches 1 to 5 are in.
To All: I'm not sure how to handle patch 6, since I don't use
CORE_TI_CMEM. Is the system that Andre suggests generic enough to be
included in mainline, on top of the (small) patch content?
Greets
Niels
Andre DRASZIK wrote:
Hi,
I am sending some more patches:
1) LUT8 fix -> lut8 palette entries (which are in RGB) were
erroneously converted from YUV to RGB in the software renderer.
2) dfbscreen test app enhancement
3) dfblayer test app enhancement - allows to set layer's screen
location & size
4) add DSPF_VYU and DSPF_AVYU to dfbinspector test app
5) add DSOC_656 to DFBScreenOutputConnectors (DirectFB already has 656
as signal type)
6) since the non public CORE_TI_CMEM type exists - can we have a
CORE_STMFBDEV system, too. I will send the system's implementation to
the list (for inclusion) if considered useful (I doubt it is, given
that it targets our driver, which is free though...), but in any case
having the system identifier reserved would be useful :-)
Basically, I found it dissatisfying that the devmem system requires
users to specify physical addresses as directfb options for graphics
memory and mmio... but I still wanted its flexibility.
It's in essence an fbdev system without any screen and layers.
Cheers,
Andre'
------------------------------------------------------------------------
_______________________________________________
directfb-dev mailing list
directfb-dev@directfb.org
http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
--
.------------------------------------------.
| DirectFB - Hardware accelerated graphics |
| http://www.directfb.org/ |
"------------------------------------------"
_______________________________________________
directfb-dev mailing list
directfb-dev@directfb.org
http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
