strcasestr() returns NULL if specified substring is not found, which
should be handled when parsing the command line options.
Tracked-On: #8439
Signed-off-by: Jiaqing Zhao <jiaqing.zhao@linux.intel.com>
Reviewed-by: Jian Jun Chen <jian.jun.chen@intel.com>
This patch fix several issues that NULL pointers possibly be
dereferenced in display module.
Tracked-On: #8439
Signed-off-by: Yonghua Huang <yonghua.huang@intel.com>
Signed-off-by: Jiaqing Zhao <jiaqing.zhao@linux.intel.com>
Reviewed-by: Jian Jun Chen <jian.jun.chen@intel.com>
When no geometry parameter is passed for virtio-gpu, it should not be started.
Tracked-On: #7988
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Reviewed-by: Sun Peng <peng.p.sun@linux.intel.com>
Reviewed-by: Wang Yu <yu1.wang@intel.com>
When multi-display window is initialied/configured, it should report the correct number
to virtio-gpu devides so that it can notify that the Guest_VM can use multi-display.
Otherwise the Guest VM still gets only one display.
Tracked-On: #7988
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Reviewed-by: Sun Peng <peng.p.sun@linux.intel.com>
Reviewed-by: Wang Yu <yu1.wang@intel.com>
When virtio-gpu is used for guest_vm, ACRN uses the libSDL API to render the framebuffer
submitted from guest virtio-gpu device. The libSDL will cache some op/states related with
3D internally and skip some 3D API. This works well for one display. When multi displays
are enabled, ACRN will create one SDL_Renderer/SDL_window for each display_window.
As the libSDL caches some states, it can't select the correct 3D shader and show
the garbage when switching among multi SDL_Renderer.
This is one limitation in libSDL.
So one small texture(32x32) is created and rendered so that each time it can reconfigure
the internal state for target texture. This is used to workaround the display issue.
Tracked-On: #7988
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Reviewed-by: Sun Peng <peng.p.sun@linux.intel.com>
Reviewed-by: Wang Yu <yu1.wang@intel.com>
Allow one VM have more than 1 virtual display for output. Till now, the
max virtual display number is 2. So guest VM can use dual display for
mirror and extend desktop mode. To specify multi-vdisplay, need use
acrn-dm parameters like this:
For fullscreen mode:
virtio-gpu,geometry=fullscreen:monitor_id1,geometry=fullscreen:monitor_id2
For window mode:
virtio-gpu,geometry=<width>x<height>+<x_off>+<y_off>,geometry=<width>x<height>+<x_off>+<y_off>
v1->v2: add pscreen_id outputs for easier debugging.
Tracked-On: #7988
Signed-off-by: Sun Peng <peng.p.sun@linux.intel.com>
Reviewed-by: Zhao Yakui <yakui.zhao@intel.com>
Add new concept "vscreen" to abstract all specs about screen in a
display server. This can provide convenience to add more screens
for one VM.
v1->v2: remove vscr NULL checks.
v2->v3: restore vscreen geometry calibaration to previous version.
wrap geometry calibaration and create window/render to
functions.
Tracked-On: #7988
Signed-off-by: Sun Peng <peng.p.sun@linux.intel.com>
Reviewed-by: Zhao Yakui <yakui.zhao@intel.com>
vdisplay use physical monitor id(pscreen index) to locate the monitor.
The max index value always is the physical monitor number - 1. For
example, there are 4 physical monitors connected. The monitor id should
be 0, 1, 2 and 3. We need check monitor id that user inputs and make
sure it is in a correct range.
Tracked-On: #7988
Signed-off-by: Sun Peng <peng.p.sun@linux.intel.com>
Reviewed-by: Zhao Yakui <yakui.zhao@intel.com>
To support full screen mode on one of multi-local-mornitor which
connected to service vm by monitor ID that customer specify. The
monitor ID is specified in acrn-dm's parameter like this:
virtio-gpu,geometry=fullscreen:monitor_id
For window mode, the vdisplay window always be shown on monitor 0,
because the customer can drag the window to anyone monitor. Besides, the
customer can set the monitor by x_off and y_off parameter like this:
virtio-gpu,geometry=<width>x<height>+<x_off>+<y_off>
v1->v2: Add note about zoom to pscreen width & height in fullscreen.
v2->v3: vdpy.width/height for window, used in host, vdpy.guest_width/
guest_height for guest framebuffer, used in guest.
Tracked-On: #7988
Signed-off-by: Sun Peng <peng.p.sun@linux.intel.com>
Reviewed-by: Zhao Yakui <yakui.zhao@intel.com>
Sometimes the virtio_gpu in guest_vm doesn't pass the zero coord_x/y for the
displayed framebuffer. In such case the offset should be calibrated for pixman_image/dmabuf
so that it can display the image from the correct image.
Tracked-On: #7988
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Reviewed-by: Peng Sun <peng.p.sun@linux.intel.com>
Vdisplay module will create the gui_window (vScreen) based on the virtio-gpu
parameter. When virtio-gpu device tries to establish the connection with
vdisplay module, it will return the supported number of vScreen.
Then the virtio-gpu device can initialize the correct info for the guest_vm.
BTW: The number is fixed to 1.
Tracked-On: #7988
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Reviewed-by: Peng Sun <peng.p.sun@linux.intel.com>
Currenly it can support only one display_win. When virtio-gpu wants to display
the framebuffer from Guest_vm, it will render it into the default win. In order
to support multi-window, the scanout_id is added for display API.
After display API is refined, the vdisplay and virtio-gpu can support the multi-win
independently.
BTW: Now the scanout_id is not implemented in vdisplay module and the virtio-gpu always
passes the zero. It will be implemeneted in the later patches.
Tracked-On: #7988
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Reviewed-by: Peng Sun <peng.p.sun@linux.intel.com>
Virtual display is component which based on native window system.
This feature depended phisical monitor connected and graphic driver in
SOS running correctly. If these dependencies fail, it is a fatal error
for virtual display. We have to terminate the device model to let user
fix runtime environment issue for graphics.
Tracked-On: #7672
Signed-off-by: Sun Peng <peng.p.sun@linux.intel.com>
1280x720 resolution will crash IDD of windows guest. To simplise, just
remove this mode.
Tracked-On: #7507
Signed-off-by: Sun Peng <peng.p.sun@linux.intel.com>
Acked-by: Wang, Yu1 <yu1.wang@intel.com>
All the modes that vdisplay supported should be reported to driver,
then driver should select the modes which report to OS.
Tracked-On: #7507
Signed-off-by: Sun Peng <peng.p.sun@linux.intel.com>
Acked-by: Wang, Yu1 <yu1.wang@intel.com>
EDID uses the bytes of 38-53 to support up to 8 standard modes. And it is
based on the mechanism: Byte 0 defines the xres / 8 - 31 and byte 1 defines
the aspect_ratio/refresh_rate.
But now it uses the incorrect logic in course of adding standard mode, which
causes that no standard mode is added in EDID block.
Fix it and add another two standard modes so that the guest_vm can parse
more modes from EDID.
Tracked-On: #7376
Acked-by: Wang Yu <yu1.wang@intel.com>
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
The EDID uses the bytes of 54-125 to define the four detailed_timing_blocks.
But the static offset is used to update the DTB. This will cause that
the incorrect offset is used for DTB if the edid_generate is called several
times.
Tracked-On: #7376
Acked-by: Wang Yu <yu1.wang@intel.com>
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Now some fileds are not initialized, which causes that ACRN-DM doesn't
handle the request of VIRTIO_GPU_CMD_GET_DISPLAY_INFO and
VIRTIO_GPU_CMD_GET_EDID.
Tracked-On: #7376
Acked-by: Wang Yu <yu1.wang@intel.com>
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Otherwise it will use the "acrn_dm" as the thread_name, which is not
convenient to check the cpu_usage of rendering_thread.
Tracked-On: #7337
Acked-by: Wang Yu <yu1.wang@intel.com>
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
When virtio-gpu tries to submit the framebuffer based on
VIRTIO_GPU_CMD_2D, one pixman_image will be created. When the
sdl rendering_thread is terminated, the pixman_image will be
released. But its pointer is set to NULL. In the next reboot,
its access in vdpy_surface_set is incorrect.
Tracked-On: #7337
Acked-by: Wang Yu <yu1.wang@intel.com>
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Now all the 3D ops are handled in one dedicated thread. As 3D ops are
not safe in multi-thread env, some checks are added so that it can indicate
that it is not in the expected code path.
Tracked-On: #7296
Acked-by: Wang Yu1 <yu1.wang@intel.com>
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Now the Opengl rendering is used implicitly in SDL backend. But sometimes
it needs to create the texture explicitly based on DMABuf so that it can
render the framebuffer submitted from virtio-gpu.
Tracked-On: #7210
Acked-by: Wang Yu <yu1.wang@intel.com>
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Hardware cursor emulation of virtio-gpu video adapter. Guest vm can
show its own cursor in virtual display, not share the cursor with
service vm. It also accelerated by SDL(OpenGL ES 2.0 backend) API
with hardware acceleration based on the GPU hardware own by service
vm.
Tracked-On: #7210
Signed-off-by: Sun, Peng <peng.p.sun@linux.intel.com>
Reviewed-by: Zhao, yakui <yakui.zhao@intel.com>
Acked-by: Wang, Yu1 <yu1.wang@intel.com>
Extended display identification data(EDID) is a data to store
display timings which are supported by ACRN virtual monitor.
Virtio-gpu FE driver will request it to config crtc for display
resolutions.
Tracked-On: #7210
Signed-off-by: Sun, Peng <peng.p.sun@linux.intel.com>
Reviewed-by: Zhao, yakui <yakui.zhao@intel.com>
Acked-by: Wang, Yu1 <yu1.wang@intel.com>
ACRN virtual monitor shown as a GUI system window of service vm.
It can display graphic outputs of guest vm which is stored in
service vm's buffers by virtio-gpu. Display operation is accelerated
by Intel GPU PF(SRIOV) device with SDL(OpenGL ES 2.0 backend) API.
This provides one generic display solution. When the virtio-gpu is
added, it will firstly try to setup the connection to graphics system
and then display the framebuffer from the guest vm in the created
window region.
Tracked-On: #7210
Signed-off-by: Sun, Peng <peng.p.sun@linux.intel.com>
Reviewed-by: Zhao, yakui <yakui.zhao@intel.com>
Acked-by: Wang, Yu1 <yu1.wang@intel.com>
