Re: [PATCH 1/3] wineoss.drv: Attempt to verify that the system is actually running OSS
On 07/24/2011 06:56 PM, Vitaliy Margolen wrote: On 07/22/2011 08:35 AM, Andrew Eikum wrote: This is really crude, but does seem to work. I tested it correct with just ALSA 1.0.24; ALSA 1.0.24's snd-pcm-oss and snd-pcm-mixer modules; and on OSS4.2. It was also tested by Gerald Pfeifer on FreeBSD 8.2 and 9.0. This lets us attempt to load the OSS driver, and if that fails, then try the ALSA driver. Automatic driver selection! You forgetting, that users can select multiple drivers in winecfg now. And that's what some people have in their registry. They can, but it's non-functional by design in MMDevAPI. winecfg even says, Selecting multiple drivers is not recommended. The actual approach is seems fishy to me as well. The reason ALSA driver is 1st is because most systems has it as the main sound subsystem. Putting something [oss] first in the list, and failing if it wasn't explicitly asked for defeats the whole idea about something being default, and having alternate fallback(s). With same logic one would add all other sound drivers and make them fail, unless explicitly asked for. I don't really understand. Maybe you're misunderstanding the logic in verify_actually_oss(). The registry entry check only occurs if the user has a driver specified in the registry. If there is no driver in the registry, as in a clean prefix, then the rest of the check will be run. The idea is that if the user specifically requests OSS in the registry, then we should not fail to load the OSS driver, even if the oss_sysinfo struct looks wrong. The problem is that there is no way to ask the question What audio system is currently being used?, so we have to come up with some other way to make a selection. Between OSS and ALSA, this was the most reliable method I could find. ALSA's OSS compatability doesn't properly fill the oss_sysinfo struct. If that struct looks wrong, then we fail to load the driver and fall back on the next one, ALSA. We could certainly have done it the other way around: try to load ALSA unless we detect that ALSA isn't actually in use, and then fall back on OSS. But there is no reliable way to differentiate between true ALSA, and OSS's ALSA compatability. Andrew
Re: [PATCH 1/3] wineoss.drv: Attempt to verify that the system is actually running OSS
Andrew Eikum aei...@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.
--
Alexandre Julliard
julli...@winehq.org
Re: [PATCH 1/3] wineoss.drv: Attempt to verify that the system is actually running OSS
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
Re: [PATCH 1/3] wineoss.drv: Attempt to verify that the system is actually running OSS
Andrew Eikum aei...@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. -- Alexandre Julliard julli...@winehq.org
Re: [PATCH 1/3] wineoss.drv: Attempt to verify that the system is actually running OSS
On 07/25/2011 12:33 PM, Alexandre Julliard wrote: Andrew Eikumaei...@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
Re: [PATCH 1/3] wineoss.drv: Attempt to verify that the system is actually running OSS
Andrew Eikum aei...@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 julli...@winehq.org
Re: [PATCH 1/3] wineoss.drv: Attempt to verify that the system is actually running OSS
On 07/22/2011 08:35 AM, Andrew Eikum wrote: This is really crude, but does seem to work. I tested it correct with just ALSA 1.0.24; ALSA 1.0.24's snd-pcm-oss and snd-pcm-mixer modules; and on OSS4.2. It was also tested by Gerald Pfeifer on FreeBSD 8.2 and 9.0. This lets us attempt to load the OSS driver, and if that fails, then try the ALSA driver. Automatic driver selection! You forgetting, that users can select multiple drivers in winecfg now. And that's what some people have in their registry. The actual approach is seems fishy to me as well. The reason ALSA driver is 1st is because most systems has it as the main sound subsystem. Putting something [oss] first in the list, and failing if it wasn't explicitly asked for defeats the whole idea about something being default, and having alternate fallback(s). With same logic one would add all other sound drivers and make them fail, unless explicitly asked for. Vitaliy.
