Yuri Benditovich authored 5 years ago and Uri Lublin committed 5 years ago

Signed-off-by: Yuri Benditovich <yuri.benditovich@daynix.com>

Modes are returned in a buffer from qemu with IDs in increasing but not
necessarily consecutive order. (Some modes may be omitted if they don't fit
into the framebuffer.) Two custom modes are appended to the local buffer to
support arbitrary resolutions. The first custom id must be set to +1 of the
last id in the mode buffer, not to the last index +1 of the buffer.

E.G. these are the last entries in the mode buffer returned from QEMU:
	Index      Mode id (unfortunately named ModeIndex in the struct)
	...
	124         128
	125         130
	126         132
	127         134 (last mode returned from QEMU)

Custom Modes:
	128         135 (Not 128!)
	129         136

If the first custom mode id is set to 128 (the number of modes returned
from QEMU), it will duplicate the id for the mode at index 124. That could
cause the FindMode function which searches the mode list by mode id
to return the wrong mode information.

The custom mode id's are now set to be greater than the last mode id
returned from QEMU.

The last argument in the FillVidModeInfo is replaced with the actual mode
id rather than the index.  This does nothing more than replace the mode id
with itself.

This addresses: https://bugzilla.redhat.com/show_bug.cgi?id=1202424

---
Updated the comments
---

A change to spice-procotol adds spice/macros.h to the qxl build.  This
causes a few macros to be redefined, resulting in warnings that break the
build.

Explicitly including the spice/macros.h file in place of the
redundant macros fixes the warnings.

Sandy Stutsman authored 9 years ago and Christophe Fergeau committed 9 years ago

Provides correct monitor locations when specified via the guest
"Screen Resolution" applet.

Addresses:https://bugzilla.redhat.com/show_bug.cgi?id=1202419

This reverts commit 49feefa9.
The patch causes the display to get stuck. Till we understand exactly
why, I'm reverting it.

QXL_IO_UPDATE_IRQ causes the device to check int_mask and int_pending
and issue an interrupt if that is required. Since we just zeroed
int_mask, no interrupt will ever be issued. Since we issue another
QXL_IO_UPDATE_IRQ in the interrupt routine DPC right after resetting
int_mask any pending interrupt will be raised then.

RHBZ: 856246

Alternative is to leak, and this happens regularely. Perhaps we should
be keeping track and destroying these surfaces later (in case no reset
happens in the middle, which destroys all off screen surfaces anyway).

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.

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

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
fc314927 to combine the iUniq of the surace and the
color_trans.

Signed-off-by: Alon Levy <alevy@redhat.com>

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.

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.

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 253b7817 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

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.