In Windows guest, if we trigger a bluescreen, Windows will reset GPU to VGA
mode, otherwise the bluescreen will not shown.
Signed-off-by: Qi Zhou <atmgnd@outlook.com>
It is valid if position of cursor is negative(not hotspot coordinates). for
example: precision section, resize, move, north east arrow...
Signed-off-by: Qi Zhou <atmgnd@outlook.com>
Acked-by: Frediano Ziglio <freddy77@gmail.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1791804
The remapping will work only when the driver controls
the placement of drawn pointer, i.e. when the input
device in VM is usb-mouse and the Spice Agent is not
active.
Signed-off-by: Yuri Benditovich <yuri.benditovich@daynix.com>
Acked-by: Marek Kedzierski <mkedzier@redhat.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1791804
Currently the screen can be shown as Landscape and
Portrait (90 deg. rotation). Allowing also Flipped
Portrait (270 deg. rotation) and Flipped Landscape
(180 deg).
Signed-off-by: Yuri Benditovich <yuri.benditovich@daynix.com>
Acked-by: Marek Kedzierski <mkedzier@redhat.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1758524
Examples are displays 320*200 and 800*480
Signed-off-by: Yuri Benditovich <yuri.benditovich@daynix.com>
Acked-by: Marek Kedzierski <mkedzier@redhat.com>
On return from S3 the driver may receive failure when
calls DxgkCbAcquirePostDisplayOwnership. In general the
driver is not expected to use this method when returns
from S3 but it is not simple to distinguish between S3
and S4 power transition (possible, due to hybrid sleep).
Current commit avoids returning error on power transition
and obtains best known default video mode info instead.
Signed-off-by: Yuri Benditovich <yuri.benditovich@daynix.com>
Acked-by: Marek Kedzierski <mkedzier@redhat.com>
Even if initial display resolution is not available at driver start, try
to find it in the registry. Then the driver can prevent black screen
on uninstall/disable also when it was installed on UEFI machine after
the production driver 0.18 which did not report valid video mode.
Signed-off-by: Yuri Benditovich <yuri.benditovich@daynix.com>
Acked-by: Marek Kedzierski <mkedzier@redhat.com>
Setting this flag on this command cause some performance issue.
When the server see this flag it updates the frame buffer and copy
part of it in a new allocated image. However for this command the
image is not used wasting only CPU and memory.
Also the frame buffer update causes the elimination optimisation
to be less effective causing more network usage.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Yuri Benditovich <yuri.benditovich@daynix.com>
Limited the installation of the driver to Windows 8 and up
in order to prevent false driver installation on unsupported OSes
which lead to BSODs.
Signed-off-by: Basil Salman <basil@daynix.com>
Signed-off-by: Sameeh Jubran <sameeh@daynix.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Add ability to produce ETW (Event Tracing for Windows) to release
version of the driver to be able to record binary traces in case
of problem in customer environment for further analysis.
Logging of debug build is not changed.
Signed-off-by: Yuri Benditovich <yuri.benditovich@daynix.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Fixed wrong formats of printouts producing errors with WPP.
All fixed format strings were wrong mainly due to incorrect
format for pointers.
Signed-off-by: Yuri Benditovich <yuri.benditovich@daynix.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
In case the device initializes 4 memory bars, the driver maps
physical memory of bar 4 and never unmaps it. Fixing it by
immediate unmap of unused memory bars.
Signed-off-by: Yuri Benditovich <yuri.benditovich@daynix.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1454866
Due to wrong addresses passed to class driver, it never does
unmapping of physical memory, causing a leak of virtual address range.
On x86 systems the device fails to start due to failure to
map physical memory range after 10-50 cycles of disable-enable.
Signed-off-by: Yuri Benditovich <yuri.benditovich@daynix.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Upon change of display mode the driver waits until all the
queued drawables pushed to the host or discarded. This eliminates
server warnings "rendering incorrect" in "get_drawable" when the
drawable command was created by guest driver just before change
of display mode and posted to the server during or after the change.
This patch and comments are heavily based on a patch sent by
Yuri Benditovich (with serialization code completely changed and
added generation to discard pending commands on old surface).
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Yuri Benditovich <yuri.benditovich@daynix.com>
As GetModeInfo is also inline there is no reason the derived class
could redefine the array anyway.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Yuri Benditovich <yuri.benditovich@daynix.com>
The check is done already by C++.
The assignment was removed as was just assigning a local variable.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Pavel Grunt <pgrunt@redhat.com>
If the memory was requested from VRAM area but finally allocated
from DEVRAM, set memory space variable for correct verification
of allocated pointer
Signed-off-by: Yuri Benditovich <yuri.benditovich@daynix.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Previous Windows drivers use mainly DEVRAM so in some environments
(like RHEV-M 4.0) VRAM is really limited.
This patch use DEVRAM as a fallback to avoid getting out of memory
conditions too earlier in such environments.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Yuri Benditovich <yuri.benditovich@daynix.com>
Don't use the old style _inline specifier.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Yuri Benditovich <yuri.benditovich@daynix.com>
This make easier to change allocation of memory using different
memory Bars.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Yuri Benditovich <yuri.benditovich@daynix.com>
As VA addresses are used as pointers there's no need to handle
them as 64-bit integer (which make the code more complicated)
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Yuri Benditovich <yuri.benditovich@daynix.com>
There were always 2 slots used so make no sense to allocate
always dynamically.
Also in this way m_MainMemSlot and m_SurfaceMemSlot become
constant making the code slightly smaller.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Yuri Benditovich <yuri.benditovich@daynix.com>
This make easier to change allocation of memory using different
memory Bars.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Yuri Benditovich <yuri.benditovich@daynix.com>
In case of VSync is active (for the driver this means it shall take
in account watchdog policy and ensure fast execution of PresentDisplayOnly
callback) allocate bitmaps for drawable objects using non-forced requests.
If immediate allocation is not possible, place entire bitmap into memory
chunk allocated from the OS.
If bitmap is allocated from device memory, but one of later
chunks can't be allocated, allocate this and further chunks from
OS memory. All these 'delayed' allocations placed into linked list
which root entry is part of QXLOutput structure.
>From separate thread, before sending drawable objects down, review
the list of delayed chunks and allocate device memory (forced) to
all of them.
The cost of solution is 2 pointers added to each drawable or cursor
object.
Cursor commands currently do not use them; in future we have an option
to offload also cursor commands.
Signed-off-by: Yuri Benditovich <yuri.benditovich@daynix.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Preparation for non-forced allocations.
Update bitmap creation procedure to allocate device memory forced
or non-forced.
In forced case it works as before.
In non-forced case, if allocation fails, the procedure allocates
memory from OS pool for entire bitmap and copies source data to it.
Later, before sending command, memory will be allocated from device
memory and copied from intermediate location to new one.
Signed-off-by: Yuri Benditovich <yuri.benditovich@daynix.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Move bitmap creation to dedicated procedure. Currently it
uses only forced allocations, as before. Later it will
be used from different flows, forced and non-forced.
Signed-off-by: Yuri Benditovich <yuri.benditovich@daynix.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Increased size of allocation to reduce number of allocation per
bitmap. Before change the procedure ignored 'alloc_size' parameter
and always allocated memory chunk according to 'size' parameter.
As a result, first chunk could be up to 64K and all following are
limited by line size. For example, for bitmap 1280x1024 there was
more than 1008 chunks allocated, for bitmap 128x1024 - 897 chunks.
We change the procedure to use chunk size up to 64K (similar to first
chunk). This reduces in described examples number of allocation from
1008 to 64 and from 897 to 8 respectively.
Signed-off-by: Yuri Benditovich <yuri.benditovich@daynix.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Preparation for offload of allocations from device's memory
to separate thread. Procedure PutBytesAlign is called to
allocate memory chunk from device memory and copy data to it.
With current commit the procedure (if called with non-NULL
linked list root entry parameter) can use non-forced allocation.
If such allocation fails, it allocates 'delayed' chunk from
OS memory and copies data to it. Later before sending drawable command
this chunk shall be processed, storage allocated from device memory
(forced) and data copied to it.
Signed-off-by: Yuri Benditovich <yuri.benditovich@daynix.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Preparation for further scenarios when memory allocation failure
can happen and we'll need to use fallback when possible.
Memory allocation can fail in following cases:
- when non-forced memory allocation used and the attempt to allocate
the memory must be as fast as possible, without waits
- when forced memory allocation used, but the driver already received
stop command and waits for thread termination. Note that in case
the VSync control is enabled stop command may happen even after the video
subsystem executes switch to VGA mode. In such case QEMU will not return
previously allocated objects (assuming the QXL driver already disabled
and ignoring callbacks from Spice server in VGA mode).
In case of forced memory allocation the allocation routine waits
unpredictable time until the request is satisfied. In current commit
we do not acquire m_MemLock mutex for all this time, but release it
when entering long wait to allow another caller to try allocating memory.
Signed-off-by: Yuri Benditovich <yuri.benditovich@daynix.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
