On Mon, 28 Feb 2005 00:24:39 -0500, Daniel Phillips <[EMAIL PROTECTED]> wrote:
> I don't think any specifics have been discussed. > > It would be nice to not have to bother the memory controller about this, > it already has enough to worry about. So how about using block ram for > the cursor? RGB cursors should be supported, even if hardly anybody > uses them. The color doesn't have to be full 24 bit though. Alpha > blended cursors would be nice, but messy hardware-wise. One bit alpha > is probably the right choice. Limiting the cursor to 32x32 is probably > ok, since other hardware has similar limitations. A 32x32 cursor with > 6:6:5:1 rgba will fit in a single 1024x18 block ram. > > There could be a dedicated "load cursor" command with cursor data > inline, or a cursor could be loaded as a normal rgba texture and have > an "activate cursor" command, giving the texture address and dimensions > (always 32x32) which loads the cursor into block ram. > > X actually defines a cursor in terms of two bitmaps and doesn't know > anything about RGB cursors, as far as I can tell, but Windows does. I > didn't dig far enough to find out what limits X has for cursor size, if > any, or how the fallback from hardware cursor to software cursor works. > 32x32 is a typical limitation for display hardware. Anyway, the > required format conversion can be handled in the driver. X supports > specifying colors for cursor foreground and background. so this has to > be handled in some way, even though I've never seen any actually use > this feature. > > There is no point in supporting cursor control through the command > buffer, as far as I can see. Timothy has mentioned providing a command > to set/get any register through the command buffer, but what I'd rather > see is all functions divided up strictly into register-controlled vs > command-controlled. I doubt there is any overlap. Cursor position and > enable/disable is one of the few functions that needs dedicated > registers, because cursor positioning has to be immediate, not delayed > by the geometry backlog. > > Just a few notes, hopefully to start some discussion on cursor > specifics. Loading a cursor glyph is an infrequent and relatively quick thing to do. My plan is to have a simple PIO interface to load pixels into the cursor. It's out-of-band, because it has nothing to do with the rendering engine. I'm going to keep this simple. In fact, accessing the video controller is going to be exclusively PIO and very simple. _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
