Andrew Eikum aeikum@codeweavers.com writes:
+/* Attempt to determine if we are running on OSS or ALSA's OSS compatability
- layer. There is no official way to do that, so just check for validity
- as best as possible, without rejecting valid OSS implementations. */
+static BOOL verify_actually_oss(void) +{
- int mixer_fd;
- oss_sysinfo sysinfo;
- HKEY key;
- static const WCHAR drv_key[] = {'S','o','f','t','w','a','r','e','\',
'W','i','n','e','\\','D','r','i','v','e','r','s',0};- static const WCHAR drv_value[] = {'A','u','d','i','o',0};
- static const WCHAR ossW[] = {'O','S','S'};
- /* if the user has specified a driver explicitly, then succeed
* if they want OSS and fail if they don't */- if(RegOpenKeyW(HKEY_CURRENT_USER, drv_key, &key) == ERROR_SUCCESS){
WCHAR driver_name[256];DWORD size = sizeof(driver_name);if(RegQueryValueExW(key, drv_value, 0, NULL, (BYTE*)driver_name,&size) == ERROR_SUCCESS){RegCloseKey(key);if(!lstrcmpiW(ossW, driver_name))return TRUE;return FALSE;}RegCloseKey(key);- }
It's not the driver's business to check the configuration key. If there's really a need to know if some other driver was configured, this info should be passed from the driver loader. But it would be preferable to avoid that.
On 07/25/2011 09:09 AM, Alexandre Julliard wrote:
It's not the driver's business to check the configuration key. If there's really a need to know if some other driver was configured, this info should be passed from the driver loader. But it would be preferable to avoid that.
I see your point. The idea was to give the user an override, in case the OSS detection isn't smart enough and refuses to load a legitimate implementation. If the user explicitly tells us to use OSS, then I think the heuristics in DllMain should be ignored; nothing in there is "critical" to our OSS driver.
MMDevAPI could pass some "explicit" flag to the driver, but DllMain doesn't take arguments (right?). It looks like we'd have to put the explicit flag into GetEndpointIDs and change MMDevAPI to check that function during driver load time, or create a new Initialize() entry point.
Do you prefer either of those options? Should I just go back to the drawing board on the whole idea?
Andrew
Andrew Eikum aeikum@codeweavers.com writes:
On 07/25/2011 09:09 AM, Alexandre Julliard wrote:
It's not the driver's business to check the configuration key. If there's really a need to know if some other driver was configured, this info should be passed from the driver loader. But it would be preferable to avoid that.
I see your point. The idea was to give the user an override, in case the OSS detection isn't smart enough and refuses to load a legitimate implementation. If the user explicitly tells us to use OSS, then I think the heuristics in DllMain should be ignored; nothing in there is "critical" to our OSS driver.
MMDevAPI could pass some "explicit" flag to the driver, but DllMain doesn't take arguments (right?). It looks like we'd have to put the explicit flag into GetEndpointIDs and change MMDevAPI to check that function during driver load time, or create a new Initialize() entry point.
Do you prefer either of those options? Should I just go back to the drawing board on the whole idea?
I guess we could have some sort of priority mechanism, where the driver can returns its priority, and the loader tries them all and keeps the highest one.
We also probably need a way to have only mmdevapi handle loading so that winmm doesn't need to duplicate the search strategy. Though the mmdevapi side will need to be fixed to support the correct registry syntax.
On 07/25/2011 12:33 PM, Alexandre Julliard wrote:
Andrew Eikumaeikum@codeweavers.com writes:
On 07/25/2011 09:09 AM, Alexandre Julliard wrote:
It's not the driver's business to check the configuration key. If there's really a need to know if some other driver was configured, this info should be passed from the driver loader. But it would be preferable to avoid that.
I see your point. The idea was to give the user an override, in case the OSS detection isn't smart enough and refuses to load a legitimate implementation. If the user explicitly tells us to use OSS, then I think the heuristics in DllMain should be ignored; nothing in there is "critical" to our OSS driver.
MMDevAPI could pass some "explicit" flag to the driver, but DllMain doesn't take arguments (right?). It looks like we'd have to put the explicit flag into GetEndpointIDs and change MMDevAPI to check that function during driver load time, or create a new Initialize() entry point.
Do you prefer either of those options? Should I just go back to the drawing board on the whole idea?
I guess we could have some sort of priority mechanism, where the driver can returns its priority, and the loader tries them all and keeps the highest one.
Mm, don't see much of a difference between this and an ordered list in the code like we are using now. This also doesn't solve the original problem of a broken OSS continuing to fail to load even if the user explicitly requests OSS in the registry.
We also probably need a way to have only mmdevapi handle loading so that winmm doesn't need to duplicate the search strategy. Though the mmdevapi side will need to be fixed to support the correct registry syntax.
Yes, that would be nice. What do you mean "correct registry syntax"? Do you mean listing multiple drivers? I don't see any reason to support that.
Andrew
Andrew Eikum aeikum@codeweavers.com writes:
Mm, don't see much of a difference between this and an ordered list in the code like we are using now. This also doesn't solve the original problem of a broken OSS continuing to fail to load even if the user explicitly requests OSS in the registry.
The difference is that the priority would be determined dynamically, so the OSS driver would return a low priority if it detects ALSA emulation.
We also probably need a way to have only mmdevapi handle loading so that winmm doesn't need to duplicate the search strategy. Though the mmdevapi side will need to be fixed to support the correct registry syntax.
Yes, that would be nice. What do you mean "correct registry syntax"? Do you mean listing multiple drivers? I don't see any reason to support that.
Yes, multiple drivers. That's necessary to make configurations portable.
-
Alexandre Julliard -
Andrew Eikum