On Tue, 5 Sep 2006 11:32:00 GMT "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> babbled:
> > Rene writes: > > > Hi, > > > > most framebuffer drivers (nvidia, radeon, ...) default to 8bps and > > all non-x86 machines such as PPC ones run this per default. However > > Evas (evas_fb_test) crashes on 8bps because no convert function is > > matched and crashes in > > > > evas_fb_outbuf_fb_get_height (buf=0x0) at evas_outbuf.c:365 > > > > because the buffer is nil - which is returned by: > > > > evas_fb_outbuf_fb_setup_fb(w, h, rot, OUTBUF_DEPTH_INHERIT, vt, > > dev, refresh); > > > > which in turn calls: > > > > evas_common_convert_func_get (dest=0x0, w=1024, h=768, depth=8, > > rmask=255, gmask=255, bmask=255, > > pal_mode=PAL_MODE_NONE, rotation=0) at evas_convert_main.c:15 > > > > Maybe someone with more evas internals in mind can help fixing > > this up properly? > > > > There's currently no convert-func in evas for converting > argb32 to an unpaletted 8-bit buffer, so it's returning a null > output buf.. The test shouldn't crash though, it should check if > an evas has been setup properly, etc. > > Code needs to be added to select the proper palette depending > on the rgb component sizes, and pass this to the convert_func_get. > Right now evas has some convert functions for depth 8, it just needs > to be told the 'palette mode' so it knows the size of the r,g,b > components of the destination (it should maybe use the fb bit-length > of each r,g,b component for this?).. But it isn't doing this, it's > just passing "pal_mode=PAL_MODE_NONE" no matter what the depth. yeah - i'm pretty lazy about the checks in the evas test setup - then again it is just quick test code - it's not meant to be a reliable product :) what we need is 1. palette allocation for the fb device to allocate a palette of some sort that the 8bit converter can understand 2. tell the converter that :) so yeah - you're right - it returns PAL_MODE_NONE :) i kind of took the position that - if you can only do 8bpp - you are going to be very limited. the output also will look pretty nasty and dithered. something like this: http://www.rasterman.com/files/e17-in-8bpp.png we handle paletted 8bpp in x because 1. we have no control over the screen depth of x, 2. often vnc will run in 8bpp to save bandwidth, 3. it's dead-easy to allocate colors :) for the fb - you have the control of defining the depth and i would suggest using 16bpp at least - probably 24/32 :) i make the assumption that if you are coding fb-based displays then you also are doing something very specific and low-levelish where you can define the depth the system runs at :) -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
