Re: [RFC] PVFB: Add refresh period to XenStore parameters?

[Markus Armbruster <armbru@redhat.com>]

Samuel Thibault <samuel.thibault@eu.citrix.com> writes:

> Hello,
>
> Sometimes the backend of PVFB knows that it doesn't need permanent
> refresh, when the window is minimized for instance (no refresh at all),
> or the administration tools know that the window is thumnailed, and so a
> slow refresh rate is fine.  Also, some users may want to tune the
> refresh rate according to the smoothness they would like, balanced with
> the CPU time that requires.

Can you quantify the CPU time savings?  Are you sure they're worth the
extra complexity?

Are you sure the ability to control the rate is required?  Why isn't
it sufficient to be able to switch updates off?

> I've played with that idea a bit and it seems to work fine, saving
> computations and communications.  I'm now wondering about the interface:
> it looks to me like it could be as simple as a "refresh-period" node in
> the backend part of XenStore: the front-end would watch it, and update
> the timing of its internal refresh loop, xenfb_fps in the case of Linux'
> xenfb for instance.  A period of 0 would mean that no refresh is needed
> (e.g. minimized window)
>
> Samuel

Another option is to send a suitable message through the ring.  That's
how the dynamic mode patch (not yet merged) communicates resolution
change, albeit in the other direction.

The pvops PVFB uses fb_defio.  I think we can change the refresh
period there by changing xenfb_defio.delay, but that doesn't exactly
look like something the API wants us to do.