Menu
▾
▴
libusb-devel
|
From: Xiaofan C. <xia...@gm...> - 2011-03-24 02:34:46
|
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 |
|
From: Greg KH <gr...@kr...> - 2011-03-24 02:44:42
|
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 |
|
From: Xiaofan C. <xia...@gm...> - 2011-03-24 05:06:28
|
On Thu, Mar 24, 2011 at 10:45 AM, Greg KH <gr...@kr...> 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 |
|
From: Тихомиров В. <int...@ya...> - 2011-03-24 17:35:45
|
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" <gr...@kr...>: > 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 > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libusb-devel |
|
From: Peter S. <pe...@st...> - 2011-03-24 21:20:01
|
Тихомиров Валентин 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 |
|
From: Xiaofan C. <xia...@gm...> - 2011-03-24 22:50:29
|
On Fri, Mar 25, 2011 at 5:19 AM, Peter Stuge <pe...@st...> 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 |
|
From: Peter S. <pe...@st...> - 2011-03-24 23:06:13
|
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 |
|
From: Pete B. <pb...@gm...> - 2011-03-25 11:22:20
|
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 |
|
From: Peter S. <pe...@st...> - 2011-03-25 13:40:46
|
Тихомиров Валентин wrote: > The capitalistic profit maximization makes the life on the Earth > incredibly difficult, This is of course another discussion completely. Not what we are talking about. > If VID holder satisfies too many users, that could be the clients > of USB-IF, his activity becomes illegal. That's not how it works. Please stop ranting and do more thorough research. > The profit-hungry standard owner even does not hesitate to revoke > his signed agreements. Have you actually read the agreements? They cover revocation as well. > I wonder how Microchip and Free Foundation have the nerve to > operate. I believe that intent is the key. The particular intent to sell PIDs is disallowed, because it would create a messy gray market. But if the intent is to sell chips then assigning PIDs is fine, as long as all parties are aware that the VID still is directly connected to the VID assignee. In my communication with USB-IF it has been confirmed that it's perfectly fine to assign PIDs to a third party. > > 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. I disagree. I don't think the company is really doing anything good. > USB-IF go f****! You may want to consider that were it not for the USB-IF there would be no USB as we know it at all. //Peter |
|
From: Тихомиров В. <int...@ya...> - 2011-03-25 14:21:53
|
> I believe that intent is the key. The particular intent to sell PIDs > is disallowed, because it would create a messy gray market. But if > the intent is to sell chips then assigning PIDs is fine, as long as > all parties are aware that the VID still is directly connected to the > VID assignee. Any market is "messy", you know. Being unpredictable is its main feature. This is opposite to "planned economy". The planned economy will always have the gray market, the symptom of its inefficiency, as the dominating market ideology teaches us. Single authority cannot efficiently distribute the goods. You must liberate the economy, permit illegal operations, to make it "not gray". Permitting the "free of charge" distribution does not improve the control over the distributions. > In my communication with USB-IF it has been confirmed that it's > perfectly fine to assign PIDs to a third party. For this reason they deny selling PIDs to third parties. > Have you actually read the agreements? They cover revocation as well. >> If VID holder satisfies too many users, that could be the clients >> of USB-IF, his activity becomes illegal. > That's not how it works. Please stop ranting and do more thorough > research. Even those who sign them, Texas Instruments, do not read. I see that USB-IF forces us to purchase unnecessarily large address spaces. What should I learn to think otherwise? Val 25.03.2011, 16:40, "Peter Stuge" <pe...@st...>;: > Тихомиров Валентин wrote: >> The capitalistic profit maximization makes the life on the Earth >> incredibly difficult, > This is of course another discussion completely. Not what we are > talking about. >> The profit-hungry standard owner even does not hesitate to revoke >> his signed agreements. > Have you actually read the agreements? They cover revocation as well. >> I wonder how Microchip and Free Foundation have the nerve to >> operate. > I believe that intent is the key. The particular intent to sell PIDs > is disallowed, because it would create a messy gray market. But if > the intent is to sell chips then assigning PIDs is fine, as long as > all parties are aware that the VID still is directly connected to the > VID assignee. > > In my communication with USB-IF it has been confirmed that it's > perfectly fine to assign PIDs to a third party. >>> 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. > I disagree. I don't think the company is really doing anything good. >> USB-IF go f****! > You may want to consider that were it not for the USB-IF there would > be no USB as we know it at all. > > //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 17:04:28
|
25.03.2011, 18:45, Phi...@mi...: > Thank you Peter for trying to bring some order back into this > thread. Let's not turn this into a political/economic discussion. > > Once a company or organization purchases a VID, they then "own" their PIDs and, > short of selling them, can do what they will with them. Is this correct? How can you thank somebody for what he is saying and not hearing what he says, that doing what you want with you PIDs is disallowed? The free PID trading would create the "messy gray market". So, you can do anything with your intellectual property only when you do it free of charge :) Val |
|
From: Peter S. <pe...@st...> - 2011-03-25 19:20:51
|
Phi...@mi... wrote: > Once a company or organization purchases a VID, they then "own" > their PIDs and, short of selling them, can do what they will with > them. Is this correct? This matches my understanding following my communication with USB-IF. > Maybe we could have Xiaofan restate his original concern/problem > about obtaining VID/PIDs. There are a few concerns, which are all legitimate: 1. The $2000 threshold of an own VID is high for amateur device developers, and it also seems a little wasteful to allocate one VID for what may be a single project. 2. Many USB chip vendors are happy to help smaller customers with a PID allocation from the chip vendor's pool. But often chip vendors (quite understandably) then require that the VID and PID will only be used in projects using the vendor's chips. Тихомиров Валентин wrote: > The free PID trading would create the "messy gray market". So, you > can do anything with your intellectual property only when you do it > free of charge :) I wouldn't even call it intellectual property. It is a number assignment in a standardized context. My impression is very much that USB-IF would have no objections against an organization that manages PID assignments for projects which can not themselves climb the $2000 threshold, and raising that sum is not such a big deal if a bunch of people get together. But the devil is, as always, in the details; running the organization needs to be planned and criteria needs to be agreed upon, for it to be successful and worthwhile. I can completely understand that USB-IF do not want to *be* that organization. They have a different purpose. //Peter |
|
From: Xiaofan C. <xia...@gm...> - 2011-03-26 03:18:03
|
On Sat, Mar 26, 2011 at 3:20 AM, Peter Stuge <pe...@st...> wrote: > Phi...@mi... wrote: >> Once a company or organization purchases a VID, they then "own" >> their PIDs and, short of selling them, can do what they will with >> them. Is this correct? > > This matches my understanding following my communication with USB-IF. > >> Maybe we could have Xiaofan restate his original concern/problem >> about obtaining VID/PIDs. > > There are a few concerns, which are all legitimate: > > 1. The $2000 threshold of an own VID is high for amateur device > developers, and it also seems a little wasteful to allocate one VID > for what may be a single project. > > 2. Many USB chip vendors are happy to help smaller customers with a > PID allocation from the chip vendor's pool. But often chip vendors > (quite understandably) then require that the VID and PID will only be > used in projects using the vendor's chips. Very good summary. Indeed these are my main concerns. > I wouldn't even call it intellectual property. It is a number > assignment in a standardized context. > > My impression is very much that USB-IF would have no objections > against an organization that manages PID assignments for projects > which can not themselves climb the $2000 threshold, and raising that > sum is not such a big deal if a bunch of people get together. But the > devil is, as always, in the details; running the organization needs > to be planned and criteria needs to be agreed upon, for it to be > successful and worthwhile. I agree. > I can completely understand that USB-IF do not want to *be* that > organization. They have a different purpose. > I agree. -- Xiaofan |
|
From: Тихомиров В. <int...@ya...> - 2011-03-28 13:13:02
|
25.03.2011, 20:20, "Peter Stuge" <pe...@st...>: > Phi...@mi... wrote: > >> Once a company or organization purchases a VID, they then "own" >> their PIDs and, short of selling them, can do what they will with >> them. Is this correct? > > This matches my understanding following my communication with USB-IF. USB-IF agreement explicitly forbids selling of the PIDs your "own", that those who did that were deprived of their VIDs. Who told me that? >> Maybe we could have Xiaofan restate his original concern/problem >> about obtaining VID/PIDs. > > There are a few concerns, which are all legitimate: > > 1. The $2000 threshold of an own VID is high for amateur device > developers, and it also seems a little wasteful to allocate one VID > for what may be a single project. > > 2. Many USB chip vendors are happy to help smaller customers with a > PID allocation from the chip vendor's pool. But often chip vendors > (quite understandably) then require that the VID and PID will only be > used in projects using the vendor's chips. > > Тихомиров Валентин wrote: > >> The free PID trading would create the "messy gray market". So, you >> can do anything with your intellectual property only when you do it >> free of charge :) > > I wouldn't even call it intellectual property. It is a number > assignment in a standardized context. > > My impression is very much that USB-IF would have no objections > against an organization that manages PID assignments for projects > which can not themselves climb the $2000 threshold, and raising that > sum is not such a big deal if a bunch of people get together. But the > devil is, as always, in the details; running the organization needs > to be planned and criteria needs to be agreed upon, for it to be > successful and worthwhile. > > I can completely understand that USB-IF do not want to *be* that > organization. They have a different purpose. If they favored making identifiers more accessible, they would not punish reselling. Revoking just creates the jumble (remember somebody in this thread even proposes to "hijack" the revoked VIDs, whereas, I believe, MSC Electronics struggles for bookkeeping its PIDs in order). You asked me to stop ranting and do more thorough research. Your ranting about USB-IF opinions are interesting. But they are not consistent. They are as controversial, as USB-IF position is. Thus, I am right in my ranting. Valentin > //Peter |
|
From: <Phi...@mi...> - 2011-03-25 15:57:28
|
Thank you Peter for trying to bring some order back into this thread. Let's not turn this into a political/economic discussion. Once a company or organization purchases a VID, they then "own" their PIDs and, short of selling them, can do what they will with them. Is this correct? Maybe we could have Xiaofan restate his original concern/problem about obtaining VID/PIDs. -----Original Message----- From: Peter Stuge [mailto:pe...@st...] Sent: Friday, March 25, 2011 6:41 AM To: lib...@li... Subject: Re: [Libusb-devel] USB VID/PID for open source projects Тихомиров Валентин wrote: > The capitalistic profit maximization makes the life on the Earth > incredibly difficult, This is of course another discussion completely. Not what we are talking about. > If VID holder satisfies too many users, that could be the clients of > USB-IF, his activity becomes illegal. That's not how it works. Please stop ranting and do more thorough research. > The profit-hungry standard owner even does not hesitate to revoke his > signed agreements. Have you actually read the agreements? They cover revocation as well. > I wonder how Microchip and Free Foundation have the nerve to operate. I believe that intent is the key. The particular intent to sell PIDs is disallowed, because it would create a messy gray market. But if the intent is to sell chips then assigning PIDs is fine, as long as all parties are aware that the VID still is directly connected to the VID assignee. In my communication with USB-IF it has been confirmed that it's perfectly fine to assign PIDs to a third party. > > http://www.mcselec.com/index.php?page=shop.product_details&flypage=s > > hop.flypage&product_id=92&option=com_phpshop&Itemid=1 > > Many health to this company. I disagree. I don't think the company is really doing anything good. > USB-IF go f****! You may want to consider that were it not for the USB-IF there would be no USB as we know it at all. //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: Tim R. <ti...@pr...> - 2011-03-24 16:45:06
|
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, ti...@pr... Providenza & Boekelheide, Inc. |
|
From: François R. <re...@fr...> - 2011-03-24 17:03:57
|
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. |
|
From: Greg KH <gr...@kr...> - 2011-03-24 17:06:58
|
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 |
|
From: Tyler W. W. <ty...@ty...> - 2011-03-24 16:58:26
|
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. |
|
From: Greg KH <gr...@kr...> - 2011-03-24 17:14:59
|
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 |
|
From: Xiaofan C. <xia...@gm...> - 2011-03-24 22:43:40
|
On Fri, Mar 25, 2011 at 1:14 AM, Greg KH <gr...@kr...> 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 |
|
From: Tim R. <ti...@pr...> - 2011-03-24 17:17:12
|
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, ti...@pr... Providenza & Boekelheide, Inc. |
|
From: Michael P. <mic...@gm...> - 2011-03-25 00:19:11
|
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 |
|
From: Tim R. <ti...@pr...> - 2011-03-25 01:04:06
|
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, ti...@pr... Providenza & Boekelheide, Inc. |
|
From: Xiaofan C. <xia...@gm...> - 2011-03-25 03:18:59
|
On Fri, Mar 25, 2011 at 1:17 AM, Tim Roberts <ti...@pr...> wrote: > 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? Once upon a time (actually not so long ago) they do add the USB-IF Test ID (TID) in the Windows Logo Kit (WLK) requirement. http://msdn.microsoft.com/en-us/library/ee820106.aspx Of course that will not go down so well on the vendors... So Microsoft has to change the requirement. http://blogs.msdn.com/b/usbcoreblog/archive/2010/09/30/usb-if-testing-requirement-in-windows-logo-kit.aspx http://msdn.microsoft.com/en-us/windows/hardware/gg463175.aspx > 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. > With the new license requirement, they do add another roadblock for people who want to get WHQL for libusb-win32 based driver package. So we will change the driver license to BSD type in the future. On the other hand, I can understand why companies like Microsoft and Apple want to protect from the impact of GPL. -- 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