Implementation patches for d3drm's CreateDeviceFromD3D.

[Aaryaman Vasishta]

Attached is the patches for implementing CreateDeviceFromD3D. Please take a
look and provide feedback, if any.



Thank you!
Aaryaman

[Stefan Dösinger]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

They look quite good: One suggestion though: Do you need the separate
implementations for IDirect3DRM1 and IDirect3DRM3? It seems that you
could thunk d3drm2 and d3drm3 to d3drm1 and work with just one
implementation. That works because you don't need a separate way to
create the device like you do in the cases where you create the
immediate mode device yourself.

Yeah, I know that the thunk direction would be different from the
other methods, but I think that's something we can live with. The
thunk direction is forced by the IM device QI limitations and thunking
is preferred over code duplication if it's possible.

However, there's one thing you need to test first: can you QI
IDirect3DRMDevice3 from IDirect3DRMDevice(1)? Or do D3DRM Devices have
the same kind of restriction (down-QI'ing only) as IM devices?

Cheers,
Stefan

Am 2015-08-08 um 00:20 schrieb Aaryaman Vasishta:
> Attached is the patches for implementing CreateDeviceFromD3D.
> Please take a look and provide feedback, if any.
>
> Thank you! Aaryaman

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBAgAGBQJVyO4rAAoJEN0/YqbEcdMwHeQQAI8v5mJmRPhMlVkl5gnUu0ya
AWRdaN4+FE1WvicUP+RCb3qYiFqbSCsF/GIfLVHhE4J52mtiuhYRZ8d/gmPi1xZb
+6jusXxzz2RnXm9OHhapmdULQRA4JoTSk8cngiG49nT99V+5NMl6lVOhZnOdcddw
tVsRQIbSZa6g4xFwNA8QiEoBXNrJRLOyOggURdMP4tg4flx7WTlyqdtlpZ9K9Ykq
WTsypE8Cdo5elWuLpUT3uHpVudBD0GW9aN1SEJNJd/4/lYepyoeAUR9A1fmhgLEG
+xACD/uEFXwmXo1IoWOHfnS+HysXJGfMnRUQeJPScki3MkXncAJk+n70NvlX+fe8
WA5DIt0p2k19VR5h66uePaSQtdSPuBYEcvdsNafLUdzl2WsayxnRA87VLRQl5R6S
66/7X4AsXhxh9k/jnl9DFwfBvKQVMuarON06lNqS/pHoUP0/XGeis60PaqovmYiN
9wkG02jQnt9pGKp+4nCVn3nZwK1D2iMQeKatpCMH14f2rRRjIKjVSxCJ1bKYv3gp
cElRUBfL2nb8G+29HaAOuoRZ/VOzWcJD3ci0G+EeXNwjn/utFjXQptFHdUWoK7PV
CqRx0vOnuz4Tdl5cNZLGpQUbmBHJUww2RKoTrLuEz9NxK+bP/BxSLhrjyJzNoZhQ
O1APG6jnsjtMjC6gcZup
=u10f
-----END PGP SIGNATURE-----

[Aaryaman Vasishta]

> However, there's one thing you need to test first: can you QI
> IDirect3DRMDevice3 from IDirect3DRMDevice(1)? Or do D3DRM Devices have
> the same kind of restriction (down-QI'ing only) as IM devices?

I've written device QI tests (quick look: http://pastebin.com/5bpRizmr need
to remove the last boolean flag column as it's unnecessary now) and you can
query up-down across all versions.
Now that I know that thunks are preferred, I'll do just that and reply with
the changes here as soon as I can.

Cheers,
Jam

[Stefan Dösinger]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 2015-08-10 um 20:41 schrieb Aaryaman Vasishta:
> I've written device QI tests (quick look:
> http://pastebin.com/5bpRizmr need to remove the last boolean flag
> column as it's unnecessary now) and you can query up-down across
> all versions.
> The follow-up question is: What happens if you create an
> IDirect3DRMDevice via CreateDeviceFromD3D, QI IDirect3DRMDevice2 or 3
> from it and then call GetDirect3DDevice2. In plain ddraw you can't get
> a device2 from a device1, so I'd expect the d3drm call to fail in some
> way.

I suspect your way to use QueryInterface in GetDirect3DDevice2 already
implements the right behavior. Please add a test for this somewhere.

I think testing this with a d3drm device that was created via
CreateDeviceFromClipper should work too. Your
IDirect3DDevice::QueryInterface(&IID_IDirectDrawSurface) call in the
version 1 test to get the render target shows that the device was
created as a v1 device.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBAgAGBQJVyQmKAAoJEN0/YqbEcdMwFi0P+gIvNUxDgs2Ooqnj54aEF8s6
XK9b0oZ8rVZQ3TviMV/fIPCoMXeCdY8EFKEhEFVTigAVdJda2t84153Lrk+fTx6I
h9DSLmrXh2fpuCvGv0efnGdDScUchdxqcp6M2u+Ha/AA8w+kaDtqqO2NXDHG0bnK
5YoLT3SH3twbozTHDIaGlGWFIb/97Zw5ZcpdO9qG1ukt6Nlr/7p5kZeXQP+xU4Xk
mATeMx4UPrTyRqCBq4nWirEk3h0SMWZHno+S6CAlYTdMohSvOmivWJAmQpL5YrzD
grVvnMq+vTggqaKvV5d5VtZX82z8JQt1ZTzCLc1OOu+QnOTQsmEgmiycIGK25ngc
eft/41TTVl3Lqipm75frGfyBm5bDe5DL/ELNJKKFvhVHohg/lcjoxONpJXVBCeb5
RnqvLWxeg21h6kU9NYeeNjL7OUiMXyT1vYHmCki7QT5X2eXntJSmmJO3p2eXnrWY
MDHGh1k8/rB5+wrKXyq9AMnPNesBLgBCMnFQGK+oij/FZhAPjEraisoz8qMAy5DZ
EEYUwnLfJdYECQ3ZXNagmJOdecMvgSO9QrBzo1F0psiOdefrZzxdfomsUA8vJ7d7
WkIWLw8ug/OjnOuT7Vr2Mkdy1GTQzkRn+Ih/oEButhNQ6u6IDLftNwBq9gn4hL/K
niROk7IH4pH0DDZZ61Mf
=5hW8
-----END PGP SIGNATURE-----

[Aaryaman Vasishta]

I just found an odd behavior while performing that test on windows.

Querying IDirect3DRMDevice2 from IDirect3DRMDevice1, then calling
GetDirect3DDevice2 will return DD_OK but the device is set to NULL instead.
It just verifies ddraw behavior but at the same time doesn't return an
HRESULT error.

On Tue, Aug 11, 2015 at 1:58 AM, Stefan Dösinger <stefandoesinger(a)gmail.com>
wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Am 2015-08-10 um 20:41 schrieb Aaryaman Vasishta:
> > I've written device QI tests (quick look:
> > http://pastebin.com/5bpRizmr need to remove the last boolean flag
> > column as it's unnecessary now) and you can query up-down across
> > all versions.
> > The follow-up question is: What happens if you create an
> > IDirect3DRMDevice via CreateDeviceFromD3D, QI IDirect3DRMDevice2 or 3
> > from it and then call GetDirect3DDevice2. In plain ddraw you can't get
> > a device2 from a device1, so I'd expect the d3drm call to fail in some
> > way.
>
> I suspect your way to use QueryInterface in GetDirect3DDevice2 already
> implements the right behavior. Please add a test for this somewhere.
>
> I think testing this with a d3drm device that was created via
> CreateDeviceFromClipper should work too. Your
> IDirect3DDevice::QueryInterface(&IID_IDirectDrawSurface) call in the
> version 1 test to get the render target shows that the device was
> created as a v1 device.
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iQIcBAEBAgAGBQJVyQmKAAoJEN0/YqbEcdMwFi0P+gIvNUxDgs2Ooqnj54aEF8s6
> XK9b0oZ8rVZQ3TviMV/fIPCoMXeCdY8EFKEhEFVTigAVdJda2t84153Lrk+fTx6I
> h9DSLmrXh2fpuCvGv0efnGdDScUchdxqcp6M2u+Ha/AA8w+kaDtqqO2NXDHG0bnK
> 5YoLT3SH3twbozTHDIaGlGWFIb/97Zw5ZcpdO9qG1ukt6Nlr/7p5kZeXQP+xU4Xk
> mATeMx4UPrTyRqCBq4nWirEk3h0SMWZHno+S6CAlYTdMohSvOmivWJAmQpL5YrzD
> grVvnMq+vTggqaKvV5d5VtZX82z8JQt1ZTzCLc1OOu+QnOTQsmEgmiycIGK25ngc
> eft/41TTVl3Lqipm75frGfyBm5bDe5DL/ELNJKKFvhVHohg/lcjoxONpJXVBCeb5
> RnqvLWxeg21h6kU9NYeeNjL7OUiMXyT1vYHmCki7QT5X2eXntJSmmJO3p2eXnrWY
> MDHGh1k8/rB5+wrKXyq9AMnPNesBLgBCMnFQGK+oij/FZhAPjEraisoz8qMAy5DZ
> EEYUwnLfJdYECQ3ZXNagmJOdecMvgSO9QrBzo1F0psiOdefrZzxdfomsUA8vJ7d7
> WkIWLw8ug/OjnOuT7Vr2Mkdy1GTQzkRn+Ih/oEButhNQ6u6IDLftNwBq9gn4hL/K
> niROk7IH4pH0DDZZ61Mf
> =5hW8
> -----END PGP SIGNATURE-----

[Aaryaman Vasishta]

Here's the device QI patches along with supporting patches to fix d3drm's
QI behavior on unsupported interfaces.


Cheers,
Jam

On Tue, Aug 11, 2015 at 5:44 PM, Aaryaman Vasishta <
jem456.vasishta(a)gmail.com> wrote:
> I just found an odd behavior while performing that test on windows.
>
> Querying IDirect3DRMDevice2 from IDirect3DRMDevice1, then calling
> GetDirect3DDevice2 will return DD_OK but the device is set to NULL instead.
> It just verifies ddraw behavior but at the same time doesn't return an
> HRESULT error.
>
> On Tue, Aug 11, 2015 at 1:58 AM, Stefan Dösinger <
> stefandoesinger(a)gmail.com> wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Am 2015-08-10 um 20:41 schrieb Aaryaman Vasishta:
> > > I've written device QI tests (quick look:
> > > http://pastebin.com/5bpRizmr need to remove the last boolean flag
> > > column as it's unnecessary now) and you can query up-down across
> > > all versions.
> > > The follow-up question is: What happens if you create an
> > > IDirect3DRMDevice via CreateDeviceFromD3D, QI IDirect3DRMDevice2 or 3
> > > from it and then call GetDirect3DDevice2. In plain ddraw you can't get
> > > a device2 from a device1, so I'd expect the d3drm call to fail in some
> > > way.
> >
> > I suspect your way to use QueryInterface in GetDirect3DDevice2 already
> > implements the right behavior. Please add a test for this somewhere.
> >
> > I think testing this with a d3drm device that was created via
> > CreateDeviceFromClipper should work too. Your
> > IDirect3DDevice::QueryInterface(&IID_IDirectDrawSurface) call in the
> > version 1 test to get the render target shows that the device was
> > created as a v1 device.
> >
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v2
> >
> > iQIcBAEBAgAGBQJVyQmKAAoJEN0/YqbEcdMwFi0P+gIvNUxDgs2Ooqnj54aEF8s6
> > XK9b0oZ8rVZQ3TviMV/fIPCoMXeCdY8EFKEhEFVTigAVdJda2t84153Lrk+fTx6I
> > h9DSLmrXh2fpuCvGv0efnGdDScUchdxqcp6M2u+Ha/AA8w+kaDtqqO2NXDHG0bnK
> > 5YoLT3SH3twbozTHDIaGlGWFIb/97Zw5ZcpdO9qG1ukt6Nlr/7p5kZeXQP+xU4Xk
> > mATeMx4UPrTyRqCBq4nWirEk3h0SMWZHno+S6CAlYTdMohSvOmivWJAmQpL5YrzD
> > grVvnMq+vTggqaKvV5d5VtZX82z8JQt1ZTzCLc1OOu+QnOTQsmEgmiycIGK25ngc
> > eft/41TTVl3Lqipm75frGfyBm5bDe5DL/ELNJKKFvhVHohg/lcjoxONpJXVBCeb5
> > RnqvLWxeg21h6kU9NYeeNjL7OUiMXyT1vYHmCki7QT5X2eXntJSmmJO3p2eXnrWY
> > MDHGh1k8/rB5+wrKXyq9AMnPNesBLgBCMnFQGK+oij/FZhAPjEraisoz8qMAy5DZ
> > EEYUwnLfJdYECQ3ZXNagmJOdecMvgSO9QrBzo1F0psiOdefrZzxdfomsUA8vJ7d7
> > WkIWLw8ug/OjnOuT7Vr2Mkdy1GTQzkRn+Ih/oEButhNQ6u6IDLftNwBq9gn4hL/K
> > niROk7IH4pH0DDZZ61Mf
> > =5hW8
> > -----END PGP SIGNATURE-----

[Stefan Dösinger]

Hi,

Looks good, except for one thing: our d3d implementation allows querying IDirect3DRMWinDevice or similar. Please test this in the test.

Also you didn't include the GetDirect3DDevice2 patch in the mail. Was that intentional?

Cheers,
Stefan
> Am 16.08.2015 um 13:30 schrieb Aaryaman Vasishta <jem456.vasishta(a)gmail.com>:
>
> Here's the device QI patches along with supporting patches to fix d3drm's
> QI behavior on unsupported interfaces.
>
> Cheers,
> Jam
>
> On Tue, Aug 11, 2015 at 5:44 PM, Aaryaman Vasishta <
> jem456.vasishta(a)gmail.com> wrote:
> > I just found an odd behavior while performing that test on windows.
> >
> > Querying IDirect3DRMDevice2 from IDirect3DRMDevice1, then calling
> > GetDirect3DDevice2 will return DD_OK but the device is set to NULL instead.
> > It just verifies ddraw behavior but at the same time doesn't return an
> > HRESULT error.
> >
> > On Tue, Aug 11, 2015 at 1:58 AM, Stefan Dösinger <
> > stefandoesinger(a)gmail.com> wrote:
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA1
> > >
> > > Am 2015-08-10 um 20:41 schrieb Aaryaman Vasishta:
> > > > I've written device QI tests (quick look:
> > > > http://pastebin.com/5bpRizmr need to remove the last boolean flag
> > > > column as it's unnecessary now) and you can query up-down across
> > > > all versions.
> > > > The follow-up question is: What happens if you create an
> > > > IDirect3DRMDevice via CreateDeviceFromD3D, QI IDirect3DRMDevice2 or 3
> > > > from it and then call GetDirect3DDevice2. In plain ddraw you can't get
> > > > a device2 from a device1, so I'd expect the d3drm call to fail in some
> > > > way.
> > >
> > > I suspect your way to use QueryInterface in GetDirect3DDevice2 already
> > > implements the right behavior. Please add a test for this somewhere.
> > >
> > > I think testing this with a d3drm device that was created via
> > > CreateDeviceFromClipper should work too. Your
> > > IDirect3DDevice::QueryInterface(&IID_IDirectDrawSurface) call in the
> > > version 1 test to get the render target shows that the device was
> > > created as a v1 device.
> > >
> > > -----BEGIN PGP SIGNATURE-----
> > > Version: GnuPG v2
> > >
> > > iQIcBAEBAgAGBQJVyQmKAAoJEN0/YqbEcdMwFi0P+gIvNUxDgs2Ooqnj54aEF8s6
> > > XK9b0oZ8rVZQ3TviMV/fIPCoMXeCdY8EFKEhEFVTigAVdJda2t84153Lrk+fTx6I
> > > h9DSLmrXh2fpuCvGv0efnGdDScUchdxqcp6M2u+Ha/AA8w+kaDtqqO2NXDHG0bnK
> > > 5YoLT3SH3twbozTHDIaGlGWFIb/97Zw5ZcpdO9qG1ukt6Nlr/7p5kZeXQP+xU4Xk
> > > mATeMx4UPrTyRqCBq4nWirEk3h0SMWZHno+S6CAlYTdMohSvOmivWJAmQpL5YrzD
> > > grVvnMq+vTggqaKvV5d5VtZX82z8JQt1ZTzCLc1OOu+QnOTQsmEgmiycIGK25ngc
> > > eft/41TTVl3Lqipm75frGfyBm5bDe5DL/ELNJKKFvhVHohg/lcjoxONpJXVBCeb5
> > > RnqvLWxeg21h6kU9NYeeNjL7OUiMXyT1vYHmCki7QT5X2eXntJSmmJO3p2eXnrWY
> > > MDHGh1k8/rB5+wrKXyq9AMnPNesBLgBCMnFQGK+oij/FZhAPjEraisoz8qMAy5DZ
> > > EEYUwnLfJdYECQ3ZXNagmJOdecMvgSO9QrBzo1F0psiOdefrZzxdfomsUA8vJ7d7
> > > WkIWLw8ug/OjnOuT7Vr2Mkdy1GTQzkRn+Ih/oEButhNQ6u6IDLftNwBq9gn4hL/K
> > > niROk7IH4pH0DDZZ61Mf
> > > =5hW8
> > > -----END PGP SIGNATURE-----
>
> <0001-d3drm-Add-IDirect3DRMObject-to-be-queried-from-IDire.patch><0002-d3drm-Fix-IDirect3DRMDevice3_QueryInterface-returnin.patch><0003-d3drm-tests-Add-QueryInterface-tests-for-IDirect3DRM.patch>

[Aaryaman Vasishta]

> Also you didn't include the GetDirect3DDevice2 patch in the mail. Was that
> intentional?

I'm a bit confused. That patch is already there over at wine-patches with
the implementation patches, wheras these 3 patches just work on QI and
tests for it. Is the GetDirect3DDevice2 patch required here for building?

[Aaryaman Vasishta]

I realized you were talking about the GetDirect3DDevice2 fix which came
after the implementation patches, I had forgotten to include that, my bad.
I've attached them in this email.

Cheers,
Jam

On Mon, Aug 17, 2015 at 3:54 PM, Aaryaman Vasishta <
jem456.vasishta(a)gmail.com> wrote:
> > Also you didn't include the GetDirect3DDevice2 patch in the mail. Was
> > that intentional?
>
> I'm a bit confused. That patch is already there over at wine-patches with
> the implementation patches, wheras these 3 patches just work on QI and
> tests for it. Is the GetDirect3DDevice2 patch required here for building?