Hi, >> Hmm, when the server is able to translate a8 ops into non-a8 ops using >> server-side rendering, then there is no need to notify the guest about >> the client capabilities. > > To be clear, this ability doesn't exist at the moment, and it would be a > significant chunk of work to add it. > >>> But it's much simpler to just say that the guest should stop referring >>> to a8 surfaces if the client can't handle them. >> >> Not sure about that, this move might just shift the complexity from >> spice-server to the guest qxl driver. > > The ability to handle this is already pretty much present in at least > the X driver (and I'm pretty sure the Windows driver has it as well) > because any time something can't be expressed in the SPICE protocol, it > has to fall back to software rendering. Ie., it has to read all the > involved surfaces back from video memory, do software rendering, then > upload the result as an image. > > Dealing with a disappearing ability to handle a8 surfaces would simply > be a matter of reading back the a8 surfaces to guest RAM and then not > attempt to acccelerate any operations involving them any more. > > It looks much more involved to do it in spice-server because it would > probably involve adding a new concept of "emulated surface" that needs > to be handled specially in a bunch of cases. Ok, so the tradeoff seems clear. I trust you on that one, you know the guest drivers alot better than I do. Lets go forward with the client capability notification for the guest, /me awaits a new revision of the patches. cheers, Gerd _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel