Menu
▾
▴
libusb-devel
|
From: Segher B. <se...@ke...> - 2011-03-24 17:56:26
|
> 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 |
|
From: Тихомиров В. <int...@ya...> - 2011-03-24 19:29:10
|
24.03.2011, 20:56, "Segher Boessenkool" <se...@ke...>: >> 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 |
|
From: Xiaofan C. <xia...@gm...> - 2011-03-24 23:45:30
|
On Fri, Mar 25, 2011 at 5:19 AM, Peter Stuge <pe...@st...> 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 |
|
From: Peter S. <pe...@st...> - 2011-03-25 01:19:59
|
Xiaofan Chen wrote: > > set up an organization > > I think this organization idea has never happened... There's at least one example; Linux Foundation. Just that it has a somewhat narrow criteria for it's assignment. When discussing this idea with people, both GNU and the EFF have come up. There's also the Linux Fund whom I might have a chance to talk to during LinuxTag in Berlin, in May. From http://www.linuxfund.org: About Linux Fund Linux Fund is a community-neutral 501(c)(3) nonprofit organization that provides financial and administrative support to the open source community. We have given away over $750,000 to open source events and projects around the world since our founding in 1999 using funds raised through our line of credit cards and direct donations. > allocation scheme Yup. I think it could be done, but someone needs to do it. :) //Peter |
|
From: Graeme G. <gr...@ar...> - 2011-03-24 23:50:10
|
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. |
|
From: Peter S. <pe...@st...> - 2011-03-25 01:11:27
|
Graeme Gill wrote: > > VID revoked > > And in practice exactly how do you "revoke" a VID once there is > hardware in the field ? The right to use the vid is revoked. > [Do you track down the cards and destroy each and every one of them > ? :-)] No more than any other rogue device which "borrows" a vid will be tracked down and destroyed. > > 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. Yes different boards should be identifiable somehow, and I think vidpid has advantages over any other field, in or out of the device descriptor. vidpid is usually always visible for user in some way, while other fields may not be. //Peter |
|
From: François R. <re...@fr...> - 2011-03-25 08:54:57
|
Le 25 mars 2011 à 02:11, Peter Stuge a écrit : >>> 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. > > Yes different boards should be identifiable somehow, and I think > vidpid has advantages over any other field, in or out of the device > descriptor. vidpid is usually always visible for user in some way, > while other fields may not be. Device version field ? François. |
|
From: Xiaofan C. <xia...@gm...> - 2011-03-25 01:31:04
|
On Fri, Mar 25, 2011 at 9:11 AM, Peter Stuge <pe...@st...> wrote: >> > 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. > > Yes different boards should be identifiable somehow, and I think > vidpid has advantages over any other field, in or out of the device > descriptor. vidpid is usually always visible for user in some way, > while other fields may not be. It may well partly due to the difficulty to get a valid PID that companies are using the same PID for different product and then differentiate the product using strings in the descriptor or other methods. The other reason may be WHQL. One example is the Amontec Jtagkey. http://www.amontec.com/download/amontec-jtagkey-driver-d2xx-20091124.zip This driver works with all Amontec JTAGkey dongles (Amontec JTAGkey / JTAGkey Tiny / JTAGkey-2 / JTAGkey-2P / JTAGkey-2 Tiny, etc). This driver is signed and certified for Windows WHQL 32bits and 64bits. They use the same PID (sub-license from FTDI) for the different product. I think the main reason may well be WHQL -- they probably do not want to submit again. -- Xiaofan |
|
From: Segher B. <se...@ke...> - 2011-03-25 02:30:04
|
>> Yes different boards should be identifiable somehow, and I think >> vidpid has advantages over any other field, in or out of the device >> descriptor. vidpid is usually always visible for user in some way, >> while other fields may not be. > > It may well partly due to the difficulty to get a valid PID that companies > are using the same PID for different product and then differentiate > the product using strings in the descriptor or other methods. > > The other reason may be WHQL. One example is the Amontec Jtagkey. > http://www.amontec.com/download/amontec-jtagkey-driver-d2xx-20091124.zip > This driver works with all Amontec JTAGkey dongles (Amontec JTAGkey / > JTAGkey Tiny / JTAGkey-2 / JTAGkey-2P / JTAGkey-2 Tiny, etc). There are also many clones of the jtagkey that use the same vid/pid. This device is also a good example of why it is *bad* to use the same vid/pid on multiple devices: all of them seem to be different in the sense of the TRST and SRST outputs (polarity, push/pull vs. open drain). This makes it impossible to use a jtagkey (clone; it might just be the clones that differ!) without looking at the device strings first, to properly identify the device. Segher |
|
From: Xiaofan C. <xia...@gm...> - 2011-03-25 03:05:09
|
On Fri, Mar 25, 2011 at 10:29 AM, Segher Boessenkool <se...@ke...> wrote: >>> Yes different boards should be identifiable somehow, and I think >>> vidpid has advantages over any other field, in or out of the device >>> descriptor. vidpid is usually always visible for user in some way, >>> while other fields may not be. >> >> It may well partly due to the difficulty to get a valid PID that companies >> are using the same PID for different product and then differentiate >> the product using strings in the descriptor or other methods. >> >> The other reason may be WHQL. One example is the Amontec Jtagkey. >> http://www.amontec.com/download/amontec-jtagkey-driver-d2xx-20091124.zip >> This driver works with all Amontec JTAGkey dongles (Amontec JTAGkey / >> JTAGkey Tiny / JTAGkey-2 / JTAGkey-2P / JTAGkey-2 Tiny, etc). > > There are also many clones of the jtagkey that use the same vid/pid. > > This device is also a good example of why it is *bad* to use the same > vid/pid on multiple devices: all of them seem to be different in the > sense of the TRST and SRST outputs (polarity, push/pull vs. open drain). > This makes it impossible to use a jtagkey (clone; it might just be the > clones that differ!) without looking at the device strings first, to > properly identify the device. If you add clones to the picture, then I do not think there is a solution. Whatever you do properly in the original design, the cheaper clones can always "un-designed" it. :-( They can just keep the device strings in the clones... -- Xiaofan |
|
From: Тихомиров В. <int...@ya...> - 2011-03-25 10:34:00
|
> 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.. The free of charge distribution is not possible. The VID owners always depend on PID users. There is always a stream of PIDs from USB-IF, through developer companies, the VID holders, toward the end (VID/PID) devices users and reverse stream of money. In the case with Microchip and Free Foundation are just indirect schemes of selling PIDs. The single PID cost is included in every device. Therefore, I observe that it is permitted to sell PIDs if you add some piece of silicon with it. User is free to throw you piece of silicon away and use only PID for his purposes. So the silicon may stay purely virtual (or get a not working piece if you additionally pay for its transport). It is mere nonsense to say that if 100 people can pay 100 times less for simply saying that they are "one family" or "one company". Why USB-IF demands the impossible nonsense? Why it invalidates most of the PIDs? Because this pushes every developer to buy a new VID from them! All businessmen to this, including "non-commertial" USB-IF. They sell the things but limit their use. It is contradictory: your things must be useful, but limited usability forces users to buy more. The capitalistic profit maximization makes the life on the Earth incredibly difficult, vainly wastes huge resources just for stimulating more sells and profit. That is all rationale. If VID holder satisfies too many users, that could be the clients of USB-IF, his activity becomes illegal. The profit-hungry standard owner even does not hesitate to revoke his signed agreements. That is why even Texas Instruments is scared. I wonder how Microchip and Free Foundation have the nerve to operate. The standard organizations must be truly non-commercial (do not depending on the amount of VIDs they sell). It could administrate PIDs as well. The only concern would be the PID depletion, which may happen due to very cheap IDs. But, coercing to buy more VIDs today, USB-IF drives the depletion (though it is smoothed by favouring the big corporations with their end products over small developers). In the ideal world, the students could do their projects without purchasing a new ID, as they do today. As long as their projects do not exit the lab, they can use any PID or one allocated by Federal Commission for shared use, like radio control frequenci es. >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 Many health to this company. USB-IF go f****! Bomb it, let Livia alone! Yet, they prefer Kaddafi because he limits their profits in Africa. Val 25.03.2011, 00:19, "Peter Stuge" <pe...@st...>: > Тихомиров Валентин 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. > > > 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 > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libusb-devel |
|
From: Тихомиров В. <int...@ya...> - 2011-03-25 12:29:28
|
Why not to let "MCS Electronics" to manage the VID it purchased? It does a good job. Do you mean that 10$ is too much per project? Why to take over company's ID space and introduce the chaos? 25.03.2011, 14:22, "Pete Batard" <pb...@gm...>: > As I've already mentioned privately to some people, an alternative would > be to just reuse one the of obsolete VIDs published by the USB-IF [1] > (where you see that the "MCS Electronics" PID reseller has indeed been > revoked). > > It is doubtful that the USB-IF will want to reassign these VIDs anytime > soon (in fact, that's what MCS Electronics are basing their business > on), so they can basically be seen as free for use. The only issue is > coordination between people "hijacking" these VIDs as well as > misrepresentation/misidentification of the vendor. However, with these > vendors being obsolete, if you're a well known open source organization, > something could probably be worked out with USB IDs list maintainers, > such as the Linux USB IDs [2]. > > Regards, > > /Pete > > [1] http://www.usb.org/developers/tools/obsoletevids011411.pdf > [2] http://www.linux-usb.org/usb.ids > > ------------------------------------------------------------------------------ > 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 > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libusb-devel |
|
From: Pete B. <pb...@gm...> - 2011-03-25 13:00:50
|
On 2011.03.25 12:29, Тихомиров Валентин wrote: > Why not to let "MCS Electronics" to manage the VID it purchased? It does a good job. Do you mean that 10$ is too much per project? Why to take over company's ID space and introduce the chaos? This is meant to be smart "hijacking", in that you don't hijack the VID from companies that are actually producing PIDs, but from the ones that don't. Somehow I have doubts that reusing the VID from Nebraska Furniture Mart would generate much of a conflict with regards to PIDs. Regards, /Pete |
|
From: Uwe B. <bo...@el...> - 2011-03-25 17:28:15
|
>>>>> "Segher" == Segher Boessenkool <se...@ke...> writes:
Segher> There are also many clones of the jtagkey that use the same
Segher> vid/pid.
Segher> This device is also a good example of why it is *bad* to use the
Segher> same vid/pid on multiple devices: all of them seem to be
Segher> different in the sense of the TRST and SRST outputs (polarity,
Segher> push/pull vs. open drain). This makes it impossible to use a
Segher> jtagkey (clone; it might just be the clones that differ!)
Segher> without looking at the device strings first, to properly
Segher> identify the device.
What is bad to require to read the device string?
--
Uwe Bonnes bo...@el...
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
|
|
From: Segher B. <se...@ke...> - 2011-03-25 23:09:50
|
> Segher> There are also many clones of the jtagkey that use the same > Segher> vid/pid. > > Segher> This device is also a good example of why it is *bad* to use > the > Segher> same vid/pid on multiple devices: all of them seem to be > Segher> different in the sense of the TRST and SRST outputs (polarity, > Segher> push/pull vs. open drain). This makes it impossible to use a > Segher> jtagkey (clone; it might just be the clones that differ!) > Segher> without looking at the device strings first, to properly > Segher> identify the device. > > What is bad to require to read the device string? Then vid/pid alone isn't enough to identify the device; which is the purpose of vid/pid. The purpose of the device string is not to identify a device for programmatic purposes (instead, it is for human consumption only); using a single datum for two conflicting purposes is not a good thing. There is no mechanism in place to prevent allocating the same device string to two different devices, not even when those devices share the same vid/pid. In practice, using the device string to distinguish between _a few_ devices that share a vid/pid usually works fine of course. Segher |
|
From: Xiaofan C. <xia...@gm...> - 2011-03-26 03:22:17
|
On Sat, Mar 26, 2011 at 7:09 AM, Segher Boessenkool <se...@ke...> wrote: >> What is bad to require to read the device string? > > Then vid/pid alone isn't enough to identify the device; which is the > purpose of vid/pid. A counter example will be the product revision, you will often come out a new product revision which has basically the same functionality as the old device while addressing problems like component obsolescence. You do not want to change the PID in the case if there are no form/fit/function change. You can use the version field for this. > The purpose of the device string is not to identify a device for > programmatic purposes (instead, it is for human consumption only); > using a single datum for two conflicting purposes is not a good thing. > > There is no mechanism in place to prevent allocating the same device > string to two different devices, not even when those devices share > the same vid/pid. When you decide to use the device strings, then you need to come out a scheme to make it unique. no different from other number allocation scheme. > In practice, using the device string to distinguish between _a few_ > devices that share a vid/pid usually works fine of course. > -- Xiaofan |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X