Hi, > What are the required semantics for update/switch/refresh? > These don't seem to be documented. Can we validly make > those be asychronous, or does the midlayer require that > the operation has completed and been reflected onscreen > before the update/switch/refresh callback returns ?
refresh ------- refresh() is called at regular intervals, for guest display refresh. By default it is called every 30 ms (GUI_REFRESH_INTERVAL_DEFAULT), UIs can ask for a different interval using update_displaychangelistener() though. Typically the refresh() callback will first call graphic_hw_update(vd->dcl.con), which in turn calls into the display device emulation for display update checks. vga emulation will check dirty tracking here to figure whenever the guest has updated the display. Next is actually updating the UI (but see below). switch ------ Notifies the UI that the DisplaySurface has changed. Will happen when the guest switches the video mode. Can also happen on pageflips. Can happen during the graphic_hw_update() call, but can also happen independant from that. Qemu will free the old DisplaySurface after the switch callback returns, so you must make sure you don't keep a reference. These days the DisplaySurface is just a thin wrapper around a pixman image though, and pixman images are reference counted. So if you want handle display updates outside the iothread the best way to do that is to grab the pixman image (DisplaySurface->image), get a reference to make sure it is not released under your feet (pixman_image_ref()) and run with that in your UI thread. update ------ Notifies the UI that the guest has updated a specific display rectangle and the UI should redraw it. Can happen during the graphic_hw_update() call, but can also happen independant from that. You can do the UI update right here, or you can just record the rectangles, then do a batched update in the refresh() callback. Or you can pass on the rectangle to your UI thread for processing. HTH, Gerd