Minor DCD Kitchen issue with MSVC

[drgreenberg]

First, I'd like to express how impressed and pleased I've been with DCD's kitchen work. Our v3.0.1 phone was working great but I decided to update to v3.1.2 / radio v3.39 the other day just to stay up to date. Since we prefer MS Voice Command to the Cyberon stuff, I decided to bake VC into the ROM as an OEM rather than as a CAB (just to ensure a baseline voice dialing capability in the even of a hard reset). In doing so, I discovered an issue that prevents this from working correctly without a registry tweak after the fact.

Basically, in order for MSVC to work correctly with a Bluetooth headset, a couple of registry settings need to be in place. The key one is:

HKLM\Software\Microsoft\Bluetooth\AudioGateway
BTAGExtModule =vcbthag.dll

Another one that I have been applying (although I don't know if it's required any longer in v1.6) is

HKLM\Software\OEM\VoiceCommand
Path=\Windows\VoiceCMD.exe

These keys are actually set up correctly by the OEM installation folder for Voice Command. The problem with the kitchen, however, is that the .RGU file in the OEMDrivers folder in the kitchen's OEM folder seems to be applied *after* the .RGU file in the MSVC folder, causing them to be overwritten with default values that break the use of Bluetooth headsets with Voice Command.

I've edited the OEMDrivers .RGU file to fix this, but I imagine I'll have to do so with every kitchen release going forward. I'm wondering if it makes more sense to make sure that the .RGU files from any user-added OEMs are applied after OEMDrivers so that they can override the defaults with values appropriate to the function of those added packages. Anyone else experience this?

[dcd1182]

First, I'd like to express how impressed and pleased I've been with DCD's kitchen work. Our v3.0.1 phone was working great but I decided to update to v3.1.2 / radio v3.39 the other day just to stay up to date. Since we prefer MS Voice Command to the Cyberon stuff, I decided to bake VC into the ROM as an OEM rather than as a CAB (just to ensure a baseline voice dialing capability in the even of a hard reset). In doing so, I discovered an issue that prevents this from working correctly without a registry tweak after the fact.

Basically, in order for MSVC to work correctly with a Bluetooth headset, a couple of registry settings need to be in place. The key one is:

HKLM\Software\Microsoft\Bluetooth\AudioGateway
BTAGExtModule =vcbthag.dll

Another one that I have been applying (although I don't know if it's required any longer in v1.6) is

HKLM\Software\OEM\VoiceCommand
Path=\Windows\VoiceCMD.exe

These keys are actually set up correctly by the OEM installation folder for Voice Command. The problem with the kitchen, however, is that the .RGU file in the OEMDrivers folder in the kitchen's OEM folder seems to be applied *after* the .RGU file in the MSVC folder, causing them to be overwritten with default values that break the use of Bluetooth headsets with Voice Command.

I've edited the OEMDrivers .RGU file to fix this, but I imagine I'll have to do so with every kitchen release going forward. I'm wondering if it makes more sense to make sure that the .RGU files from any user-added OEMs are applied after OEMDrivers so that they can override the defaults with values appropriate to the function of those added packages. Anyone else experience this?

its because buildos is parsing your MSVC rgu before the OEMDrivers rgu (which then overwrites btagextmodule).
i fixed MSVC in the next release (it will be included) with a provxml.

[drgreenberg]

its because buildos is parsing your MSVC rgu before the OEMDrivers rgu (which then overwrites btagextmodule).
i fixed MSVC in the next release (it will be included) with a provxml.

I figured as much (after looking through all the RGU files to see which ones matched the condition the phone was coming up in). Thanks so much for responding to me and for actually fixing this in the next release.