Re: [Xen-devel][RFC] Dynamic modes support for PV xenfb (included)

[Pat Campbell <plc@xxxxxxxxxx>]

Markus Armbruster wrote:
> The current PVFB code shares the framebuffer as follows.  The
> framebuffer is described by a two level directory.  The first level is
> the page directory pd[] in the shared page.  pd[] contains the mfns of
> the second level directory pages.  Those form an array containing the
> mfns of the framebuffer.
>
> Your patch replaces both levels of the page directory by grants, but
> not the framebuffer itself.  What exactly does that buy us?
>   
Patch does not replace the pd array.  That is still being used to
maintain backwards compatibility.  The required framebuffer memory is
allocated in xenfb_probe() and is never reallocated or changed.  Only
the mapping to the framebuffer is changed.

Maybe some pseudo code this will make it clearer.

Frontend (FE)
   Determine framebuffer size
   Allocate framebuffer 
   Fill in array of mfns
   Set shared page info to default mem length, width and height
   Fill in grant refs using array of mfns
   Back end Connected?
        Send map extended event (uses grant ref)
   Map extended done event?
        Free grant refs

Backend  (BE)
   Calculate number of mfns based on mem length from shared  page
   Map in and point at framebuffer
   Map extended event?
         Map in using grant ref
         Change framebuffer pointer to the new location
                (still the same FE memory but now we can reach father
into it) 
         Send Map extended done

At this point the Backend is still treating the framebuffer as
800x600x32 but does has access to the extended framebuffer memory but
does not use it.  When a resize event occurs the screen geometry changes
but not the framebuffers mappings.

So to answer what it buys us.  It buys us access to a larger framebuffer
for higher resolutions support.
 

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel