Created attachment 75247 [details] Test executable and source On Windows XP querying Direct3D8 for the supported modes yields a number of modes using the X1R5G5B5 pixel format instead of the normal R5G6B5 one when using the QXL driver. This causes Wine's conformance tests to fail on that platform. For instance: Vendor 6966, Device 256, SubSys 285219572, Revision 3 Driver = qxldd.dll Description = Red Hat QXL GPU Got 226 modes Mode 0: 640 x 480 @ 100Hz format *** X1R5G5B5 *** (unexpected) Mode 1: 640 x 480 @ 100Hz format X8R8G8B8 ... Using the same QXL graphics card and driver on Windows 7 shows the expected alternating R5G6B5 and X8R8G8B8 modes: Vendor 6966, Device 256, SubSys 285219572, Revision 3 Driver = qxldd.dll Description = Red Hat QXL GPU Got 58 modes Mode 0: 640 x 480 @ 100Hz format R5G6B5 Mode 1: 640 x 480 @ 100Hz format X8R8G8B8 ... Still using the QXL graphics card but with Microsoft's Standard VGA driver in Windows XP also shows the expected R5G6B5 and X8R8G8B8 modes: Vendor 0, Device 0, SubSys 0, Revision 0 Driver = vga.dll Description = Got 28 modes Mode 0: 640 x 480 @ 1Hz format R5G6B5 ... Mode 5: 640 x 480 @ 1Hz format X8R8G8B8 ... Steps to reproduce: * Set up a Windows XP VM in QEmu/KVM and install the QXL driver. * Run the attached d3d8modes.exe tool. * The tool should not report unexpected modes. More configuration details: * 32-bit Windows XP SP2 straight from CD, no windows updates. * The driver was installed from spice-guest-tools-0.3.exe which seems to ship a QXL driver built from this commit: 5020ad9f4a54d632daca3ccbc5522e3d44909c33 http://spice-space.org/download.html * The VM is running in QEmu/KVM on a 64-bit Debian host. qemu 1.1.2+dfsg-5 qemu-keymaps 1.1.2+dfsg-5 qemu-kvm 1.1.2+dfsg-5 qemu-system 1.1.2+dfsg-5 qemu-user 1.1.2+dfsg-5 qemu-utils 1.1.2+dfsg-5
What is the actual problem with X1R5G5B5? Not saying this is not a bug, I just want to know what the implications of this are.
Created attachment 75248 [details] Direct3D8 test executable and source Fix attachment so it has the correct MIME type.
Created attachment 75260 [details] Direct3D9 test executable and source My (possibly flawed) understanding is that this is not a format that IDirect3D8::EnumAdapterModes() is supposed to claim is supported. I'm still checking on that though. Another point however comes from a similar Direct3D 9 test which is also failing: although IDirect3D9::EnumAdapterModes(X1R5G5B5) returns a bunch of results, IDirect3D9::CheckDeviceType() refuses that format. So there's an inconsistency here. This inconsistency is also present for X8R8G8B8 though. I have attached the corresponding Direct3D9 test. Here is what it returns: Vendor 6966, Device 256, SubSys 285219572, Revision 3 Driver = qxldd.dll Description = Red Hat QXL GPU R5G6B5: is not supported (D3DERR_INVALIDCALL) X1R5G5B5: is supported Mode 0: 640 x 480 @ 100Hz format X1R5G5B5 ... *** error: CheckDeviceType(hal, fullscreen) refused this format anyway (D3DERR_NOTAVAILABLE)! *** error: CheckDeviceType(hal, windowed) refused this format anyway (D3DERR_NOTAVAILABLE)! *** error: CheckDeviceType(sw, fullscreen) refused this format anyway (D3DERR_NOTAVAILABLE)! *** error: CheckDeviceType(sw, windowed) refused this format anyway (D3DERR_NOTAVAILABLE)! X8R8G8B8: is supported Mode 0: 640 x 480 @ 100Hz format X8R8G8B8 ... *** error: CheckDeviceType(hal, fullscreen) refused this format anyway (D3DERR_NOTAVAILABLE)! *** error: CheckDeviceType(hal, windowed) refused this format anyway (D3DERR_NOTAVAILABLE)! *** error: CheckDeviceType(sw, fullscreen) refused this format anyway (D3DERR_NOTAVAILABLE)! *** error: CheckDeviceType(sw, windowed) refused this format anyway (D3DERR_NOTAVAILABLE)!
(In reply to comment #1) > What is the actual problem with X1R5G5B5? Not saying this is not a bug, I > just want to know what the implications of this are. The Wine tests are probably just a bit too restrictive here, but on the other hand it's pretty uncommon for drivers to expose X1R5G5B5 instead of R5G6B5. If there's no particular reason to prefer one over the other, you may want to consider exposing the more common R5G6B5 format instead.
Not sure if we should support windows xp at this point: http://windows.microsoft.com/en-us/windows/end-support-help
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.