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

[Markus Armbruster <armbru@redhat.com>]

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

> Samuel Thibault, le Thu 01 May 2008 18:55:36 +0100, a écrit :
>> Getting back to that old issue.
>> 
>> Samuel Thibault, le Tue 04 Mar 2008 16:12:20 +0000, a écrit :
>> > > * If the frontend can track changes efficiently, it sends update
>> > >   messages to the backend, which can use them to only redisplay
>> > >   changed areas.
>> > 
>> > Well, that was actually my next target :)
>> > (but for that we badly need the resize/redepth support).
>> > 
>> > However, that doesn't solve something that still bugs me, which is
>> > that the VGA emulation layer wakes up every 30ms to just notice that
>> > the width/height/depth registers didn't change etc. even if the actual
>> > window is not shown.
>> 
>> What could be done is to make the backend set request-update to 0 when
>> the window is minimized, which makes the frontend understand that there
>> is temporarily no need to send updates any more, and set it back to 1
>> when the window is restored.  Would that be OK?
>
> Here is how it would be implemented:
>
>
> ioemu: transmit idleness information to avoid useless polls
>
> Signed-off-by: Samuel Thibault <samuel.thibault@eu.citrix.com>

Any particular reason for going through xenstore instead of the event
rings?

If I read your patch correctly, xenfb_read_frontend_fb_config() sets
request-update in xenstore depending on xenfb->ds->idle, during
startup.  The only place that changes it is xenfb_update(), which is
#ifdef CONFIG_STUBDOM.

What if ds->idle is true when xenfb_read_frontend_fb_config() runs
during startup of the ordinary (!CONFIG_STUBDOM) backend?  Can this
happen?  If not, why?

Other than that, the change seems to affect only Mini-OS and
CONFIG_STUBDOM, which are both outside the area of my expertise (and
frankly, interest).