[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [E-devel] Evas (evas_fb_test) crashing on 8bps framebuffers

On Tue, 5 Sep 2006 11:32:00 GMT "jose_ogp@juno.com" <jose_ogp@juno.com> 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:


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)    raster@rasterman.com
Tokyo, Japan (東京 日本)