USB VID/PID for open source projects

[Xiaofan Chen]

For libusb-win32 project, we have a few issues and some of them
have been sorted out, for example, the kernel driver signing issue
which has been solved by the generous donations of the people
in the libusb/libusb-win32 mailing list. For the issues with
GPL being excluded license for WHQL we are also working
on it (to change the kernel driver license to BSD in the future).

There is one more issue for the test firmware which is a common
issue for small USB developers. Sometimes you can get a free
PID sub-licensed from the vendors like FTDI, TI/Luminary and
Microchip. And we indeed get one for our Microchip based
test firmware (thanks a lot again, Microchip!). But they all have
strings attached -- to be used with vendors' USB parts only.

Now we intend to have more broader test firmware available,
for example, for Cypress EZ-USB FX2/FX2LP (high speed
USB) and Atmel AVR (and probably AVR32 with high speed)
and ARM MCUs. Then we can not use the Microchip VID/PID.

What are the potential solution here? I think it is too expensive
to get a USB VID for small projects like libusb/libusb-win32.

And I do not really like to use random USB VID/PID like
what we do right now -- that is the motivation to get a
valid PID in the first place.

--
Xiaofan

------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Greg KH-2]

On Thu, Mar 24, 2011 at 10:34:39AM +0800, Xiaofan Chen wrote:

> For libusb-win32 project, we have a few issues and some of them
> have been sorted out, for example, the kernel driver signing issue
> which has been solved by the generous donations of the people
> in the libusb/libusb-win32 mailing list. For the issues with
> GPL being excluded license for WHQL we are also working
> on it (to change the kernel driver license to BSD in the future).
>
> There is one more issue for the test firmware which is a common
> issue for small USB developers. Sometimes you can get a free
> PID sub-licensed from the vendors like FTDI, TI/Luminary and
> Microchip. And we indeed get one for our Microchip based
> test firmware (thanks a lot again, Microchip!). But they all have
> strings attached -- to be used with vendors' USB parts only.
>
> Now we intend to have more broader test firmware available,
> for example, for Cypress EZ-USB FX2/FX2LP (high speed
> USB) and Atmel AVR (and probably AVR32 with high speed)
> and ARM MCUs. Then we can not use the Microchip VID/PID.
>
> What are the potential solution here? I think it is too expensive
> to get a USB VID for small projects like libusb/libusb-win32.
>
> And I do not really like to use random USB VID/PID like
> what we do right now -- that is the motivation to get a
> valid PID in the first place.

For Linux-based projects, I can assign valid product id numbers from the
Linux Foundation's vendor id.  Just email me and let me know what you
want/need and I will reserve it.

For non-Linux-based projects, sorry, I don't know what to suggest.

thanks,

greg k-h

------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Xiaofan Chen]

On Thu, Mar 24, 2011 at 10:45 AM, Greg KH <[hidden email]> wrote:
> For Linux-based projects, I can assign valid product id numbers from the
> Linux Foundation's vendor id.  Just email me and let me know what you
> want/need and I will reserve it.

Thanks. Right now the test firmware is based on USB PICs and the next
one will be based on Atmel AVR (from Pete Batard). And the next one
will probably be based on Cypress EZ-USB FX2/FX2LP. Right now no
Linux based test firmware are planned yet. In the future I would certainly
look into a Linux based test firmware (USB gadget).

> For non-Linux-based projects, sorry, I don't know what to suggest.

I understand that.

--
Xiaofan

------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Tim Roberts]

Xiaofan Chen wrote:

> There is one more issue for the test firmware which is a common
> issue for small USB developers. Sometimes you can get a free
> PID sub-licensed from the vendors like FTDI, TI/Luminary and
> Microchip. And we indeed get one for our Microchip based
> test firmware (thanks a lot again, Microchip!). But they all have
> strings attached -- to be used with vendors' USB parts only.
>
> Now we intend to have more broader test firmware available,
> for example, for Cypress EZ-USB FX2/FX2LP (high speed
> USB) and Atmel AVR (and probably AVR32 with high speed)
> and ARM MCUs. Then we can not use the Microchip VID/PID.

Well, you can't use the SAME firmware for an FX2 solution and an AVR
solution.  Maybe you can politely ask for a test PID from each manufacturer.

> What are the potential solution here? I think it is too expensive
> to get a USB VID for small projects like libusb/libusb-win32.

$2,000 a year does seem a little steep.

