Date: Fri, 22 Feb 2008 21:39:56 +0100 (CET) From: Oliver Fromme <olli@lurza.secnetix.de> To: freebsd-hackers@FreeBSD.ORG Subject: Re: /boot/loader graphics support & extensibility Message-ID: <200802222039.m1MKduRf027996@lurza.secnetix.de> In-Reply-To: <754FD289-9E26-4368-9AB4-64F3ECB6CDFC@mac.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Marcel Moolenaar wrote: > [Oliver explains bitblit, then Marcel explains bitblt.] OK, so we mean the same thing, bascially. > The higher lever TTY code simply calls bitblt with a > bit mask of the glyph to be printed and doesn't need to > know about the details of the display. As such, simple > console output works at any resolution and with any > color depth. > > At the same time the VGA driver is abstracted from any > high-level details, like fonts or character sets. This > means that it's easy to write an accelerated driver for > some graphics hardware. You simply implement mode > setting and bitblt and you're good to go. Yes, that'll work well for putting characters on the screen. But I don't think it is suitable for generic graphics operations, even (and especially) for drawing single pixels. > > For example, lets say there's a function to draw a > > rectangle (in fact there _is_ such a function in my code). > > The Forth code to draw a rectangle covering the whole > > screen at 640x480 would look like this: > > > > 480 640 0 0 vrect > > > > The FICL word pops the parameters from the Forth stack > > and calls a function gfx_rect(). This will go through > > an abstraction switch so it calls an appropriate function > > depending on the bitmap format of the current mode, > > i.e. there will be gfx_planar4_rect(), gfx_linear8_rect() > > and gfx_true24_rect(). Each of these functions implements > > the graphics operation in the most efficient way for the > > particular bitmap format. > > > > How would the above work with a bitblit function, exactly? > > You bitblt the 4 edges. I didn't say it was the most > performance optimal thing to do. I only said that it > can be abstracted that way. I'm sorry, I should have been clearer, that gfx_rect() function draws a filled rectangle. I don't think it makes sense to have a function for non-filled rectangles, because -- as you say -- that can easily and efficiently done by drawing 4 lines (I implemented efficient functions for vertical and horizontal lines, and a function for generic lines). Efficient line functions are important if someone wants to implement a simple windowing system in Forth (no, I'm not going to do this, but if someone else wants to, I won't hold him off). > Yes. My vtc(4) driver, which puts graphics support in the > kernel, is having the same problems with bitmaps. I have > a nice logo (the 4.4 daemon: see > http://www.mckusick.com/beastie/shirts/source.html), but > I only have it for the standard VGA 4-bit color mode. I need > a separate one for 16-bit and/or 256-bit colors... For the loader, I plan to support bitmaps in an upwards- compatible way. E.g. you should be able to use a 4bit PCX file in 8bit and 24bit modes (but not the other way round). > I think that sounds good. I do have another datapoint. > I leave it up to you whether that's something that needs > to be considered or not: > > EFI supports multiple consoles. In other words, the > EFI console can be both the display and the serial > line at the same time. Clearly, graphics mode is > something that you generally cannot duplicate over > the serial line. However, modulo the logo and > background, if the graphics console is like a text > console or serial console, then you can still have > them both. The serial console simply doesn't get > copied the logo and background, but since everything > else is text anyway, this should not be a problem. > > My ia64 machines use serial consoles, because > syscons hasn't been ported (and I'm not planning to > yet). However, it would be great if we could get the > EFI loader working in graphics mode already and > it would be especially great if that doesn't break the > dual console setting in EFI. > > The question before us is: worth a try or not worth > it... Sounds like a good plan, but I won't be able to help, because I know nothing about EFI, and I don't have any EFI machines. However, I will keep those EFI features in mind that you explained, and I will try make it possible that such support can easily be added at a later time. > > Well, personally I would also like to be able to use the > > capabilities of my hardware. My main "workstation" at home > > is a notebook. When using the default VGA resolution of > > 640x480, the hardware scales it up to the TFT resolution, > > and it doesn't do a particularly good job at it ... It's > > butt ugly and distorted. As a user, I would certainly > > welcome an option (in loader.conf or whatever) that enables > > me to select a better resolution. > > > > Is that like a toddler going nuts over candy? > > Yes and no. I can image that the user wants control over > the desktop. Power to the people. But here we're talking > about the boot process. For Joe User nothing more than > a waiting period. What does it matter, really, that a nice > logo is a bit distorted? Would it be nicer if we could avoid > the scaling? Yes, definitely. But it's not the first priority. I agree, it's definitely not first priority. I want to get the basic functionality done which will work with standard VGA and nothing else. There will be no VESA support at the beginning, or anything else. It's on my to-do list, but with lower priority. But I need to keep all those future enhancements in mind, even if they're not first priority, or otherwise it might become more difficult later on to add those features. I also want to avoid breaking the syntax of FICL words once they're established. That's why I have to think about all that now. > The graphics world is one with many pitfalls, obstacles > and controversies. I think it's best to get something basic > off the ground first. I agree. Absolutely. > I think performance is not a concern. > Once you have the basic functionality, you'll also have a > wishlist of things you want to do better; performance one > of them in all likelyhood. Performance isn't my highest priority, but not the lowest either. I try to do things in a way so that they're not horribly inefficient. At the very least I try to do it in a way so that they can be made more efficient easily. > I think we're finally moving into the 20th century :-) Even the 21st, I hope. :-) Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd Passwords are like underwear. You don't share them, you don't hang them on your monitor or under your keyboard, you don't email them, or put them on a web site, and you must change them very often.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200802222039.m1MKduRf027996>