Vesa Jääskeläinen <[EMAIL PROTECTED]> writes: >> I would just used `int' and `unsigned int'. It's just important that >> you don't explicitly use a specific amount of bits and leave that to >> the compiler. > > Ok. Can I assume that unsigned int always has at least 32 bits? Or do I > need to specify some types needing 32 bits using grub_uint32_t ? I will > use grub_uint32_t and friends in VBE structures, but in video subsystem > it is irrelevant.
It's 32 bits on a 32 bits architecture and 64 bits on a 64 bits architecture. Using 32 bits on some 64 bits architecture might be suboptimal and I think it is harder to read. But it is ok to assume you have at least 32 bits, but it can be more on some archs. >>>> Is it possible to pass parameters like depth to grub_video_setup? >>> Depth?... Are you thinking 3D-displays here :) ? Or are you building up >>> some kind of Z-buffering? >> >> Depth means the amount colors. For example you can have a 16 bits >> depth, which means 65536 colors per pixel. > > Okey, bits per pixel then, or color depth :)... Currently it is auto > detecting best possible bits per pixel mode. We could allow mode_type > parameter to assist on selection of the best matching mode. And if there > is no exact match, one bit in mode_type could tell what to do in that > situation. Should best matching mode be selected, or only exact matches > allowed. If there is no valid mode in display driver it will fall back > to next listed driver and try to initialize mode with same parameters. Ok, nice. > I thinked that selecting the bpp is not important and I optimized it out > :), but if this is wanted feature I think guiding is better option. > There are many different RGB modes and I think that it would be most > reasonable to ask generally a RGB mode and then select best one. It's relevant when someone made a 16bpp background image. I am quite sure he doesn't want to use 8 bpp. :-) >>>> How would scrolling work if a background picture was used? >>> I was planning that terminal would implement background picture >>> handling. And if there is a background picture that would scroll when >>> the screen is about to scroll. That area must be redrawn. Fanciest >>> option here would be that there would be graphical layers, but that is >>> more a "window manager issue" than a video driver issue. >> >> If you use double buffering, you can use a few buffers: >> >> 1) the background >> 2) the text and whatever the console needs for output >> 3) some buffer to which #1 is copied and #2 is copied (using 0 as >> transparancy or so) >> 4) The visible buffer >> >> In that case you draw to buffer 2, prepare buffer 3. When you want to >> show buffer 3 you switch it with buffer 4. >> >> What do you think of that? > > That's not exactly double buffering :). It's more like a layering > combined with double buffering. That is right. > But your idea of layers with data can be used and is most likely good > approach. But should this be implemented in video driver or elsewhere. I > have tried to make video drivers simple to implement. Rest of the > graphics system would then implement fancier functions. I also think video drivers should be easy to implement. So this stuff has to be done by the framebuffer I think. Or someplace else. > In here I would see this as a job of "window manager". In grub's case > this is more like a responsibility of the terminal :). Yeah, window manager support is something we should focus at, at first. ;-) > There are two approaches that I see here: > > 1) Terminal's responsibility > > Rendering sequence would be: > > - Zero out back buffer (optional) > - Terminal would draw background bitmap > - Terminal could use multiple additional bitmaps layers and upper layers > could include transparency information > - Terminal must use font manager in order to draw text, unless glyph > drawing is implemented elsewhere. > - Swap front/back buffers > > Now good thing here is that video driver is not bloated. Bad thing here > is that handling of those bitmaps would most likely need same > functionality as is provided in non-bitmap video driver. I am not sure if I understand you. Can you give two practical examples of where it is better and where it is worse? > 2) Partially video drivers responsibility > > Add support for rendering targets. Caller could create virtual screens > that can be used to render with normal drawing functions. This would > shift some of the jobs to video subsystem. > > Rendering sequence could be something like: > > - Zero out back buffer (optional) > - Render background from render target 0 (or from bitmap) > - Render additional layers from other render targets (or from bitmaps) > - Render text layer using font manager or another render target > - Swap front/back buffers You want this so hardware layering features can be used? Did you look at some systems like XFree already? > In order to use render targets, they must be created and they should be > based on the actual screen properties. Eg. Same color order and so on. > Resolution of the render targets could be different. This is to fasten > blitting process. There is also possibility to "lock" render target in > order to do pixel buffer modifications. What does locking mean in this context? > Con's of the render targets is that eats quite lot of more memory than > then first idea. But with them we can get prettier output more easily. Isn't the output just the same? > This render target could be a viable solution, even though it shifts > some more work to video subsystem. It's not too hard to implement render > target support. So if this is a route we take it's Ok for me. I am not yet sure if I understand it completely, I should re-read it when I am not that tired. ;) > But now comes the important question :)... How advanced we want this > video subsystem to be in GRUB ? As I see it we need some killer feature to compete with GRUB Legacy. Some neat graphics support can be that killer feature. Especially if it is cross-platform. Something we should keep in mind is that if we want something new, we could always extend the interfaces. So no need for interfaces to support 3D cards yet. ;-) -- Marco _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel