In an effort to come up with a (hopefully palatable) solution to a couple of bugs I've put together the attached patch. Only the first of the two issues is currently handled, though the patch paves the way for the second issue.
1) Bug #15839: (not this title) Wine does not report the manufacturer driver (for example, "nv4_disp.dll" for nVidia users) 2) Wine does not always report the correct amount of video RAM (not sure if there is a bug number for this)
The approach handles graphics requests like this: "manufacturer" driver --> "OS" driver (normally winex11.drv)
Where the manufacturer driver (at present) forwards all requests to the OS driver. Later additions could provide driver-specific code for returning information such as the correct amount of video RAM. Also, the manufacturer driver is skipped (reverting to the current behavior) unless "HKEY_CURRENT_USER\Software\Wine\Drivers\ReportNativeVideoDriver" is set to "Y".
Note: patch makes changes to configure.ac, so cover your bases: autoheader && autoconf && ./configure && make depend && make
I'm particularly interested in comments related to how the driver is selected (__wine_get_video_driver in gdi32), but all feedback is welcome.
Erich Hoover ehoover@mines.edu
I don't know about stubbing drivers, but I remember that autodetection/registry wasn't accepted on the fallout 3 patch. I think AJ would prefer something like http://source.winehq.org/git/wine.git/?a=commit;h=f2e2e3e49947490368900ef06a... but for driver dll strings.
But take my comments with a grain of salt. I just watch the list most of the time and don't really understand the graphics stuff too well.
Mike.
On Sun, Jun 14, 2009 at 3:38 PM, Erich Hooverehoover@mines.edu wrote:
In an effort to come up with a (hopefully palatable) solution to a couple of bugs I've put together the attached patch. Only the first of the two issues is currently handled, though the patch paves the way for the second issue.
- Bug #15839: (not this title) Wine does not report the manufacturer
driver (for example, "nv4_disp.dll" for nVidia users) 2) Wine does not always report the correct amount of video RAM (not sure if there is a bug number for this)
The approach handles graphics requests like this: "manufacturer" driver --> "OS" driver (normally winex11.drv)
Where the manufacturer driver (at present) forwards all requests to the OS driver. Later additions could provide driver-specific code for returning information such as the correct amount of video RAM. Also, the manufacturer driver is skipped (reverting to the current behavior) unless "HKEY_CURRENT_USER\Software\Wine\Drivers\ReportNativeVideoDriver" is set to "Y".
Note: patch makes changes to configure.ac, so cover your bases: autoheader && autoconf && ./configure && make depend && make
I'm particularly interested in comments related to how the driver is selected (__wine_get_video_driver in gdi32), but all feedback is welcome.
Erich Hoover ehoover@mines.edu
On Sun, Jun 14, 2009 at 2:26 PM, Mike Kaplinskiymike.kaplinskiy@gmail.com wrote:
I don't know about stubbing drivers, but I remember that autodetection/registry wasn't accepted on the fallout 3 patch. I think AJ would prefer something like http://source.winehq.org/git/wine.git/?a=commit;h=f2e2e3e49947490368900ef06a... but for driver dll strings.
But take my comments with a grain of salt. I just watch the list most of the time and don't really understand the graphics stuff too well.
Mike.
It's been some time since I've seen those patches pass through (it's also possible I missed the patch your talking about), but if I remember correctly there were a couple different reasons they were rejected. It sounded like the issue was that they reported a driver that doesn't exist and/or that the registry key manually specified a driver. My suggestion is that there's a "try to report the manufacturer driver" type registry key and that it, when activated, reports a real driver. This real driver then funnels the requests back to winex11.drv (with room to add additional non-funneled requests later, such as requesting the card's video RAM).
Erich Hoover ehoover@mines.edu
On Sun, Jun 14, 2009 at 10:45 PM, Erich Hooverehoover@mines.edu wrote:
On Sun, Jun 14, 2009 at 2:26 PM, Mike Kaplinskiymike.kaplinskiy@gmail.com wrote:
I don't know about stubbing drivers, but I remember that autodetection/registry wasn't accepted on the fallout 3 patch. I think AJ would prefer something like http://source.winehq.org/git/wine.git/?a=commit;h=f2e2e3e49947490368900ef06a... but for driver dll strings.
But take my comments with a grain of salt. I just watch the list most of the time and don't really understand the graphics stuff too well.
Mike.
It's been some time since I've seen those patches pass through (it's also possible I missed the patch your talking about), but if I remember correctly there were a couple different reasons they were rejected. It sounded like the issue was that they reported a driver that doesn't exist and/or that the registry key manually specified a driver. My suggestion is that there's a "try to report the manufacturer driver" type registry key and that it, when activated, reports a real driver. This real driver then funnels the requests back to winex11.drv (with room to add additional non-funneled requests later, such as requesting the card's video RAM).
Erich Hoover ehoover@mines.edu
The only thing I didn't add yet was driver identification as I didn't have time for it yet but I just plan to add that to a table in wined3d (the reported driver name depends also on the windows version). In the end adding such info to the display driver would make sense though but I don't think it brings us much at this point.
Roderick
On Sun, Jun 14, 2009 at 10:52 PM, Roderick Colenbranderthunderbird2k@gmail.com wrote:
On Sun, Jun 14, 2009 at 10:45 PM, Erich Hooverehoover@mines.edu wrote:
On Sun, Jun 14, 2009 at 2:26 PM, Mike Kaplinskiymike.kaplinskiy@gmail.com wrote:
I don't know about stubbing drivers, but I remember that autodetection/registry wasn't accepted on the fallout 3 patch. I think AJ would prefer something like http://source.winehq.org/git/wine.git/?a=commit;h=f2e2e3e49947490368900ef06a... but for driver dll strings.
But take my comments with a grain of salt. I just watch the list most of the time and don't really understand the graphics stuff too well.
Mike.
It's been some time since I've seen those patches pass through (it's also possible I missed the patch your talking about), but if I remember correctly there were a couple different reasons they were rejected. It sounded like the issue was that they reported a driver that doesn't exist and/or that the registry key manually specified a driver. My suggestion is that there's a "try to report the manufacturer driver" type registry key and that it, when activated, reports a real driver. This real driver then funnels the requests back to winex11.drv (with room to add additional non-funneled requests later, such as requesting the card's video RAM).
Erich Hoover ehoover@mines.edu
The only thing I didn't add yet was driver identification as I didn't have time for it yet but I just plan to add that to a table in wined3d (the reported driver name depends also on the windows version). In the end adding such info to the display driver would make sense though but I don't think it brings us much at this point.
Roderick
I forgot to mention the reason why previous registry key options didn't enter Wine. The reason was that we had to have a good default mechanism (e.g. returning nv4_disp.dll for nvidia by default on 2k/xp) before adding override keys. The registry keys can be added when this mechanism is around.
Roderick
On Sun, Jun 14, 2009 at 2:55 PM, Roderick Colenbranderthunderbird2k@gmail.com wrote:
...
I forgot to mention the reason why previous registry key options didn't enter Wine. The reason was that we had to have a good default mechanism (e.g. returning nv4_disp.dll for nvidia by default on 2k/xp) before adding override keys. The registry keys can be added when this mechanism is around.
Roderick
So, a patch similar to the one Mike pointed out* but able to report different drivers for different OSes would prove acceptable (possibly w/ a second patch for overrides)? The email was some time ago, but I thought someone was pretty adamant that Wine should not report a driver that does not exist and that was the major show-stopper.
Erich Hoover ehoover@mines.edu
* http://source.winehq.org/git/wine.git/?a=commit;h=f2e2e3e49947490368900ef06a...
Am Sonntag, 14. Juni 2009 23:11:42 schrieb Erich Hoover:
So, a patch similar to the one Mike pointed out* but able to report different drivers for different OSes would prove acceptable (possibly w/ a second patch for overrides)? The email was some time ago, but I thought someone was pretty adamant that Wine should not report a driver that does not exist and that was the major show-stopper.
Is there any app that depends on the real display driver name, or just the device description string? I lost overview of the situation :-/
There are some other problems to deal with:
*) If we create a stub / thunk driver for each known windows display driver, we potentially have all those thunks around. E.g. an app might complain that it finds BOTH nv4_disp.dll AND atiumdag.dll.
*) Providing these vendor specific DLLs can trigger other problems - for example, apps might start trying to call functions in the driver, but skip gracefully now. So we should see if the driver APIs are at least pseudo-documented
*) Centralized detection. If the gdi32 detection comes to a different conclusion than the wined3d one this may cause trouble. It may require moving the current wined3d GL based detection code to winex11.drv and use it from wined3d and gdi and others to report the same result everywhere.
On Sun, Jun 14, 2009 at 3:33 PM, Stefan Dösingerstefandoesinger@gmx.at wrote:
Am Sonntag, 14. Juni 2009 23:11:42 schrieb Erich Hoover:
So, a patch similar to the one Mike pointed out* but able to report different drivers for different OSes would prove acceptable (possibly w/ a second patch for overrides)? The email was some time ago, but I thought someone was pretty adamant that Wine should not report a driver that does not exist and that was the major show-stopper.
Is there any app that depends on the real display driver name, or just the device description string? I lost overview of the situation :-/
Yes, the one I'm most familiar with is Fallout 3. It's very tempting to whack Bethesda upside the head...
There are some other problems to deal with:
*) If we create a stub / thunk driver for each known windows display driver, we potentially have all those thunks around. E.g. an app might complain that it finds BOTH nv4_disp.dll AND atiumdag.dll.
You think that the very existence of extra DLLs would pose a problem? Even if the DLL detected that it was incorrect and failed on DllMain?
*) Providing these vendor specific DLLs can trigger other problems - for example, apps might start trying to call functions in the driver, but skip gracefully now. So we should see if the driver APIs are at least pseudo-documented
At least for the nvidia driver (nv4_disp.dll) there are no exposed functions, I don't currently have a driver disk for other manufacturers. However, it's possible that routines are exposed in some other way.
*) Centralized detection. If the gdi32 detection comes to a different conclusion than the wined3d one this may cause trouble. It may require moving the current wined3d GL based detection code to winex11.drv and use it from wined3d and gdi and others to report the same result everywhere.
I believe in the example that I attached that I found all of the detection code and put it in one centralized location.
Erich Hoover ehoover@mines.edu
On Sun, Jun 14, 2009 at 4:55 PM, Roderick Colenbranderthunderbird2k@gmail.com wrote:
On Sun, Jun 14, 2009 at 10:52 PM, Roderick Colenbranderthunderbird2k@gmail.com wrote:
On Sun, Jun 14, 2009 at 10:45 PM, Erich Hooverehoover@mines.edu wrote:
On Sun, Jun 14, 2009 at 2:26 PM, Mike Kaplinskiymike.kaplinskiy@gmail.com wrote:
I don't know about stubbing drivers, but I remember that autodetection/registry wasn't accepted on the fallout 3 patch. I think AJ would prefer something like http://source.winehq.org/git/wine.git/?a=commit;h=f2e2e3e49947490368900ef06a... but for driver dll strings.
But take my comments with a grain of salt. I just watch the list most of the time and don't really understand the graphics stuff too well.
Mike.
It's been some time since I've seen those patches pass through (it's also possible I missed the patch your talking about), but if I remember correctly there were a couple different reasons they were rejected. It sounded like the issue was that they reported a driver that doesn't exist and/or that the registry key manually specified a driver. My suggestion is that there's a "try to report the manufacturer driver" type registry key and that it, when activated, reports a real driver. This real driver then funnels the requests back to winex11.drv (with room to add additional non-funneled requests later, such as requesting the card's video RAM).
Erich Hoover ehoover@mines.edu
The only thing I didn't add yet was driver identification as I didn't have time for it yet but I just plan to add that to a table in wined3d (the reported driver name depends also on the windows version). In the end adding such info to the display driver would make sense though but I don't think it brings us much at this point.
Roderick
I forgot to mention the reason why previous registry key options didn't enter Wine. The reason was that we had to have a good default mechanism (e.g. returning nv4_disp.dll for nvidia by default on 2k/xp) before adding override keys. The registry keys can be added when this mechanism is around.
Roderick
Then perhaps when this mechanism is in place, we can add a way to have 1 general "funnel" dll and symlink it on prefix creation (if it's not already there). This way we don't have to worry about newer graphics cards as much, and if there is a specific implementation for a specific brand/card we can use it instead of the general one.
As for the files being different on different windows' - maybe extending the list to also return different rows based on the windows version (and also add WINVER_ALL as wildcard) would work. But that seems rather hacky, and the whole business doesn't seem like it would give too much benefit.
Mike.
On Sun, Jun 14, 2009 at 3:13 PM, Mike Kaplinskiymike.kaplinskiy@gmail.com wrote:
...
Then perhaps when this mechanism is in place, we can add a way to have 1 general "funnel" dll and symlink it on prefix creation (if it's not already there). This way we don't have to worry about newer graphics cards as much, and if there is a specific implementation for a specific brand/card we can use it instead of the general one.
As for the files being different on different windows' - maybe extending the list to also return different rows based on the windows version (and also add WINVER_ALL as wildcard) would work. But that seems rather hacky, and the whole business doesn't seem like it would give too much benefit.
Mike.
I was considering that method of "funneling" at first, but since there are no DLL symlinks in */lib/wine/ currently I figured this would prove objectionable. I also didn't realize the driver name is reported differently on different OS versions (which makes for a lot more driver filenames).
"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".
Erich Hoover ehoover@mines.edu
On Sun, Jun 14, 2009 at 5:20 PM, Erich Hooverehoover@mines.edu wrote:
On Sun, Jun 14, 2009 at 3:13 PM, Mike Kaplinskiymike.kaplinskiy@gmail.com wrote:
...
Then perhaps when this mechanism is in place, we can add a way to have 1 general "funnel" dll and symlink it on prefix creation (if it's not already there). This way we don't have to worry about newer graphics cards as much, and if there is a specific implementation for a specific brand/card we can use it instead of the general one.
As for the files being different on different windows' - maybe extending the list to also return different rows based on the windows version (and also add WINVER_ALL as wildcard) would work. But that seems rather hacky, and the whole business doesn't seem like it would give too much benefit.
Mike.
I was considering that method of "funneling" at first, but since there are no DLL symlinks in */lib/wine/ currently I figured this would prove objectionable. I also didn't realize the driver name is reported differently on different OS versions (which makes for a lot more driver filenames).
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?)
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.
"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.
Erich Hoover ehoover@mines.edu
Mike.
On Sun, Jun 14, 2009 at 3:33 PM, Mike Kaplinskiymike.kaplinskiy@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@mines.edu
On Sun, Jun 14, 2009 at 11:44 PM, Erich Hooverehoover@mines.edu wrote:
On Sun, Jun 14, 2009 at 3:33 PM, Mike Kaplinskiymike.kaplinskiy@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@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
Does the attached sound more like what people are looking for (with driver_filename_table filled in a bit more, of course)?
Erich Hoover ehoover@mines.edu
On Sun, Jun 14, 2009 at 5:33 PM, Stefan Dösingerstefandoesinger@gmx.at wrote:
*) If we create a stub / thunk driver for each known windows display driver, we potentially have all those thunks around. E.g. an app might complain that it finds BOTH nv4_disp.dll AND atiumdag.dll.
*) Providing these vendor specific DLLs can trigger other problems - for example, apps might start trying to call functions in the driver, but skip gracefully now. So we should see if the driver APIs are at least pseudo-documented
Can we form a mob after the people that do this? For the first point that would mean the app has hardcoded mappings since we only report one filename. But this situation is also possible in windows if you switch video cards, so it would fail on windows as well.
For the second point, as said previously, we can have a generic stub dll and a specific one. Since (as Erich notes) nvdia doesn't export any symbols, we can use the generic one for it. If ATI exports symbols we write a specialized one. And in the worst case we fail in DllMain. I doubt there are many apps that do this.
On Sun, Jun 14, 2009 at 7:09 PM, Erich Hooverehoover@mines.edu wrote:
Does the attached sound more like what people are looking for (with driver_filename_table filled in a bit more, of course)?
Erich Hoover ehoover@mines.edu
I'm a little queasy about a forceful vendor-os combo: what stops vendors from having different driver filenames for different cards? What I had in mind when I was thinking of the multi-version solution was: struct driver_version_information { WORD vendor; /* reported PCI card vendor ID */ WORD card; /* reported PCI card device ID */ + driver_os_version os; const char *description; /* Description of the card e.g. NVIDIA RIVA TNT */ + const char *driver_filename; WORD hipart_hi, hipart_lo; /* driver hiword to report */ WORD lopart_hi, lopart_lo; /* driver loword to report */ };
But if noone has problems about the vendor-os combo then this is perfect.
Mike.
2009/6/15 Mike Kaplinskiy mike.kaplinskiy@gmail.com:
On Sun, Jun 14, 2009 at 5:33 PM, Stefan Dösingerstefandoesinger@gmx.at wrote:
*) If we create a stub / thunk driver for each known windows display driver, we potentially have all those thunks around. E.g. an app might complain that it finds BOTH nv4_disp.dll AND atiumdag.dll.
*) Providing these vendor specific DLLs can trigger other problems - for example, apps might start trying to call functions in the driver, but skip gracefully now. So we should see if the driver APIs are at least pseudo-documented
Can we form a mob after the people that do this? For the first point that would mean the app has hardcoded mappings since we only report one filename. But this situation is also possible in windows if you switch video cards, so it would fail on windows as well.
The point is that Wine shouldn't act as if there are (or have been) multiple video cards for this reason - the apps could hate you for it. As Roderick said, the correct driver name has to be selected at runtime, and based on the features exposed by the OpenGL/GLX/driver implementation.
For the second point, as said previously, we can have a generic stub dll and a specific one. Since (as Erich notes) nvdia doesn't export any symbols, we can use the generic one for it. If ATI exports symbols we write a specialized one. And in the worst case we fail in DllMain. I doubt there are many apps that do this.
You make it sound easy!
On Sun, Jun 14, 2009 at 8:33 PM, Ben Kleinshacklein@gmail.com wrote:
2009/6/15 Mike Kaplinskiy mike.kaplinskiy@gmail.com:
On Sun, Jun 14, 2009 at 5:33 PM, Stefan Dösingerstefandoesinger@gmx.at wrote:
*) If we create a stub / thunk driver for each known windows display driver, we potentially have all those thunks around. E.g. an app might complain that it finds BOTH nv4_disp.dll AND atiumdag.dll.
*) Providing these vendor specific DLLs can trigger other problems - for example, apps might start trying to call functions in the driver, but skip gracefully now. So we should see if the driver APIs are at least pseudo-documented
Can we form a mob after the people that do this? For the first point that would mean the app has hardcoded mappings since we only report one filename. But this situation is also possible in windows if you switch video cards, so it would fail on windows as well.
The point is that Wine shouldn't act as if there are (or have been) multiple video cards for this reason - the apps could hate you for it. As Roderick said, the correct driver name has to be selected at runtime, and based on the features exposed by the OpenGL/GLX/driver implementation.
The correct driver name will be selected. I believe what Stefan is saying is that other dlls may be present due to previous configurations. What I am trying to say is that this will fail to work on windows as well. In the best case where the driver filename never gets changed, our behavior will match that of windows.
If this is still undesirable, we can purge system32 of all the driver-specific dll's and copy the correct dll at init every time.
For the second point, as said previously, we can have a generic stub dll and a specific one. Since (as Erich notes) nvdia doesn't export any symbols, we can use the generic one for it. If ATI exports symbols we write a specialized one. And in the worst case we fail in DllMain. I doubt there are many apps that do this.
You make it sound easy!
I'm talking about building an empty dll and then copying it over when the driver file name we return doesn't actually exist. Perhaps we can't (easily) change the version information during the copy but as a starting point, just copying the file will be good enough. So something like:
if (!exists(prefix/system32/current driver's .dll)) { if (exists(/usr/lib/wine/current driver's .dll.so)) copy(/usr/lib/wine/current driver's .dll.so, prefix/system32/current driver's .dll); else copy(/usr/lib/wine/generic driver .dll.so, prefix/system32/current driver's .dll); }
And the generic driver.dll.so will have a DllMain which returns false. Am I missing something important?
Mike.
-
Ben Klein -
Erich Hoover -
Mike Kaplinskiy -
Roderick Colenbrander -
Stefan Dösinger