|
From: James S. <jsi...@tr...> - 2001-11-27 19:18:38
|
> >Set the fb_fix fields for mmio and smem to zero. As for internally with > >the new api you don't need to use the screen_base field. > >Just ignore it. > > After further review (correct me If I am wrong James) it seems that > screen base (a kernel virtual address to the framebuffer) is needed > for the fb_read and fb_write functions. It was suggested that > there isn't a way around this. Well at present true. Actually I have been thinking about this problem. Plus someone talked about this a few days ago on the list. I personally have run inot the the problem of data write size restrictions. For me it was the Epson 1385 framebuffer. It only allows 16 bit accesses to the framebuffer. So if I do a raw cat I get strips down my screen. Lets not forget that use can't use memset on PPC on a framebuffer. So I agree we need to have fbdev functions for access to the framebuffer and they should be made avaliable to userland. The question is where to place these macros? So for fb_read and fb_write we need to copy the userland data into a temporary buffer and then use fb_memset to actually draw the image. > fb_put: Put data from somewhere into the framebuffer. This is called > imageblit in the new API. This should have a parameter to tell you > to use copy_from_user() or memcpy() Yeap. > fb_get: Get data from the framebuffer and put it in a provided pointer. > This should have a flag to tell you to use copy_to_user() or > memcpy() See what I said above. We should also consider the endian of the buffers to. > fb_set: Set a region of the frambuffer with the value provided. This > is called fillrect(?) in the new api. Yes. Remember tho it only does a rectangle of one color. We also nedd fb_write functions. > I have thought of a compromise that should be very easy for most > drivers to do, and will allow us to keep the driver private stuff > hidden. [snip]... Oh my. I really have to think about this. For now lets just cleanup what we have. |