[<<] [<] Page 1 of 1 [>] [>>] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: MicroGDI direct framebuffer support
From: "Greg Haerr" ####@####.#### Date: 12 Oct 1999 02:22:15 -0000 Message-Id: <00a701bf1457$76e48020$14320cd0@censoft.com> Brad, At some time, _all_ bogl drivers need to be combined into one driver, that supports any bpp that the framebuffer asks for. For this reason, the framebuffer and mmap() stuff needs to be separated out into a single file, and then have separate files that deal _only_ with the specific pixel format, given an address. This isn't quite the way the bogl code is organized. When the framebuffer-specific stuff is removed, then the core drawing routines can be used by other routines to perform useful stuff, not related to framebuffer operations. A specific case in point is that I'm currently developing bitblt support. Offscreen drawing want's to be done in the exact device-dependent way that the screen drivers currently use, except that, rather than the "address" being the framebuffer start, it's an address returned by malloc(). Then the exact same low level routines are used to draw offscreen. Afterwards, when the user wants to see it, a single bitblt (fast memory copy) is used without conversion from malloc area to framebuffer or hw video address. Currently, we've got bogl/bogl-cfb8.c and bogl/vga16.c, which know too much. In addition, we need a 24 bit truecolor driver, as well as now the 2bpp driver for the Everex Freestyle. I suppose now's the time to get all this sorted out. Greg | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
[<<] [<] Page 1 of 1 [>] [>>] |