| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
We haven't done this for most any change. Perhaps we should do this? No
idea what the x.y.z.w convention is, so I made the most minor change
right now. But the date is the important bit.
(cherry picked from commit ab746740d03eb3c2494f7a70971861b933688718)
|
|
Change the registry checking logic we already have, instead of enabling
surfaces by default we now disable surfaces by default. They can be
enabled without driver change by creating a registry key name
"SurfacesEnabled" of type DWORD with any value under the adapter key.
To find the adapter key, one way is looking for the key under which
there is a value of name "QxlDeviceID" after a successfull startup of
the qxl driver.
RHBZ: 985408
(cherry picked from commit 154c477005c8f5001262123ddc043adba1b4bf0e)
|
|
rhbz#968050
In contrast to Microsoft Msdn documentation, the iUniq of a SURFOBJ doesn't
always change when the surface changes. However, it seems that the
iUniq of the associated color_trans (XLATEOBJ) changes, while its
flXlate=XO_TRIVIAL. Since we tried to retrieve the alpha bitmap key
only by the surface iUniq, we fetched the wrong bitmap, and it looked
like parts of the screen haven't been rendered.
The patch modifies QXLGetAlphaBitmap so that it will use GetCacheImage
instead of duplicating its code. GetCacheImage was already fixed in
fc314927bc48835e to combine the iUniq of the surace and the
color_trans.
(cherry picked from commit 170af9c620d40e607b02f9722bc90260c15ed914)
|
|
Signed-off-by: Alon Levy <alevy@redhat.com>
(cherry picked from commit 85de1534831a63ebcb682a10d4cd509467f4e5d0)
|
|
DebugPrintV first locks print_sem, and then locks io_sem.
async_io, locks io_sem.
In ordr to avoid a deadlock, DebugPrintV MUSTN'T be called when
io_sem is locked.
I also moved the locking of io_sem, so that reading pdev->use_async
will also be protected (async_io can modify use_async to 0 upon a
timeout).
Also notice, that locking io_sem during DebugPrintV limits our ability
to use the log_port for debugging concurrency problems related to ios.
(cherry picked from commit ae74511ef2269491347f0b2f78f94dcabed268b9)
|
|
rhbz#966835
We do not support copying such bitmaps. But instead of failing
operations that involve such bitmaps we either BSODed (in checked
builds), or proceeded with the bitmap copying (in free builds) - this lead to an infinite
loop allocating QXLDataChunks without any data, just header.
(cherry picked from commit 0a2458574d3c22314ff58758ad98c820374de370)
|
|
This is a pixman requirement. If it isn't enforced spice crashes, qemu
with it. That should be fixed, but there is no simple way to allow for
non word aligned strides, and the only down side is that for 16 bit
modes we will require even widths. And we already have the same
implementation detail in the X driver, only there it is a multiple of 8,
not 4.
The SurfaceCreate command's stride is computed in one place:
miniport:FillVidModeInfo sets ScreenStride as word aligned
display:pdev->stride is set from ScreenStride
A third change at GetSurfaceMemory fixes the stride used for GDI
allocated surface, but since surface 0 has a fixed larger then required
area this isn't required for the bug fix, just for consistency.
|
|
Change IOCTL_QXL_SET_CUSTOM_DISPLAY to use 5/6/5 (via SetCustomDisplay).
The replaced 5/6/5 is not supported by us. Specifically we fail
display/rop.c:TestSrcBits and thus fail _BitBlt. I'm not sure how
exactly this causes the BSOD for 863410, but it does in fact do that,
and applying this fix, by not failing _BitBlt also fixes 863410.
RHBZ: 863410
|
|
Presence of the key disables off screen surfaces creation; The callback
is still registered, but it always fails.
Registry key is checked on device initialization only, not during
runtime, so you must reset the vm to see any affects.
|
|
The patch 253b781773190afef313390542f2d68995e302d7 implementing custom
display resolution is accessing unowned memory regions.
Interestingly, the driver worked fine on Windows XP but BSOD on Win7.
|
|
Updated:
- removed ununsed yoffset
- removed VIDEO_MODE_NO_OFF_SCREEN usage
- commented why 2 modes are needed
|
|
|
|
happen out of WHQL
|
|
|
|
|
|
This patch handles the surprise removal whql test. The surprise
removal test sends a surprise removal IRP via a filter driver to
qxl.sys. The handling of that IRP is actually done in videoprt.sys,
and there is no API to get notified. The side effect of the handler
in videoprt.sys is disabling our interrupt handler. This patch takes
care of continuing to work after our interrupt is disabled. This is
in effect the opposite of what the MSDN states that a device should do
after a surprise removal, since the MSDN requires every IO to fail after
the surprise removal IRP has been successfully handled. On the other
hand, this workaround is sufficient to pass the test.
The workaround is to turn the EngWaitForSingleEvent on the io_cmd_event
event into a timed wait.
If it fails, we revert to synchronouse IO, which doesn't require that
event at all.
|
|
|
|
|
|
|
|
|
|
1) send create surface commands for all the surfaces that have not been
moved to vram
2) fix the parameters sent to SendSurfaceCreateCommand
3) send create primary surface IO
|
|
due to the previous patch ("support clearing the pci-bar when the pdev is disabled for revision<3 as well"),
surfaces_info and other resources like caches, are no longer shared between pdevs. Moreover,
it is an error to use globals, since different display driver sessions have different memory space.
In addition I removed all the semaphores that are not related to the pci ram. These semaphores
were protecting the surfaces_info array and the caches, however these sturctures belong only to one pdev,
and according to http://msdn.microsoft.com/en-us/library/ff568281%28v=vs.85%29.aspx, can be accessed
only from a single thread.
For the rest of the semaphores, I returned them to the same state that was in revision 1 => they
are part of the PDev. However, this should be fixed:
1) In order to protect the device log buffer,
the print_sem must be shared by different pdevs and
different display sessions. Alternatively, we can use IOCTL for logging.
2) malloc_sem: not sure what it protects. Maybe globals in mspace?
since only the enabled pdev is allocating memory, I don't
think it is required (unless it is possible to have
AssertMode(x, enable) before AssertMode(y, disable).
3) cmd_sem, cursor_sem: again, since only the enabled pdev touches the cmd rings
I don't think it is required.
4) io_sem - same as print sem. Note that we should prevent starvation between
print_sem and io_sem in DebugPrintV.
|
|
revision<3 as well, RHBZ #731644
see also commit "display/driver: reimplement DrvAssertMode for Suspend+Hibernate (S3+S4) support".
In revision < 3, objects (surfaces and other devram objects) stayed alive in the pci ram
after DrvAssertMode(Disable) was called. Then, when another display driver session started (upon switch user),
the driver had newly initiated mspace, but an old release ring (with objects from the older session's mspace).
This state led to a crash.
|
|
When several sessions of the display driver are alive,
DrvDisableDriver can be called for the older session while the newer session has already started.
It happens when you switch users on a dual monitor XP guest. Reseting the devices in DrvDisableDriver
while they are used by another session leads to a BSOD.
|
|
Drv<Enable/Disbale>Surface calls IOCTL_VIDEO_MAP/UNMAP_VIDEO_MEMORY respectively.
These calls make the miniport map/unmap the vram to/from system space.
The BSOD occurred since with qxl revision 2, the driver assumes that
as long as it is loaded the vram stays (and all the other mem slots) valid
and in the same place. However, the miniport's call to VideoPortMapMemory
(in IOCTL_VIDEO_MAP_VIDEO_MEMORY) is not guaranteed to map the vram to the same
virtual address. As a result, when the driver accessed to an mspace instance
that was initialized with a no longer valid virtual address, we got BSOD.
Since we don't change the size of the vram, I see no point in mapping and
unmapping it more then once.
For qxl revision 3 this problem is not relevant since between DrvAssertMode(disable)
to DrvAssertMode(enable) we clear the pci ram and initialize all
the data structure that are related to it (mspace, caches, etc.)
I didn't remove the calls to IOCTL_VIDEO_MAP/UNMAP_VIDEO_MEMORY
since I think they would be useful for supporting dynamically changing the
size of the memslots according to the current resolution. Which I think is the
real purpose of IOCTL_VIDEO_MAP/UNMAP_VIDEO_MEMORY. Today, the size
of the frame buffer (surface0) is static -> the maximal resolution we support.
|
|
RHBZ: 727886
The io port range test was too large, requiring support for the
new io ports introduced in revision 3. The purpose was just the opposite,
to only require the revision 2 range, and use the revision 3 range only
if the device claims revision 3.
Fix by checking that either
rev == 2 && io range contains 2
rev > 2 && io range contains 3
|
|
This was (kind-of) cherry-picked from qspice (rhev-2.2) commit
commit 1d467e6be87eedb3b0ad2723468fb5555192b9a2, that fixes
rhbz #581514
|
|
|
|
our old code did a very minimal flow good for resolution change:
DrvAssertMode False (disable)
destroy primary surface
delete vram memslot
DrvAssertMode True (enable)
create primary surface (destroyed on disable)
create vram memslot
Aside: Importantly the flow for resolution change involves two pdevs, so actually the
enable call is not called, only:
DrvAssertMode(PDEV#1, FALSE)
DrvEnableSurface(PDEV#2)
EnableSurface creates a primary surface, so the call to AssertMode must destroy it.
This fails on suspend for many reasons, one of them being that we don't disable
operations to any driver managed off screen surfaces, and the other is that
after the qxl reset done via acpi S3 request by windows, we don't reinitialize
the primary memslot (this is fixed by a previous commit).
The correct (per example drivers from WinDDK, and per msdn) thing to do in
DrvAssertMode is to not do any further interaction with the device. The
simplest way to achieve that is to fail any operation. The GDI is designed such
that it can work completely without any driver, so for any operation there is a
fallback in case the driver returns a failure error code. A simplification is
to use EngModifySurface to move a surface to GDI control and so not to get any
further callback on it (except for the deletion callback when it is deleted).
This is also done in the 3dlabs example driver.
There is zero synchronization between the miniport, which knows about the power
state, and the displayport, which knows about the pci device structure, command
rings, resources.
As a result the easiest and also consistent with the above requirements
implementation for suspend to ram and to disk is to reset any server side state
during DrvAssertMode(FALSE), copying all volatile (surface contents only atm)
memory to guest ram (from there windows will copy it to disk for us if we are
hibernating).
So the new flow for DriveAssertMode is then:
AssertModeDisable:
1. set pdev->enable to False (all further operations will be punted)
2. tell server to prepare for sleep, via new QXL_IO_UPDATE_MEM(QXL_UPDATE_MEM_RENDER_ALL):
server updates all surfaces
server destroys all surfaces. Since we never sent it a destroy command
this doesn't trigger any guest side surface destruction, only a release of
the creation command resources.
3. release anything in the release ring.
4. tell server to write it's current releasable items list (qxl->last_release)
to the release_ring (we just made sure the release_ring is empty, and since we
are not sending anything new to the worker and we already had it render
anything outstanding it will not fill it) release the last resources (at this
point there is nothing allocated on devram and vram - we verify that in debug
mode with DUMP_MSPACE_VRAM and DUMP_MSPACE_DEVRAM).
5. Destroy primary surface
6. Delete vram memslot
AssertModeEnable:
1. Create primary surface
2. create vram memslot
3. copy surfaces from ram to vram, sending create commands which cause both
create and surface image commands to be sent to the client.
In suspend there is a single PDEV involved which does exactly those two calls,
disable before sleep and enable after.
For resolution change this work is excessive but correct. Since
miniport:SetPowerState is called after DrvAssertMode during suspend (actually
there is no defined order in the documentation), there is no way to distinguish
between the two anyway.
From: Alon Levy <alevy@redhat.com>
From: Yonit Halperin <yhalperi@redhat.com>
|
|
GDI will continue using any callback we registered even after a
DrvAssertMode(FALSE). We are expected to move any surface we own to GDI handled
and ignore any new requests to create a surface. This is called punting and we
use PDev->enabled to indicate if this is required.
A later patch will set PDev->enabled to FALSE on DrvAssertMode.
|
|
Adds fields to SurfaceInfo to cache data previously only available
via SurfaceArea::draw_area.
Adds two functions to save and restore surfaces from ram:
MoveAllSurfacesToVideoRam
allocates and copies surfaces from vram to ram, and calls EngModifySurface
with an empty hook list to make those surfaces completely managed by gdi and not
us.
MoveAllSurfacesToRam
recreates surfaces on vram and calls EngModifySurface with QXL_SURFACE_HOOKS, and
finally sends a QXL_SURFACE_CMD_CREATE with the valid data flag to make the server
send a surface image message after the surface create message.
Cc: Yonit Halperin <yhalperi@redhat.com>
|
|
alloc/free code paths
This adds a third surface allocation type, allocation from guest memory using
the windows ddk allocator.
Not all code paths are used later - the creation is not done since
copy-surfaces-to-ram allocates memory itself, and at the end we never allocate
any surfaces when the device is disabled, we just punt the allocation to the
gdi, but the code is still left in GetSurfaceMemory.
Cc: Yonit Halperin <yhalperi@redhat.com>
|
|
Cc: Yonit Halperin <yhalperi@redhat.com>
|
|
Cc: Yonit Halperin <yhalperi@redhat.com>
|
|
Cc: Yonit Halperin <yhalperi@redhat.com>
|
|
|
|
Cc: Yonit Halperin <yhalperi@redhat.com>
|
|
Refactors InitResources code called upon DrvEnableSurface so it can later be called
from AssertModeEnable. Introduces three helpers:
EmptyReleaseRing - no vmexit, goes over release ring and empties it all (as opposed to
OOM behavior that empties 50 resources).
InitDeviceMemoryResources - resets anything on the device memory (devram and vram pci bars).
ReleaseCacheDeviceMemoryResources - helper for clearing the cache (which points to devram
QXLImage's)
Cc: Yonit Halperin <yhalperi@redhat.com>
|
|
even if it is not found in the cache (which is an error)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
in DrvAssertModeDisable later)
Cc: Yonit Halperin <yhalperi@redhat.com>
|
|
changes the passed user pointer to mspace from NULL to a proper pdev, so
it will be able to print using QXL_IO_LOG.
|
|
Disabled if no DBG, and uses loglevel == 1
|
|
|
|
|
