When the guest's framebuffer resource is larger than the scanout (GNOME on KMS), the flush copied the whole resource into the scanout-sized frame and the VMM panicked. The flush now reads only the scanout's area at the scanout's stride. A read error returns ERR_UNSPEC, after presenting the allocated frame so backends that allow one frame in flight don't lock up.
Tested with a unit test reading a 2x2 scanout out of a 4x2 resource.
The cherry-pick to stable-1.19.x needs small fixups (an import, and the test uses main's rutabaga API); an adapted commit is ready if wanted.
Open question: SET_SCANOUT's x/y offset is still ignored, as before. Should it be honored?
Activity
5
mtjhrc1mo agoI'll check this later I need more time to look into this - specifically about your x/y being ignored question.
willie14d agoIn case it helps with the x/y question: honoring it isn't just passing the scanout's x/y to transfer_read. With Rutabaga2D (rutabaga_gfx 0.1.85), transfer_2d applies x/y to the destination as well as the source, and transfer_read hard-codes dst_offset = 0, so the last rows don't fit the scanout-sized frame and the read fails with InvalidIovec. It would need a staging copy here or a rutabaga change. Happy to do that as a follow-up if you want it honored. (I haven't checked the virglrenderer path.)
slp11d ago@mtjhrc any additional feedback here?
@mtjhrc @dorindabassey PTAL