Re: clipping

On Sat, 2003-01-11 at 03:39, James Simmons wrote:

quoted

quoted

I thought about this. Originally I did have this function but removed it.
WHat do you think Geert?

Yes, that's OK.

But I was most concerned about fb_ops.fb_imageblit(), since clipping impacts
fb_image.data as well. IIRC, all (most?) current clipping implementations
modify fb_image.{dx,dy,width,height} only, without updating fb_image.data.

Good point. Of course we could ignore pieces of data in that image instead 
of altering the data. Altering the entire data would be expensive.

quoted

quoted

quoted

The other option (which I don't like) is just to check the passed
fb_var_screeninfo in the put_var ioctl against the current console
window size.  But this is not foolproof as we will not be sure of the
resulting window size _after_ the fb_set_var() call.

Yuck!!! The other way is better.

Well, in between the calls to fb_ops.fb_check_var() and fb_ops.set_par() you
can still perform that check. But it's indeed ugly.

Altering to the framebuffer via /dev/fb that would effect the tty should 
not remain after the final close of /dev/fb. Instead the console should 
reset to its previous state before we first opened /dev/fb.

Right :-) I believe this is nearer the correct solution.  Clipping is
typically used to maximize graphics/video bandwidth, but fbcon is using
it to "cover up" possible bugs in the code.

If we can have a correctly working fbcon, without the clipping code, it
will be proof to its robustness.

So, basically, on the first open we save xres, yres, xres_virtual,
yres_virtual and bits_per_pixel, and restore them on the last close, is
this correct?  Any other parameters that will affect the actual and
virtual window size?

Tony





-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com