summary refs log tree commit diff stats
path: root/hw/display/virtio-gpu-udmabuf.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
* virtio-gpu-udmabuf: correct naming of QemuDmaBuf size propertiesDongwon Kim2023-07-171-6/+6
| | | | | | | | | | | | | | | Replace 'width' and 'height' in QemuDmaBuf with 'backing_widht' and 'backing_height' as these commonly indicate the size of the whole surface (e.g. guest's Xorg extended display). Then use 'width' and 'height' for sub region in there (e.g. guest's scanouts). Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Marc-André Lureau <marcandre.lureau@redhat.com> Cc: Vivek Kasireddy <vivek.kasireddy@intel.com> Signed-off-by: Dongwon Kim <dongwon.kim@intel.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-ID: <20230713040444.32267-1-dongwon.kim@intel.com>
* virtio-gpu-udmabuf: create udmabuf for blob even when iov_cnt == 1Dongwon Kim2023-06-271-1/+2
| | | | | | | | | | | | | | | There were often cases where a scanout blob sometimes has just 1 entry that is linked to many pages in it. So just checking whether iov_cnt is 1 is not enough for screening small, non-scanout blobs. Therefore adding iov_len check as well to make sure it creates an udmabuf only for a scanout blob, which is at least bigger than one page size. Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Marc-André Lureau <marcandre.lureau@redhat.com> Cc: Vivek Kasireddy <vivek.kasireddy@intel.com> Signed-off-by: Dongwon Kim <dongwon.kim@intel.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-ID: <20230621222704.29932-1-dongwon.kim@intel.com>
* Do not include "qemu/error-report.h" in headers that do not need itThomas Huth2023-02-141-0/+1
| | | | | | | | | | Include it in the .c files instead that use the error reporting functions. Message-Id: <20230210111931.1115489-1-thuth@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Thomas Huth <thuth@redhat.com>
* Don't include headers already included by qemu/osdep.hMarkus Armbruster2023-02-081-1/+0
| | | | | | | | | This commit was created with scripts/clean-includes. Signed-off-by: Markus Armbruster <armbru@redhat.com> Acked-by: Christian Schoenebeck <qemu_oss@crudebyte.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-Id: <20230202133830.2152150-19-armbru@redhat.com>
* Remove qemu-common.h include from most unitsMarc-André Lureau2022-04-061-1/+0
| | | | | | Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20220323155743.1585078-33-marcandre.lureau@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* virtio-gpu: splitting one extended mode guest fb into n-scanoutsDongwon Kim2021-11-051-8/+14
| | | | | | | | | | | | | | | | | | | | | | | When guest is running Linux/X11 with extended multiple displays mode enabled, the guest shares one scanout resource each time containing whole surface rather than sharing individual display output separately. This extended frame is properly splited and rendered on the corresponding scanout surfaces but not in case of blob-resource (zero copy). This code change lets the qemu split this one large surface data into multiple in case of blob-resource as well so that each sub frame then can be blitted properly to each scanout. v2: resizing qemu console in virtio_gpu_update_dmabuf to scanout's width and height v3: updating stub function of virtio_gpu_update_dmabuf to match the type Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Vivek Kasireddy <vivek.kasireddy@intel.com> Signed-off-by: Dongwon Kim <dongwon.kim@intel.com> Message-Id: <20211104065153.28897-5-dongwon.kim@intel.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* ui/gtk: skip any extra draw of same guest scanout blob resDongwon Kim2021-11-021-1/+1
| | | | | | | | | | | | | | | | | Any extra draw call for the same blob resource representing guest scanout before the previous drawing is not finished can break synchronous draw sequence. To prevent this, drawing is now done only once for each draw submission (when draw_submitted == true). v2: - removed mutex - updated commit msg Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Vivek Kasireddy <vivek.kasireddy@intel.com> Signed-off-by: Dongwon Kim <dongwon.kim@intel.com> Message-Id: <20210924225105.24930-1-dongwon.kim@intel.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* ui: Create sync objects and fences only for blobsVivek Kasireddy2021-09-151-0/+1
| | | | | | | | | | | | Create sync objects and fences only for dmabufs that are blobs. Once a fence is created (after glFlush) and is signalled, graphic_hw_gl_flushed() will be called and virtio-gpu cmd processing will be resumed. Cc: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com> Message-Id: <20210914211837.3229977-4-vivek.kasireddy@intel.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* virtio-gpu: Add helpers to create and destroy dmabuf objectsVivek Kasireddy2021-05-271-0/+65
| | | | | | | | | | These helpers can be useful for creating dmabuf objects from blobs and submitting them to the UI. Cc: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com> Message-Id: <20210526231429.1045476-12-vivek.kasireddy@intel.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* virtio-gpu: Add udmabuf helpersVivek Kasireddy2021-05-271-0/+158
Add helper functions to create a dmabuf for a resource and mmap it. Also, introduce the fields blob and blob_size so that these helpers can start to use them but the full picture will emerge only after adding create_blob API in patch 8 of this series. To be able to create a dmabuf using the udmabuf driver, Qemu needs to be lauched with the memfd memory backend like this: qemu-system-x86_64 -m 8192m -object memory-backend-memfd,id=mem1,size=8192M -machine memory-backend=mem1 Based-on-patch-by: Gerd Hoffmann <kraxel@redhat.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com> Message-Id: <20210526231429.1045476-4-vivek.kasireddy@intel.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>