Hi, This is probably somewhat off topic but seeing as xfree86 is fairly unhelpful I would appreciate it if anyone can give me some pointers re porting XGGI to a YUV framebuffer. For porting XGGI/fb is it possible to do minimal support ie just one BPP driver? Also can you just hack a couple of low level pixel operations for quick results and then later add support for lines, boxes etc (like GGI)? Any online docs/howto's etc? Also would GGI direct buffer need changing, or does it merely pass low level fbdev heuristics to XGGI? Regards, David Craig -----Original Message----- From: Andreas Beck [mailto:[EMAIL PROTECTED]] Sent: Friday, 19 May 2000 8:02 To: [EMAIL PROTECTED] Subject: Re: GGI support for non standard FB devices > 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]> =