> And I do not really like to use random USB VID/PID like
> what we do right now -- that is the motivation to get a
> valid PID in the first place.

I don't see any good alternative.  One advantage of using an obviously
bogus VID/PID (like DEAD/BEEF) is that it will (hopefully) make it
obvious to people that they have to provide their own.  Untold misery
ensued after some idiot company released a product using the FX2's
default VID/PID, then submitted their driver to WHQL and got it
installed in the Windows Driver Library.  After that, any time anyone
plugged in an unconfigured FX2, Windows helpfully installed the wrong
driver.

--
Tim Roberts, [hidden email]
Providenza & Boekelheide, Inc.


------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Tyler W. Wilson]

On 3/24/2011 12:44 PM, Tim Roberts wrote:
> Xiaofan Chen wrote:
>> There is one more issue for the test firmware which is a common
>> issue for small USB developers. Sometimes you can get a free
>> PID sub-licensed from the vendors like FTDI, TI/Luminary and
>> Microchip. And we indeed get one for our Microchip based
>> test firmware (thanks a lot again, Microchip!). But they all have
>> strings attached -- to be used with vendors' USB parts only.
SiLabs has the same option. We are using a C8051F320 and plan to go this
route too.

>> Now we intend to have more broader test firmware available,
>> for example, for Cypress EZ-USB FX2/FX2LP (high speed
>> USB) and Atmel AVR (and probably AVR32 with high speed)
>> and ARM MCUs. Then we can not use the Microchip VID/PID.
> Well, you can't use the SAME firmware for an FX2 solution and an AVR
> solution.  Maybe you can politely ask for a test PID from each manufacturer.
>
>> What are the potential solution here? I think it is too expensive
>> to get a USB VID for small projects like libusb/libusb-win32.
> $2,000 a year does seem a little steep.

Plus, if you want to WHQL it, so it is as seamless for the user as
possible, that is another bill.

>> And I do not really like to use random USB VID/PID like
>> what we do right now -- that is the motivation to get a
>> valid PID in the first place.
> I don't see any good alternative.  One advantage of using an obviously
> bogus VID/PID (like DEAD/BEEF) is that it will (hopefully) make it
> obvious to people that they have to provide their own.  Untold misery
> ensued after some idiot company released a product using the FX2's
> default VID/PID, then submitted their driver to WHQL and got it
> installed in the Windows Driver Library.  After that, any time anyone
> plugged in an unconfigured FX2, Windows helpfully installed the wrong
> driver.

We ran into the same thing with Pleo, which used an Atmel ARM7. There
was some GPS manufacturer which used the default Atmel VID/PID and got
their driver (usbser.sys based) approved via WHQL. Ugly.

------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[François Revol]

Le 24 mars 2011 à 17:50, Tyler W. Wilson a écrit :

>>> And I do not really like to use random USB VID/PID like
>>> what we do right now -- that is the motivation to get a
>>> valid PID in the first place.
>> I don't see any good alternative.  One advantage of using an obviously
>> bogus VID/PID (like DEAD/BEEF) is that it will (hopefully) make it
>> obvious to people that they have to provide their own.  Untold misery
>> ensued after some idiot company released a product using the FX2's
>> default VID/PID, then submitted their driver to WHQL and got it
>> installed in the Windows Driver Library.  After that, any time anyone
>> plugged in an unconfigured FX2, Windows helpfully installed the wrong
>> driver.
> We ran into the same thing with Pleo, which used an Atmel ARM7. There
> was some GPS manufacturer which used the default Atmel VID/PID and got
> their driver (usbser.sys based) approved via WHQL. Ugly.

This really looks like a flaw in WHQL itself then...
they shouldn't approve a driver from someone that is not the vendor of the advertised IDs unless they have an explicit authorization from the real manufacturer...
hmm this would prevent writing FLOSS driver though... (but then signed binaries can hardly be Free Software, at least not real one, and certainly not copyleft).

Well at the minimum they should check with the owner of the IDs.

François.
------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Greg KH-2]

On Thu, Mar 24, 2011 at 09:44:58AM -0700, Tim Roberts wrote:
> > And I do not really like to use random USB VID/PID like
> > what we do right now -- that is the motivation to get a
> > valid PID in the first place.
>
> I don't see any good alternative.  One advantage of using an obviously
> bogus VID/PID (like DEAD/BEEF) is that it will (hopefully) make it
> obvious to people that they have to provide their own.

