On Tue, May 16, 2017 at 9:40 AM, Józef Kucia joseph.kucia@gmail.com wrote:
I'm just a bit skeptical about usefulness of this extension in Wine besides your use-case.
Definitely understandable. I think it's a big enough one to justify it in and of itself, however; this is critical middleware for a rapidly expanding library of games and applications. And I think getting SteamVR itself running in Wine is unrealistic due to how hardware-dependent it is.
I'm not aware of such problems. Other WGL extensions are already implemented in Wine, see dlls/winex11.drv/opengl.c. In this case it may be a little harder though, the extension has to understand D3D9, D3D10 and D3D11 interfaces, and it has to talk to wined3d, and it has to presumably map GL objects to internal wined3d GL objects.
I was asking because I'm completely naive to how IP works with OpenGL/WGL extensions. I take it, then, the vendor prefix has no bearing on whether any kind of permission or license is needed for implementation on the host side of things based solely on the public specification? I must sound so green...
It's going to be some time, as I want to get a few Vulkan and/or OpenGL programs to the point of submitting frames to the compositor before I tackle the D3D nut, but if no one else looks in the meantime, I'll have a go at implementing the dx_interop extensions and putting together a pullreq myself. I mostly wanted to gauge the viability of the project, as never having D3D11 support at all would defeat a large part of the point.