Request for comments on patch

Roderick Colenbrander thunderbird2k at gmail.com
Sun Jun 14 16:48:32 CDT 2009


On Sun, Jun 14, 2009 at 11:44 PM, Erich Hoover<ehoover at mines.edu> wrote:
> On Sun, Jun 14, 2009 at 3:33 PM, Mike
> Kaplinskiy<mike.kaplinskiy at gmail.com> wrote:
>> ...
>>
>> I didn't mean symlinking to the /lib/wine directory, but rather,
>> symlinking to prefix/windows/system32/ from /lib/wine/ . But since
>> that isn't done either, just copying to a new filename also seems
>> reasonable. Sadly if we do have a registry-based mechanism for
>> selection, this might not be possible to do on wineboot (unless there
>> is a way to check on every startup?)
>>
>
> A copy would probably be fine, I'm not familiar with how this is
> handled though so I'd have to look into it.
>
>> Stubbing dlls for every possible driver (even if there are only 2-3)
>> seems too much, so a general driver should be available. I'm just not
>> too sure on how to convert between that driver's filename and the
>> specific filename that our table gives.
>>
>
> I'm not sure exactly what you're referring to here.
>
>>>
>>> "struct driver_version_information" contains the vendor as an integer
>>> already, a separate structure could easily contain columns for
>>> matching the Vendor and OS in order to return a driver filename.  That
>>> way you wouldn't end up with a giant "struct
>>> driver_version_information".
>>
>> Yes that is what I meant to say, sorry if I didn't make my intentions
>> clear. I was just thinking about the size of the driver_version_table
>> array - 5-10 os's, 30-40 drivers already there...that's 150-400
>> entries, and adding something like WINVER_ANY (as a last resort when
>> matching) would make it a smaller.
>>
>
> There are only a couple different manufacturers, you don't need an
> entry for each specific driver.  There would only be
> OSVersion*Manufacturer combinations.
>
> Erich Hoover
> ehoover at mines.edu
>

Also note as I documented in the card detection code that we don't
care about the exact card but about the functionality we can offer
(that's also what games care about). In case of d3d10 even if you have
a radeon hd4800 (so d3d10 capable) and there is no geometry shader
support in the drivers then it doesn't make sense to report this card
(games might be so stupid to detect the hd4800 and based on that load
the d3d9 or d3d10 backend). The gpu features also depend on the use of
direct or indirect rendering. We always need to get the card at run
time.

Roderick



More information about the wine-devel mailing list