This does not happen.  I've seen VID/PID values of 0x0000/0x0000 in
devices that ship and are very common.  So putting a real number in
there, even if it does spell something, will not cause people to realize
they need to change it :(

thanks,

greg k-h

------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Greg KH-2]

On Thu, Mar 24, 2011 at 06:03:44PM +0100, François Revol wrote:

>
> Le 24 mars 2011 à 17:50, Tyler W. Wilson a écrit :
>
> >>> And I do not really like to use random USB VID/PID like
> >>> what we do right now -- that is the motivation to get a
> >>> valid PID in the first place.
> >> I don't see any good alternative.  One advantage of using an obviously
> >> bogus VID/PID (like DEAD/BEEF) is that it will (hopefully) make it
> >> obvious to people that they have to provide their own.  Untold misery
> >> ensued after some idiot company released a product using the FX2's
> >> default VID/PID, then submitted their driver to WHQL and got it
> >> installed in the Windows Driver Library.  After that, any time anyone
> >> plugged in an unconfigured FX2, Windows helpfully installed the wrong
> >> driver.
> > We ran into the same thing with Pleo, which used an Atmel ARM7. There
> > was some GPS manufacturer which used the default Atmel VID/PID and got
> > their driver (usbser.sys based) approved via WHQL. Ugly.
>
> This really looks like a flaw in WHQL itself then...
> they shouldn't approve a driver from someone that is not the vendor of
> the advertised IDs unless they have an explicit authorization from the
> real manufacturer...  hmm this would prevent writing FLOSS driver
> though... (but then signed binaries can hardly be Free Software, at
> least not real one, and certainly not copyleft).

Microsoft already makes it very difficult to write opensource windows
drivers, as their DDK license prohibits it.

It is still possible, but I think the signing process is the least of
your worries :)

thanks,

greg k-h

------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Tim Roberts]

François Revol wrote:
> This really looks like a flaw in WHQL itself then...
> they shouldn't approve a driver from someone that is not the vendor of the advertised IDs unless they have an explicit authorization from the real manufacturer...

It's a tough call.  Is it really Microsoft's job to act as the USB
police or the PCI police?  Who would get to decide?  Would they be
opening themselves up to a lawsuit if they refused to bless a driver
because of this?

I appreciate the position they're in.  WHQL probably gets hundreds of
submissions per day, and only a very small percentage of them ever gets
touched by human hands.  They don't need yet another roadblock in the
process.

--
Tim Roberts, [hidden email]
Providenza & Boekelheide, Inc.


------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Тихомиров Валентин]

I feel it is a waste of of VIDs for the small companies, which is a majority, to order a 65535-device VID for their two devices. I wonder why nobody so far implemented my idea - purchasing a VID and selling the PIDs. It would be a good business, I'm sure. Additionally, Vid/Pid address space would be optimized and small developers satisfied.

> There is one more issue for the test firmware which is a common
 issue for small USB developers. Sometimes you can get a free
 PID sub-licensed from the vendors like FTDI, TI/Luminary and
 Microchip. And we indeed get one for our Microchip based
 test firmware (thanks a lot again, Microchip!). But they all have
 strings attached -- to be used with vendors' USB parts only.

Texas Instruments have rejected my request telling that their agreement does not let them to. I suppose they refer to the VID ownership right, obtained from USB-IF.

Valentin.


24.03.2011, 19:48, "Greg KH" <[hidden email]>:

> On Thu, Mar 24, 2011 at 10:34:39AM +0800, Xiaofan Chen wrote:
>
>>  For libusb-win32 project, we have a few issues and some of them
>>  have been sorted out, for example, the kernel driver signing issue
>>  which has been solved by the generous donations of the people
>>  in the libusb/libusb-win32 mailing list. For the issues with
>>  GPL being excluded license for WHQL we are also working
>>  on it (to change the kernel driver license to BSD in the future).
>>
>>  There is one more issue for the test firmware which is a common
>>  issue for small USB developers. Sometimes you can get a free
>>  PID sub-licensed from the vendors like FTDI, TI/Luminary and
>>  Microchip. And we indeed get one for our Microchip based
>>  test firmware (thanks a lot again, Microchip!). But they all have
>>  strings attached -- to be used with vendors' USB parts only.
>>
>>  Now we intend to have more broader test firmware available,
>>  for example, for Cypress EZ-USB FX2/FX2LP (high speed
>>  USB) and Atmel AVR (and probably AVR32 with high speed)
>>  and ARM MCUs. Then we can not use the Microchip VID/PID.
>>
>>  What are the potential solution here? I think it is too expensive
>>  to get a USB VID for small projects like libusb/libusb-win32.
>>
>>  And I do not really like to use random USB VID/PID like
>>  what we do right now -- that is the motivation to get a
>>  valid PID in the first place.
>
> For Linux-based projects, I can assign valid product id numbers from the
> Linux Foundation's vendor id.  Just email me and let me know what you
> want/need and I will reserve it.
>
> For non-Linux-based projects, sorry, I don't know what to suggest.
>
> thanks,
>
> greg k-h
>
> ------------------------------------------------------------------------------
> Enable your software for Intel(R) Active Management Technology to meet the
> growing manageability and security demands of your customers. Businesses
> are taking advantage of Intel(R) vPro (TM) technology - will your software
> be a part of the solution? Download the Intel(R) Manageability Checker
> today! http://p.sf.net/sfu/intel-dev2devmar
> _______________________________________________
> Libusb-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/libusb-devel

