[Bug 21515] VENDOR_WINE vs VENDOR_ATI with xf86-video-ati

wine-bugs at winehq.org wine-bugs at winehq.org
Wed Feb 3 04:45:48 CST 2010


http://bugs.winehq.org/show_bug.cgi?id=21515





--- Comment #24 from P.Panon <ppanon at shaw.ca>  2010-02-03 04:45:48 ---
Thanks Cùran,

Looks like I made a typo and it should have been +d3d_caps. Currently, I only
see a Directx8 capability when I run with that trace.

I'm not quite sure how to resolve the fixme for init_driver_info(). It looks
like it's necessary to set the driver_info parameters that are passed to
Windows apps. However it requires the vendor code to match the list in
driver_version_table[]. While I could hack it to use VENDOR_ATI, at some point,
somebody is going to add support for the Intel 3D-accelerated Mesa or nouveau
drivers as well. The problem is that the device number isn't unique across
vendors, but if the vendor is VENDOR_MESA, then we don't know if it's really an
ATI or INTEL, and the GL vendor and renderer strings aren't available to figure
it out like they are in wined3d_guess_vendor() wined3d_guess_device()

While it would be possible to modify init_driver_info() to also pass in the GL
vendor again, it's not good for function orthogonality and there may be other
places where that info eventually becomes necessary. I suspect it would
actually be better to split VENDOR_MESA into VENDOR_MESA_ATI,
VENDOR_MESA_INTEL, VENDOR_MESA_SOFTPIPE(?), etc so that the actual card vendor
information is carried through the wined3d_pci_vendor enumeration. Hopefully
one of the wine devs will clarify which way to go.

-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.


More information about the wine-bugs mailing list