Geert wrote:

Indeed. BTW, no comments on my proposal to add fb_fix_screeninfo.capabilities?

referring to his earlier post where he suggested:

What we really want to know here is whether redrawing is faster than
copying, i.e. whether reading from the frame buffer is fast or slow,
and whether fb_copyarea and fb_imageblit are fast or slow.

Right now we have in fb_fix_screeninfo:
 - [xy]panstep, for hardware panning
 - ywrapstep, for hardware ywrap

We can add a capability field with some flags that indicates that
- fb_copyarea is accelerated or not
- fb_imageblit is accelerated or not
- fb_write is much faster than fb_read
(I don't think it matters much to announce an accelerated fb_fillrect, 
although we may want to do that for consistency)

I chose the above so we have reasonable defaults if the capability field 
is 0.

All other logic can be derived by fbcon from these capabilities, right?

I like the approach.  It sounds like this is the sensible replacement for
the vague semantics we have now in var.accel_flags / FB_ACCELF_TEXT. 

I'm currently running through the radeon code trying to figure who all 
twiddles var before it gets set to registers and how to rework fbcon to be
sensible...

-dte

---
getting bounce messages from me? let me know and you'll go on my whitelist


-------------------------------------------------------
This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
For a limited time only, get FREE Ground shipping on all orders of $35
or more. Hurry up and shop folks, this offer expires April 30th!
http://www.thinkgeek.com/freeshipping/?cpg=12297