------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Segher Boessenkool]

> I feel it is a waste of of VIDs for the small companies, which is a
> majority, to order a 65535-device VID for their two devices. I wonder why
> nobody so far implemented my idea - purchasing a VID and selling the PIDs.
> It would be a good business, I'm sure.

The agreement for getting a VID from the USB-IF explicitly forbids
selling PIDs.


Segher


------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Тихомиров Валентин]

24.03.2011, 20:56, "Segher Boessenkool" <[hidden email]>:
>>  I feel it is a waste of of VIDs for the small companies, which is a
>>  majority, to order a 65535-device VID for their two devices. I wonder why
>>  nobody so far implemented my idea - purchasing a VID and selling the PIDs.
>>  It would be a good business, I'm sure.
>
> The agreement for getting a VID from the USB-IF explicitly forbids
> selling PIDs.

Owing to the fact that

"Sometimes you can get a free PID sub-licensed from the vendors like FTDI, TI/Luminary and Microchip. And we indeed get one for our Microchip based test firmware (thanks a lot again, Microchip!)."

that agreement can easily be worked around by handing out a piece of silicon in addition to the PID!

Valentine

>
> Segher

------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Peter Stuge]

Тихомиров Валентин wrote:
> I wonder why nobody so far implemented my idea - purchasing a VID
> and selling the PIDs.

Somebody has already done this, and have been stopped, because USB-IF
does not allow selling product ids.


> Texas Instruments have rejected my request telling that their
> agreement does not let them to. I suppose they refer to the VID
> ownership right, obtained from USB-IF.

TI is wrong, but I don't think you will succeed in making them change
their view. The USB-IF allows a VID holder to allocated PIDs to third
parties, but only free of charge.

The only solution is to get a VID ($2k one-time) for yourself, or to
have a group of people set up an organization solely for this purpose
and while that would not be a problem there will still always be some
strings attached. For the organization to get some traction there
will need to be an agreed-upon criteria for pid allocation. 64k is
many pids, but it's still a finite pool, and there are lots of
students who create a USB device as part of some course. The
organization also needs some kind of administration..


As for test devices I think it is very important to use different
vidpids for each actual different device. If it is not the same
design then it should not have the same vidpid IMO.


//Peter

------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Xiaofan Chen]

On Fri, Mar 25, 2011 at 1:14 AM, Greg KH <[hidden email]> wrote:
> Microsoft already makes it very difficult to write opensource windows
> drivers, as their DDK license prohibits it.

I do not think this is correct. Firstly Open Source does not
mean GPL and there are Open Source licenses which are not
"excluded license" like BSD/MIT/,,, license.

Secondly from what I read, only the "Distributable Code" is
subjected to the restriction.

++++++++++++++++++
>From WDK 7600.16385.1
• modify or distribute the source code of any Distributable
Code so that any part of it becomes subject to an Excluded License.
An Excluded License is one that requires, as a condition of use,
modification or distribution, that
• the code be disclosed or distributed in source code form; or
• others have the right to modify it.
+++++++++++++++++


> It is still possible, but I think the signing process is the least of
> your worries :)
>

WHQL has the similar "excluded license" clause regarding
the submitted driver package -- that was not the case last time
and companies got WHQL using libusb-win32 last time, but
new submissions will have issues.

--
Xiaofan

------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Xiaofan Chen]

On Fri, Mar 25, 2011 at 5:19 AM, Peter Stuge <[hidden email]> wrote:
> Тихомиров Валентин wrote:
>> I wonder why nobody so far implemented my idea - purchasing a VID
>> and selling the PIDs.
>
> Somebody has already done this, and have been stopped, because USB-IF
> does not allow selling product ids.

