Re: Resource management.

["Antonino A. Daplas" <adaplas@hotpop.com>]

On Tuesday 22 February 2005 07:25, James Simmons wrote:
> > On Tuesday 22 February 2005 03:11, James Simmons wrote:
> > > Hi!
> > >
> > >    This is my first run at the resource management code. Comments are
> > > welcomed :-)
> >
> > Hi James,
> >
> > Where is this going to?  What I see are performance penalties.  For each
> > putcs and cursor, it has to call fb_find_resource() which walks the
> > linked list looking for a resource using strncmp().
> >
> > What's the goal here?
>
> 	So we don't end up with a struct fb_info constantly growing with struct
> fb_pixmaps. At present we have pixmap and sprite in struct fb_info. In the
> future we will have more. I need to create a pixmap for the framebuffer
> itself. This way we can have hooks for inbuf and outbuf to deal with
> issues of devices that have hardware restriction when writing to the
> framebuffer. The classic example is the Epson135X chipsets. You can only
> write/read 16 bits at a time with the framebuffer. Also in the future I
> plan to add DMA support. One approach to this is pci_pools. This would
> require multiple fb_pixmaps. One for each area for DMA you request. Of
> course we could have a static array of struct fb_pixmaps but there is no
> guarantee that the orders will be the same for each driver.
>
> Do you see any other solution to this then?

The structure fb_pixmap was designed originally as a kind of scratchpad, ie,
this is where each character map is consolidated into a single image before
writing to the framebuffer.  Of course, this structure is not restricted to
that role only, but it can be used in different ways, as long as its
function as a scratchpad is kept in mind.  The only thing we need to know is
where this scratchpad is located, is it in system RAM or some kind of IO
memory, and we already have support for that. In short, it was never meant
as an accessor to different areas of the graphics aperture. which is the
reason I'm not too keen on info->sprite.

In the example you cited, the epson problem can be easily solved by
creating an epson-specific fb_read/write.

However, if you are trying to add features to fbdev, like video overlay,
textures and the like, then that is a different problem altogether and
requires a new interface/architecture. Extending the function of structure
fb_pixmap will just complicate things even more by blurring its role as
a simple scratchpad area.

Tony




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click