"Generic USB Input Device Support" for keydisks?
Georges Berenger
generic support for USB mouse & keyboards. Is there a similar component
for USB keydisks?
So far, our image supports all the different keydisks we have tried
(maybe 10 or 15 brands/models?), but is there a better way to be sure?
thanks,
-georges
KM
"DiskOnKey USB personal storage device" under "Hardware : Devices :
Universal Serial Bus controllers" ?
--
KM,
BSquare Corporation
Slobodan Brcin (eMVP)
Component "USB Mass Storage Device"
Among other things it supports compatible ID:
USB\Class_08&SubClass_06&Prot_50
This should support all your devices if not modify this ID to match all your
devices.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/install/hh/
install/idstrings_4n6v.asp
Regards,
Slobodan
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Have an opinion on the effectiveness of Microsoft Embedded newsgroups? Tell
Microsoft!
https://www.windowsembeddedeval.com/community/newsgroups
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Georges Berenger" <dontSpam...@francenet.fr> wrote in message
news:e9HCDyuB...@TK2MSFTNGP11.phx.gbl...
KM
Driver" :-)
--
KM,
BSquare Corporation
Georges Berenger
> Georges,
>
> "DiskOnKey USB personal storage device" under "Hardware : Devices :
> Universal Serial Bus controllers" ?
>
> --
> KM,
> BSquare Corporation
I believe that DiskOnKey is a brand, so that's not really what I am
looking for here. I'd like to support all key disks (so far, we had no
failure).
I guess, Slobodan's answer is what I was looking for.
Thanks for the tips.
-georges
Georges Berenger
-georges
KM
"USB Mass Storage Device" would be better for your case.
--
KM
Slobodan Brcin (eMVP)
Regards,
Slobodan
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Have an opinion on the effectiveness of Microsoft Embedded newsgroups? Tell
Microsoft!
https://www.windowsembeddedeval.com/community/newsgroups
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"KM" <kons...@nospam.yahoo.com> wrote in message
news:OV$aIWvBE...@TK2MSFTNGP09.phx.gbl...
KM
It also has "USB Mass Storage Driver" service data resource. Don't know why
"DiskOnKey .." does not depend on the "USB Mass Storage Driver" component.
--
KM,
BSquare Corporation
Slobodan Brcin (eMVP)
Use filter option to filter out all components that contains usbstor.sys.
You will end up with more than 70 components that are made from same inf
file and use same driver. So all these components are the same. If you make
component similar to "USB Mass Storage Driver" you could replace all these
70 components with one component that would have exact functionality as if
you entered all these components in your image. And many more components
that are not even produced yet.
This is the only reason why I have stopped using TAP long time ago to detect
hardware in my target device.
With few generic components you can cover all types of hardware, and let FBA
PnP do the rest of installation.
Regards,
Slobodan
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Have an opinion on the effectiveness of Microsoft Embedded newsgroups? Tell
Microsoft!
https://www.windowsembeddedeval.com/community/newsgroups
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"KM" <kons...@nospam.yahoo.com> wrote in message
news:Of6#LnvBEH...@TK2MSFTNGP09.phx.gbl...
Slobodan Brcin (eMVP)
I forgot to mention to you.
Since you are not using USB disk as boot device. You don't need any
component that will modify registry. Only thing you need are two files that
any of these components will provide. During the FBA PnP phase or at any
time when you connect new USB disk device PnP will use info from inf file to
install device driver for any compatible model (all DOK models current and
future).
Regards,
Slobodan
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Have an opinion on the effectiveness of Microsoft Embedded newsgroups? Tell
Microsoft!
https://www.windowsembeddedeval.com/community/newsgroups
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Georges Berenger" <dontSpam...@francenet.fr> wrote in message
news:e7o#YbvBEH...@TK2MSFTNGP11.phx.gbl...
KM
I saw and keep seeing the same: a lot of different components coming from
one .inf file (Printers, Modems, Keyboards, etc.) that basically bring the
same files in to the image and then FBA PnP does the install job. Even
worse, there is a lot of hardware component with the same names. The
difference is only in PnP IDs (but file sections are the same so the same
inf(s) get copied to the image).
My guess is that currently most of the components in XPe database are
developed by importing XP inf files. There is not much componentization on
hardware side of the database. E.g., a "perfect" XPe DB would have only
instance of the "usbstor.sys". All other "relative" components should depend
on the component that brings "usbstor.sys".
However, more done on software side.
My two cents.
--
KM,
BSquare Corporation
Slobodan Brcin (eMVP)
Few days ago I have already opened discussion on this topic and gave some
suggestions to MS.
Today I was writing few possible approaches how they should solve this, I
need to revisit few details, and then I'll send them more feedback on this.
Your guess about importing inf files is correct.
How would you make drivers for let us say Intel chipset?
Import inf files and from each inf file you will have 5 or more similar
components.
For NVIDIA graphic cards even worse maybe 40,50 components.
And list goes on and on.
Since most drivers are not critical for first OS boot. We can use generic
drivers, and copy all inf, dll, sys files on their place in windows folders.
FBA PnP will detect all present hardware and use inf files to install
appropriate drivers.
So for 99% of scenarios there is no need for us to use componentized drivers
and make myriads of components.
Heck if you want to support 8 different graphic adapters from NVIDIA or ATI
normally you would be expected to import 8 components to your project.
(creepy)
And then you would have problem with which component to use for setting
default display resolution.
What do you think?
Regards,
Slobodan
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Have an opinion on the effectiveness of Microsoft Embedded newsgroups? Tell
Microsoft!
https://www.windowsembeddedeval.com/community/newsgroups
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"KM" <kons...@nospam.yahoo.com> wrote in message
news:#DtH7GwB...@TK2MSFTNGP11.phx.gbl...
KM
I see a few issues that MS may keep in mind solving the problem:
1. Although any approach you come up with will not probably require much to
do on the XPe Tools side, changing components in XPe database will require
tremendous QA efforts.
2. You mentioned that for 99% of scenarios there is no need for us to use
componentized drivers. I agree. I was not happy to see many unnecassary
components coming from INF imports of some drivers. The very common approach
on XP is to just copy all driver required files to appropriate directories
and then PnP will do the install. However, what's about the rest "1%"?
Perhaps, it is up to driver developer(s) (hardware manufacture) to decide
what components should be included. Until most manufactures really support
XPe (providing not INFs but SLDs), there is nothing MS can to do to separate
simple "99%" drivers from complex "1%".
One of the approaches I see to solve the problem with NEW drivers is to have
"simple" and "complex" INF imports. The simple import should just prepare a
component with all the files going to corresponding windows directories. FBA
PnP will do the rest. The complex import would be to wrap up all the
components from INF. The Component Designer does the complex import now.
In any case (simple/complex) integrating a driver in to an XPe image does
not promise (prove) the driver will work properly. XPe devs have to do the
runtime testing anyway. So, even having problems with "simply" imported
components a Dev can always switch to the complex imports.
Not thinking about issue #1 (QA efforts), on current XPe database it is
possible to write a set of automated CMI scripts to re-organize components
so that there will be only instance of the components that wrap a particular
driver. E.g., it is pretty easy to go through DB and find out all the
components with "usbstor.sys" in Files section. The final component is
likely the one that would be in result of "simple" import.
And again, this should touch only Hardware category.
These are just ideas, though.
KM
Slobodan Brcin (eMVP)
One extreme case: for instance importing display adapter drivers from NVIDIA
will create much more than 50 components with same purpose and
functionality. Only difference between them will be their names and Hardware
ID used to identify them. In case of display adapters more natural way would
be that for each driver (per inf file or even per manufacturer) we have the
tool that can create component with following characteristic.
One inf file imported will create one component that will contain hardware
IDs for all supported adapters. This option is to maintain compatibility
with TAP results that allow automatic selection and import of components.
Since this component is not critical for boot, presence of this component
should not write anything to the registry. All driver installations should
be left for FBA PnP.
In this driver type category fall devices like Network adapters, Display
Adapters, Chipsets etc.
The best way I see would be to somehow create one component based on
"Compatible Ids" instead of having many "Hardware Ids"
For instance PCI\VEN_10DE&CC_030000 would match all NVIDIA video adapters.
Second category would be components that contain critical drivers required
to boot device.
Similar thing with "Compatible Ids" could be applied especially to them with
only difference that this component must modify registry to mark that
compatible Id as critical device required for system boot.
To support all chipsets we use I'm using standard components beginning with
"PCI standard *" and few other components to mark critical boot chipset
devices.
And then I have few components that copy all required files mostly inf files
that are used during the PnP phase to install adequate drivers and names.
So these two categories should cover all drivers. Only problem is how tools
for creating these components should look like. Or both MS and we should
mannualy create components by analyzing each driver inf file and other
specifics.
Do you have any idea how tools for this should look like?
Regards,
Slobodan
"KM" <konstmor@nospam_yahoo.com> wrote in message
news:#Jg3VgxB...@TK2MSFTNGP10.phx.gbl...
KM
I see your point.
Basically, my idea was similar. By "simple import" I meant parsing INF so
that all required files would go to corresponding windows directories and
all required PnP IDs (your Hardware IDs) would go to the component
resources. This should be compatible to TAP results as it will search and
include components by PnP IDs of drivers anylized on target device.
You are right about the two categories. Critical drivers should also get
required registry data.
What if the tool you are talking about just has to parse an INF file,
setting Files section (all files in to corresponding directories) and adding
all possible PnP ID resources from the INF. FBA PnP will install drivers for
present hardware.
So, the difference between current MS INF parser and the tool you want
should be in merging all result components in the final SLD in to one
component with all PnP IDs in it. This approach seems to work fine when I
look at NVIDIA components (parsed INF).
However, one question is left - will TAP be still compatible with this? If
PMQ parser does nothing more than just searching in XPe database for
components (to make them as dependencies) which include PnP IDs mentioned in
the PMQ. Then the answer is yes.
That's probably too late now to get the whole picture. I'll think more on
the subject tomorrow.
Konstantin
Slobodan Brcin (eMVP)
> Basically, my idea was similar. By "simple import" I meant parsing INF so
> that all required files would go to corresponding windows directories and
> all required PnP IDs (your Hardware IDs) would go to the component
> resources. This should be compatible to TAP results as it will search and
> include components by PnP IDs of drivers anylized on target device.
This is the first part (but I would try to avoid having component resources
when ever possible). Or at least if we set that device is critical for boot
most of resources should not modify registry, only one resource that uses
Compatible Id should modify registry.
> You are right about the two categories. Critical drivers should also get
> required registry data.
>
> What if the tool you are talking about just has to parse an INF file,
> setting Files section (all files in to corresponding directories) and
adding
> all possible PnP ID resources from the INF. FBA PnP will install drivers
for
> present hardware.
> So, the difference between current MS INF parser and the tool you want
> should be in merging all result components in the final SLD in to one
> component with all PnP IDs in it. This approach seems to work fine when I
> look at NVIDIA components (parsed INF).
But PnP ID resource definition should be little modified so it should not
modify registry in any scenario. Or there could be new PnP2 ID type.
And old PnP ID resource should be used for making registry changes needed
for boot critical devices.
> However, one question is left - will TAP be still compatible with this? If
> PMQ parser does nothing more than just searching in XPe database for
> components (to make them as dependencies) which include PnP IDs mentioned
in
> the PMQ. Then the answer is yes.
I think that this is how current implementation of PMQ import works. Nothing
more than search for best match component and add it to list.
KM
I don't see problems having Compatible Ids in the component resources (one
Compatible Id per set of the components from one INF file, say). However,
not changing TAP code much we will have to have PnP resources that match TAP
input with the XPe database components.
That is how I vision the tool from the discussion: import an INF file
creating only one component with all the PnP IDs from the INF file. This
will maintain compability with TAP. Files and Registry data sections should
have links to all the resources parsed from the INF files so that all fiiles
go to corresponding windows directories and if necessary some registry are
included (e.g. Nvidia requires a helper service data). As you will have only
one component to add to your configuration it will save you from having
multiply components' settings (e.g. only display driver settings in TD).
I don't see, however, where you apply Compatible IDs here? Sorry, I am
missing a piece here.
Also, how having all PnP Ids in registry may confuse FBA PnP? Why are you
trying to avoid it? If I understand this, I will understand your idea.
There should not be a problem of separating critical boot drivers from
non-critical's (hardware category).
Also, adding Compatible Ids concept do you want to change existing XPe
database components? Or you just want to apply this change to new components
that we all create?
--
KM,
BSquare Corporation
Slobodan Brcin (eMVP)
> I don't see problems having Compatible Ids in the component resources (one
> Compatible Id per set of the components from one INF file, say). However,
> not changing TAP code much we will have to have PnP resources that match
TAP
> input with the XPe database components.
TAP code should not be changed at all. Analyze PMQ file more closely and you
will see that TAP will provide you with both information's HARDWAREIDS and
COMPATIBLEIDS:
CD and TD should be slightly modified to support this. And also there is a
problem with importing inf files since I have not seen compatible IDs in inf
files so we probably must provide that info manually.
<DEVICE ConfigFlags="0">
<DEVICEDESC>Intel(R) 82845G/GL/GE/PE/GV Processor to I/O Controller -
2560 </DEVICEDESC>
<HARDWAREIDS>
<DEVICEID
Order="1">PCI\VEN_8086&DEV_2560&SUBSYS_00000000&REV_02</DEVICEID
>
<DEVICEID
Order="2">PCI\VEN_8086&DEV_2560&SUBSYS_00000000</DEVICEID>
<DEVICEID Order="3">PCI\VEN_8086&DEV_2560&REV_02</DEVICEID>
<DEVICEID Order="4">PCI\VEN_8086&DEV_2560</DEVICEID>
<DEVICEID Order="5">PCI\VEN_8086&DEV_2560&CC_060000</DEVICEID>
<DEVICEID Order="6">PCI\VEN_8086&DEV_2560&CC_0600</DEVICEID>
</HARDWAREIDS>
<COMPATIBLEIDS>
<DEVICEID Order="1">PCI\VEN_8086&CC_060000</DEVICEID>
<DEVICEID Order="2">PCI\VEN_8086&CC_0600</DEVICEID>
<DEVICEID Order="3">PCI\VEN_8086</DEVICEID>
<DEVICEID Order="4">PCI\CC_060000</DEVICEID>
<DEVICEID Order="5">PCI\CC_0600</DEVICEID>
</COMPATIBLEIDS>
</DEVICE>
> That is how I vision the tool from the discussion: import an INF file
> creating only one component with all the PnP IDs from the INF file. This
> will maintain compability with TAP. Files and Registry data sections
should
> have links to all the resources parsed from the INF files so that all
fiiles
> go to corresponding windows directories and if necessary some registry are
> included (e.g. Nvidia requires a helper service data). As you will have
only
> one component to add to your configuration it will save you from having
> multiply components' settings (e.g. only display driver settings in TD).
> I don't see, however, where you apply Compatible IDs here? Sorry, I am
> missing a piece here.
Fortunately compatible ids are not required for hardware display driver and
network category. This category does not require us to provide any resources
like service initialization or some registry entries.
Since during installation PnP will use all required info from inf file
itself.
Merging of all sections from inf file could be even dangerous, since there
is possibility that some hardware require some specific service installed
while some other does not require it.
So for this type of drivers only file copy should be enough and auto
detection from PMQ file would be nice.
Also if you use different manufacturers in same image like ATI and NVIDIA.
It is not good to set resolution from driver components.
In my image I'm using directly prototype component "Device: Display" it
allows me to set resolution independently of drivers I choose to put in my
image. Also this component should support settings for more that one
monitor.
> Also, how having all PnP Ids in registry may confuse FBA PnP? Why are you
> trying to avoid it? If I understand this, I will understand your idea.
I'm following the logic "The less things you have in registry the less
things can go wrong". And who knows it might speed boot process for few mil.
sec :D
>
> There should not be a problem of separating critical boot drivers from
> non-critical's (hardware category).
>
> Also, adding Compatible Ids concept do you want to change existing XPe
> database components? Or you just want to apply this change to new
components
> that we all create?
Let me think.
1. It would be nice to have native mechanism to create components like this
for our purposes, right?
2. MS could make few new components if they have time to spare. (keeping old
for compatibility)
3. Big picture. In few years we will have LHe. Do you think that they should
keep compatibility with XPe components and way to componentized drivers?
KM
> > .... > >
> TAP code should not be changed at all. Analyze PMQ file more closely and
you
> will see that TAP will provide you with both information's HARDWAREIDS and
> COMPATIBLEIDS:
I hadn't noticed the Compatible/Hardware IDs in PMQ results. Now I see. I
was mostly tending to see INF parser results and there are no Compatible IDs
currently :-(.
The Hardware IDs and Compatible IDs come from PnP enum subkeys of
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum] (REG_MULTI_SZ values).
Please correct if I am wrong.
> CD and TD should be slightly modified to support this. And also there is a
> problem with importing inf files since I have not seen compatible IDs in
inf
> files so we probably must provide that info manually.
Do you know how Compatible IDs get in to the registry? I don't think that XP
PnP sets this info. I think Compatible ID info are in INF files (maybe, not
always) but INF importer just does not parse it and sets all the PnP ID
resources to have IsCompatibleID flag set to FALSE.
However, if for example, you take a look into the MS default monitor
driver's INF you will see that its Compatible IDs is there (*PNP09FF).
I am not an expert in INF format so I may be wrong here.
>...>
>
> > ... > >
>
> Fortunately compatible ids are not required for hardware display driver
and
> network category. This category does not require us to provide any
resources
> like service initialization or some registry entries.
> Since during installation PnP will use all required info from inf file
itself.
I see.
> Merging of all sections from inf file could be even dangerous, since there
> is possibility that some hardware require some specific service installed
> while some other does not require it.
That is why I was referring to having "simple" and "complex" INF import
processes. This may always be up to dev (XPe, manufacturer) to decide
whether it is dangerous to merge the components. We have to test images
anyway.
> So for this type of drivers only file copy should be enough and auto
> detection from PMQ file would be nice.
>
> Also if you use different manufacturers in same image like ATI and NVIDIA.
> It is not good to set resolution from driver components.
> In my image I'm using directly prototype component "Device: Display" it
> allows me to set resolution independently of drivers I choose to put in my
> image. Also this component should support settings for more that one
monitor.
Yup, if you support more than one platform - prototype "Device: Display" is
a good choice.
However, how do you want to tell TAP to choose the "Device: Display"
automatically and not to match the real display driver PnP with an XPe
database component?
> > ... > > trying to avoid it? If I understand this, I will understand your
idea.
> I'm following the logic "The less things you have in registry the less
> things can go wrong". And who knows it might speed boot process for few
mil. sec :D
Agree. It also simplifies the image build process.
> > ... > >
> Let me think.
> 1. It would be nice to have native mechanism to create components like
this for our purposes, right?
Sure. A custom INF parser should do the trick if we come to agreement on the
Compatible IDs.
> 2. MS could make few new components if they have time to spare. (keeping
old for compatibility)
So, you don't change existing XPe database. Then a few multiply TAP results
used in one confuguration may not work properly with your concept.
> 3. Big picture. In few years we will have LHe. Do you think that they
should keep compatibility with XPe components and way to componentized
drivers?
As I heard LH (not embedded) is going to be much more componentized in first
place than, say, XP Pro.
Basically, there may be LHe only and LH will be built as one of the possible
configurations (the biggest one!).
However, these rumors seem mostly apply to the software stack. I don't know
MS plans for the hardware stack in XPe, though. I don't think it is possible
to change the hardware support dramatically maintaining compability to all
the hardware supoprted by XP Pro now.
My personal vote would be to re-design current XPe database (not only around
the hardware categories, btw).
Regards,
Konstantin
Slobodan Brcin (eMVP)
> The Hardware IDs and Compatible IDs come from PnP enum subkeys of
> [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum] (REG_MULTI_SZ values).
> Please correct if I am wrong.
> Do you know how Compatible IDs get in to the registry? I don't think that
XP
> PnP sets this info. I think Compatible ID info are in INF files (maybe,
not
> always) but INF importer just does not parse it and sets all the PnP ID
> resources to have IsCompatibleID flag set to FALSE.
This registry entries are virtual anyway. Those values are provided during
hardware enumeration by bus driver. Response on IRP_MN_QUERY_ID with
parameter BusQueryComptibleIDs.
In most cases value is read directly from hardware. But there are two
reasons why inf files usually do not contain this values.
Yes they are read from hardware like any Hardware Ids.
Only difference is when PnP tries to match driver to install them from inf
files.
Priority always goes to best match. There are criterions how best match is
determined, but it is sufficient so say that all Hardware Id matches come
first before Compatible Ids.
Supporting short Compatible Ids would require from driver manufacturer to
make driver that will support forward compatibility with all new hardware
for many years in future.
Also providing descriptive Hardware Ids enable driver manufacturers to
describe each adapter with special text and to populate registry with some
special hardware requirements.
> However, if for example, you take a look into the MS default monitor
> driver's INF you will see that its Compatible IDs is there (*PNP09FF).
>
> I am not an expert in INF format so I may be wrong here.
You can use compatible ids for dummy drivers or for generic drivers that
will support all hardware in given class (with at least satisfactory
support).
If inf file with Hardware Id is found it will be always used instead of inf
file and driver with compatible id.
There is description in DDK how this works. (But we have no issues with this
since we don't want to force hardware manufacturers to change their inf
files, and that would be bad solution anyway).
What I want is to define some standard for us developers and possibly MS how
to detect drivers that can be configured trough one component and to create
one component to cover wide range of devices.
Maybe example of what I'm currently using will help you to understand what I
want.
Look at components beginning with "PCI standard *" or "Standard *" you will
notice that they all use compatible IDs and that some of them have critical
device set to TRUE.
Having components like these your image will allow you to generically
support all hardware types. Some of these components are just placeholders
to set some info in critical database and some offer driver functionality
trough files like pci.sys pciide.sys, atapi.sys, etc.
This will allow us to reach FBA PnP phase and as you have noticed if we just
copy new drivers and inf files they will override generic drivers (which btw
are used by Intel etc with only name modification from inf file same MS
binaries are used) that override some of this functionality.
Check component: PCI standard RAM Controller. This hardware resource does
not use any driver it just exist as hardware resource access point. Other
manufacturers just change name of this node trough inf file. They do this by
providing hardware Id that always have better match than compatible Id
provided by MS.
Bottom line is if we use few MS components to make system boot, everything
else will be handled by PnP.
So we need a way to create component from let us say Intel 845.inf, 865.inf
and 852.inf files.
Ok we can have 6-7 components but not 15-20 components. Also all that
components should know that they are using functionality (generic drivers
provided by MS and not third party)
and according to these knowledge CD could create component that will use
compatible ID that we see in component "PCI standard RAM Controller".
If we had these options then it could be possible for MS to improve TD so we
could sort components in central panel trough their meaning chipset drivers
of some type, or drivers generally, etc... (topic for another discussion)
Uhhh.... I hope that I explained more successfully what I want.
Regards,
Slobodan
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Have an opinion on the effectiveness of Microsoft Embedded newsgroups? Tell
Microsoft!
https://www.windowsembeddedeval.com/community/newsgroups
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
KM
I did not know so much details about the device IDs before this thread (only
excuse - I am an app guy, not a platform dev :-) ).
Sorry for wasting your time.. Only plus - you seem to close to formulate
your idea as a suggestion to MS.
A couple of quick questions inline...
> This registry entries are virtual anyway. Those values are provided during
> hardware enumeration by bus driver. Response on IRP_MN_QUERY_ID with
> parameter BusQueryComptibleIDs.
You are probably talking about how the PnP manager works.
What I meant is that TAP seems to do just the registry enumeration to fill
up an xml template (pmq result).
> In most cases value is read directly from hardware. But there are two
> reasons why inf files usually do not contain this values.
> Yes they are read from hardware like any Hardware Ids.
> Only difference is when PnP tries to match driver to install them from inf
files.
> Priority always goes to best match. There are criterions how best match is
> determined, but it is sufficient so say that all Hardware Id matches come
first before Compatible Ids.
Yes, that is what it says in DDK docs.
Because a compatible-ID match is not as strong as a hardware-ID match, the
PnP Manager may prompt for confirmation from the user before processing the
INF file. Since you want just to have component(s) with compatible IDs only
(not hardware IDs) don't you afraid that FBA PnP may sometimes prompt for a
confirmation? It might not be the case at all if FBA PnP is a "silent"
version of the PnP Manager (I don't know the differences between FBA PnP and
regular XP PnP). Also, you have mentioned that most of "PCI standard *", for
example, components already have compatible IDs and FBA PnP proccess them
well.
Anyway, you seem to formuate the solution now: "we use few MS components to
make system boot, everything else will be handled by PnP."
Basically, new INF importer will have to analyze/match compatible IDs
instead of hardware IDs. It is possible to get hardware IDs from INF file
and then find all compatible IDs of XPe database components that hardware
IDs match hardware IDs from INF, isn't it?
But all this requires changing XPe Tools which only MS can do. Now I see
only manual creating components.
Regards,
Konstantin
Slobodan Brcin (eMVP)
> I did not know so much details about the device IDs before this thread
(only
> excuse - I am an app guy, not a platform dev :-) ).
> Sorry for wasting your time..
No trouble at all, I love some after midnight tech discussions they wake me
up :D
Only plus - you seem to close to formulate
> your idea as a suggestion to MS.
> A couple of quick questions inline...
>
> > This registry entries are virtual anyway. Those values are provided
during
> > hardware enumeration by bus driver. Response on IRP_MN_QUERY_ID with
> > parameter BusQueryComptibleIDs.
>
> You are probably talking about how the PnP manager works.
> What I meant is that TAP seems to do just the registry enumeration to fill
> up an xml template (pmq result).
Sorry yes I was talking about who generated them.
Use devcon hwids * and it will list all devices with all hardware and
compatible ids found. I think that is uses some of CM_xxx API functions for
the job. But it is irrelevant since they will probably read from registry.
Well I have never seen FBA PnP to ask me anything ever (it swallows
signed/unsigned drivers etc).
Also I'm not suggesting that we or MS change inf files. They should remain
as they are today. So PnP will never see any difference.
But we are getting to what I want. TD and CD should work with one component
per whole compatible hardware group. And at the same time they should try to
minimize writing any info to registry, or in case of very few boot critical
devices they should mark them by using compatible id.
When XPe load reaches point of FBA PnP, PnP will handle all detection and
appropriate installations (this is the time when drivers/services are
installed and registry is truly modified with info contained in inf file for
specific hardware detected by PnP and not by TAP, or TD)
> Anyway, you seem to formuate the solution now: "we use few MS components
to
> make system boot, everything else will be handled by PnP."
I'm using this solution for very long time. But currently it is undocumented
manual work that is based on my knowledge how things work. This is a luxury
that many people here do not have. Time or knowledge so this is why I would
like to see some tools that address these issues. I have solved my problems
but people are just afraid to experiment with componentization.
> Basically, new INF importer will have to analyze/match compatible IDs
> instead of hardware IDs. It is possible to get hardware IDs from INF file
> and then find all compatible IDs of XPe database components that hardware
> IDs match hardware IDs from INF, isn't it?
:)
This part it tricky since currently there is no way to associate hardware
IDs with compatible ID. (manually it is only way).
PMQ file contains info about hardware that you posses, but this is not
enough for componentizing whole sections of inf files.
MS could make database about relation between known manufacturers hardware
IDs and compatible IDs manually.
They could periodically update this DB. Or they could give us a tool to
create our association between all Hardware IDs that we get from inf file
and some compatible Id we choose from PMQ file.
> But all this requires changing XPe Tools which only MS can do. Now I see
> only manual creating components.
Yep, I agree on that. Beside info I already sent I'm going to give them link
to this thread they might find a better way to do this.
KM
What I was thinking looking at your idea is that most of the Compatible Ids
and Hardware Ids info is in the XPe database. The only problem is that they
did not seem to mark IsCompatibleID flags there :-( Who knows maybe MS has
already got the right DB of Compatible Ids and Hardware Ids matched.
Regarding devcon. I was actually using DevMgr (the Details tab page for each
component) that shows Compatible Ids and Hardware Ids perfectly. It even
shows the Matching Device Ids as a separate item. Basically, devcon and
DevMgr are the same (the same functionality).
I am glad that we finished the thread. I'm going to be out the whole next
week and will unlikely be able to respond.
Thanks a lot for the discussion! It was very informative to me :-).
Regards,
Konstantin