Wouter is one of them. He has stopped after getting letters from USB-IF.
http://www.voti.nl/shop/catalog.html?USB-PID-10
http://www.voti.nl/docs/usb-pid.html

This one has got its VID revoked even though they are still selling...
http://www.mcselec.com/index.php?page=shop.product_details&flypage=shop.flypage&product_id=92&option=com_phpshop&Itemid=1

>
> As for test devices I think it is very important to use different
> vidpids for each actual different device. If it is not the same
> design then it should not have the same vidpid IMO.

What do you mean by different design? I think as long as
the end function is the same, the VID/PID combination
can be the same even if different MCU/MPU is used.

For example, Linux based Gadget driver will have the
same VID/PID with given functions even though the
MPU used can be different.



--
Xiaofan

------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Peter Stuge]

Xiaofan Chen wrote:
> > As for test devices I think it is very important to use different
> > vidpids for each actual different device. If it is not the same
> > design then it should not have the same vidpid IMO.
>
> What do you mean by different design?

Good question.


> I think as long as the end function is the same, the VID/PID
> combination can be the same even if different MCU/MPU is used.
>
> For example, Linux based Gadget driver will have the
> same VID/PID with given functions even though the
> MPU used can be different.

At the very least I think vidpid should belong to one particular
device software only.

But I actually also think that different hardware running the same
software should have separate vidpids.

The way I think about it is that even if the software is the same,
differences in the hardware can have significant impact on device
functionality, and thus it is important to identify also the
hardware.


//Peter

------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Xiaofan Chen]

On Fri, Mar 25, 2011 at 5:19 AM, Peter Stuge <[hidden email]> wrote:
> The only solution is to get a VID ($2k one-time) for yourself,

I've come to the same conclusion now...

> or to have a group of people set up an organization solely for this purpose
> and while that would not be a problem there will still always be some
> strings attached.

I think this organization idea has never happened...

> For the organization to get some traction there
> will need to be an agreed-upon criteria for pid allocation. 64k is
> many pids, but it's still a finite pool, and there are lots of
> students who create a USB device as part of some course. The
> organization also needs some kind of administration..

That is indeed the case. The company I work for does not
have many USB device out there but we do have a USB
PID allocation scheme within the company. And there are
many other unique ID assignment schemes within the
company, for example, the Ethernet Mac IDs, the
product IDs within various product families, unique
IDs across the CIP ( Common Industrial Protocol)
networks, etc. So it does incur cost in admin and
manufacturing.


--
Xiaofan

------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Graeme Gill]

Xiaofan Chen wrote:
> This one has got its VID revoked even though they are still selling...
> http://www.mcselec.com/index.php?page=shop.product_details&flypage=shop.flypage&product_id=92&option=com_phpshop&Itemid=1

And in practice exactly how do you "revoke" a VID once there is hardware in the field ?

[Do you track down the cards and destroy each and every one of them ? :-)]

> What do you mean by different design? I think as long as
> the end function is the same, the VID/PID combination
> can be the same even if different MCU/MPU is used.

As long as there is a fixed way for a given VID/PID to discover
the board sub type.

Graeme Gill.

------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Michael Plante]

Tim Roberts wrote:
>> I appreciate the position they're in.  WHQL probably gets hundreds of
>> submissions per day, and only a very small percentage of them ever gets
>> touched by human hands.  They don't need yet another roadblock in the
>> process.


Perhaps it shouldn't be on the (automated) critical path to approval.  But
then is it possible for Microsoft to come back and revoke WHQL, or, if not,
at least to quit providing that driver over Windows Update anymore?
(Following some sort of complaint, since they obviously can't review them
all, based on what you've said.)

Regards,
Michael


------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Tim Roberts]

Michael Plante wrote:
>
> Perhaps it shouldn't be on the (automated) critical path to approval.  But
> then is it possible for Microsoft to come back and revoke WHQL, or, if not,
> at least to quit providing that driver over Windows Update anymore?
> (Following some sort of complaint, since they obviously can't review them
> all, based on what you've said.)

Right -- they don't have to revoke the WHQL, they just have to remove it
from the Windows Driver Library that automatically gets searched when a
new device is entered.  And, in fact, they eventually did that, so the
problem did get solved.

--
Tim Roberts, [hidden email]
Providenza & Boekelheide, Inc.


------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel