> OK well I have started modifying GGI/fbdev to support my YUV framebuffer and
> its turning out to be fairly straight forward, However the sole purpose for
> porting GGI is to get XGGI running on our platform. If I understand you
> correctly then XGGI contains specific fb rendering code that does not just
> use the underlying GGI graphics lib functions???
Yes. This is due to the structure of the X-consortium server that was used
as a base. It will acquire a directbuffer and render to it.
> If this is the case then what is involved in doing mods to XGGI such that it
> would work on our YUV framebuffer???
IIRC there are subdirectories for each renderer. You'd have to copy one of
them, link it into the building process and modify it to understand the
framebuffer arch you have.
> I am keen to get something running quickly so if I started off by using a fb
> translation method what would be the best way of doing it? (ie: is fbdev
> the best target to use, what is the best way to trigger translation frames?)
As a "quick-hack", I'd say that writing something like a "dbemu" target
would be best. The idea would be to make a cross between the memory target
and one of the *emu targets.
This target would open a truecolor memory-buffer and intercept ggiFlush
on it. When ggiFlush gets called, it would scan the framebuffer for
changed lines and blit those out using the child target's native functions.
Another idea would be a shm-coupled system that works like the cube3d.
You write a small native LibGGI Program that reads from a shared-memory
located memory target and writes to your framebuffer and then you redirect
XGGI to the same shared memory area.
CU, ANdy
--
= Andreas Beck | Email : <[EMAIL PROTECTED]> =
