Why complain about X1R5G5B5?

[Francois Gouget]

If I run Wine's conformance tests in a QEmu VM using Spice's QXL driver 
I get the following errors:

d3d8:device
device.c:1004: Test failed: Unexpected display mode returned for mode 0: 0x18

d3d9:device
device.c:1366: Test failed: EnumAdapterModes(D3DFMT_X1R5G5B5) did not return D3DERR_INVALIDCALL (got 00000000)!

In essence our tests say that the driver must not support X1R5G5B5. Why?

Further notes:
 * If I then call Direct3D9::CheckDeviceType() for this format I get 
   NOTAVAILABLE which is inconsistent. But then that's exactly what 
   Microsoft's Standard VGA driver does for the R5G6B5 and X8R8G8B8 
   formats.
   http://www.winehq.org/pipermail/wine-patches/2013-February/122388.html

* See the exact list of formats returned by IDirect3D8::EnumAdapterModes()
   http://newtestbot.winehq.org/JobDetails.pl?Key=243&log_103=1#k103
   Test executable and source:
   https://bugs.freedesktop.org/attachment.cgi?id=75248

* See the list of formats that IDirect3D8::EnumAdapterModes() claims 
   are supported, and how CheckDeviceType() refuses them.
   http://newtestbot.winehq.org/JobDetails.pl?Key=249&log_103=1#k103
   Test executable and source:
   https://bugs.freedesktop.org/attachment.cgi?id=75260

* I think it's important to get Spice's QXL driver and Wine's 
   conformance tests to play nice together. First they are both 
   open-source so if one is wrong we should work to resolve that. But 
   also the new WineTestBot is uses QEmu and the QXL driver looks like 
   it will be _the_ paravirtualized(*) graphics driver there.
   (*) I.e. high performance and most used driver.

* See also QXL bug 61227:
   https://bugs.freedesktop.org/show_bug.cgi?id=61227

[Stefan Dösinger]

Am 21.02.2013 um 17:24 schrieb Francois Gouget :
> In essence our tests say that the driver must not support X1R5G5B5. Why?

I think the tests were written this way because we did not find any driver that exposed this format, and we had a lot of cases in other areas where exposing additional features broke games.

There are also potential issues because X1R5G5B5 is a 16 bit format, just like R5G6B5, which makes depth<->format mapping tricky. If the current setup uses a color depth of 16 bits and the app does not request a specific adapter format, which one does the driver choose?

[Henri Verbeet]

On 23 February 2013 16:42, Stefan Dösinger  wrote:
> There are also potential issues because X1R5G5B5 is a 16 bit format, just like R5G6B5, which makes depth<->format mapping tricky. If the current setup uses a color depth of 16 bits and the app does not request a specific adapter format, which one does the driver choose?

I don't think applications can actually do that. (Although if you mean
backbuffer format instead of adapter format there, that would just be
whatever format it's currently using.)

Personally, I suspect the test is just overly restrictive. Yes, there
have been a couple of cases where applications break if you expose
e.g. certain texture formats, but I don't think it necessarily makes
sense to write tests like that until you actually find an application
that breaks because of it. That doesn't mean it isn't a pretty
uncommon format and something the QXL people may want to look into,
but I don't think we want the tests to fail because of it.
CheckDeviceType() probably just fails for every format combination
because the driver can't do 3D.

[Henri Verbeet]

On 23 February 2013 17:20, Henri Verbeet  wrote:
> Personally, I suspect the test is just overly restrictive.

Also, just to clarify something, initially on IRC I was under the
impression the driver *only* exposed X1R5G5B5, i.e. instead of
X8R8G8B8, while clearly supporting 32 bpp display modes. That would be
much more suspicious than just exposing X1R5G5B5 instead of the more
common R5G6B5.

[Francois Gouget]

On Sat, 23 Feb 2013, Henri Verbeet wrote:
> On 23 February 2013 17:20, Henri Verbeet  wrote:
> > Personally, I suspect the test is just overly restrictive.
>
> Also, just to clarify something, initially on IRC I was under the
> impression the driver *only* exposed X1R5G5B5, i.e. instead of
> X8R8G8B8, while clearly supporting 32 bpp display modes.

Yes, that's probably my fault as that's what I believed too initially. 
But I have since run tests to list all the supported format and QXL 
exposes both X1R5G5B5 and X8R8G8B8:

http://newtestbot.winehq.org/JobDetails.pl?Key=243&log_103=1#k103