Samuel Thibault <samuel.thibault@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx>
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).
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home