The problem is that there is no way for the driver to "post a message".
What you get is a device that doesn't work. If you use Device manager you'll find out that the device is using the XYZ driver from FTDI and that there is a "problem". Possibly with a cryptic windows error code.
I thought that too until I started adding up the optional stuff I had to add in to make it equivalent to to a Mac Mini. The Mac Mini (like Apple laptops) makes a great Windows system.
And even if you (like me) simply run Windows on it, being able to buy it at the local Apple store or be able to get it fixed at the local Apple store, by a company I trust to fix things is a win.
None of the other suppliers of Windows laptops have a local store where I can do that.
Huh... a high end Windows Laptop will set you back the same or more than an equivalent Mac laptop.
I looked around for better part of a year for a good Windows laptop to replace my ageing Acer Timeline. Finally just bought a MacBook Pro and installed Windows 8.1 on it.
IMHO Apple makes some of the best Windows laptops in the world.
Even if the chips where manufactured from the same dies and design in the same factory, if they are not being delivered to FTDI and sold by FTDI they are fake.
Like it or lump it, FTDI owns their design and their software. And the license to use their driver goes with an actual piece of hardware that they sell.
No, because then the end-user looks in Device Manager and sees that the driver, which is owned by FTDI, is experiencing a problem with their device. So they contact FTDI for support.
So not only did FTDI NOT make any money selling a chip for the device, now they would be on the hook to field support calls because the device does not "work" with their driver.
No JTAG (apparently) required. You do need to use an OS that will allow enumeration of a device with a product id of zero. And then have a driver for that device which will write a new product id for you using the same USB Device Requests that the FTDI driver originally used to set it to zero.
The problem is the inability of modern Windows to work with a device with a product id of zero.
And you'll return it to your supplier for a refund.
If it doesn't work return it. Let the supplier worry about it. He'll return to the distributor. They'll return to the manufacturer. The manufacturer will make sure they don't do that again.
Since there is no way to use the product without using illegal drivers there is now way to use it period. Bricking it doesn't make it usable all of a sudden. Also "bricking" in this case doesn't actually mean that the entire device is non-functional. Just the USB capability. Plug into windows and windows just complains.
And that is from FTDI's and Microsoft's position the preferable solution. Otherwise they get support calls saying my device is not working with your operating system or your driver. After the modification the indication is that the device is broken. So instead of bugging FTDI or Microsoft the end-user will return the device to their supplier.
Until and unless that product id is used and expected to be used by (for example) Windows to load a driver that is owned by the people who own the product id that you are using.
At that point you are circumventing the Windows mechanism and gaining illegal access to software for your hardware. Since you don't have an alternate driver you cannot even make a case that you didn't intend for your customers to use something other than the software you don't own or have rights to.
Since the manufacturer should be doing quality assurance testing. That should include plugging devices in and checking that they work. So they should be the first to notice if there are any problems with devices getting bricked.
Since this bricking is probably done the first time the device is used, and nobody is going to "collect" a bunch of data without testing that the device works by plugging it in first, etc, etc....
The result is the same. It works and life goes on. Or it doesn't work and you send it back. Whether the device is bricked or simply doesn't work is pretty irrelevant to most end users. It goes back in both cases.
Sure, and if you are using legal software (for example a class driver provided by the host os) that may be legal.
What is not legal is using the device identifier descriptors that are owned by another company so that you can illegally get the host OS to use that manufacturers driver.
Since FTDI doesn't sell end user consumer products it is highly unlikely the end user will blame FTDI.
More likely they will blame (roughly in order): the place they bought it from, the distributor, the device manufacturer.
This will in turn train the retailer to distrust the distributor, the distributor to distrust the manufacturer.
Which hopefully will make the manufacturer select actual FTDI chips OR write their own drivers instead of stealing FTDI's.
That means more sales of FTDI chips or possibly a reduced customer experience if the manufacturer does their own driver which in turn will push them back to FTDI based devices which will increase sales for FTDI.
You need about double that to allow for losses pushing the power into storage and getting it back out.
And you need some additional capacity for generation and storage to allow for days when you run at less than 100% efficiency. E.g. cloud cover or winter.
So 1MW/h becomes 3MW/h becomes 6MW/h becomes maybe 10MW/h and you might have 1-2 days best case backup for bad weather.
Slashdot Mirror
No it is the act of identifying criminal chips and disabling them.
No there are os's out there that can be used to reprogram the device.
It doesn't let the valuable smoke out. The device still works.
It is just not useful for USB communications until someone re-re-programs it to a vid/pid for another (non FTDI) driver.
Just because (currently) doesn't make it wrong. What was wrong was people trying to use unlicensed software illegally.
FTDI should just allocate a PID under their VID for the counterfeit chips.
Then reprogram counterfeit chips to that PID. The device would then still work anywhere with another driver that supported THAT vid/pid (e.g. linux.)
I just wouldn't work with the stolen vid/pid to access unlicensed software.
The problem is that there is no way for the driver to "post a message".
What you get is a device that doesn't work. If you use Device manager you'll find out that the device is using the XYZ driver from FTDI and that there is a "problem". Possibly with a cryptic windows error code.
I thought that too until I started adding up the optional stuff I had to add in to make it equivalent to to a Mac Mini. The Mac Mini (like Apple laptops) makes a great Windows system.
And even if you (like me) simply run Windows on it, being able to buy it at the local Apple store or be able to get it fixed at the local Apple store, by a company I trust to fix things is a win.
None of the other suppliers of Windows laptops have a local store where I can do that.
My cat has learned to pull the magsafe connector off and play with it. :-)
Huh... a high end Windows Laptop will set you back the same or more than an equivalent Mac laptop.
I looked around for better part of a year for a good Windows laptop to replace my ageing Acer Timeline. Finally just bought a MacBook Pro and installed Windows 8.1 on it.
IMHO Apple makes some of the best Windows laptops in the world.
Until they require the use of FTDI's software.
At that point no, they do not have any rights at all.
If manufacturers want to save a few bucks on a non-FTDI chip they should then hire someone to produce a driver that will work with that chip.
Even if the chips where manufactured from the same dies and design in the same factory, if they are not being delivered to FTDI and sold by FTDI they are fake.
Like it or lump it, FTDI owns their design and their software. And the license to use their driver goes with an actual piece of hardware that they sell.
Damage is a big word.
They are modifying an eeprom value such that the device will no longer attempt illegally use their driver.
Since eeprom's are designed to be written, multiple times, you cannot claim that is damage.
And it is unlikely that the actual function of the device is impaired. Just its ability to communicate with Windows.
No, because then the end-user looks in Device Manager and sees that the driver, which is owned by FTDI, is experiencing a problem with their device. So they contact FTDI for support.
So not only did FTDI NOT make any money selling a chip for the device, now they would be on the hook to field support calls because the device does not "work" with their driver.
No JTAG (apparently) required. You do need to use an OS that will allow enumeration of a device with a product id of zero. And then have a driver for that device which will write a new product id for you using the same USB Device Requests that the FTDI driver originally used to set it to zero.
The problem is the inability of modern Windows to work with a device with a product id of zero.
And you'll return it to your supplier for a refund.
If it doesn't work return it. Let the supplier worry about it. He'll return to the distributor. They'll return to the manufacturer. The manufacturer will make sure they don't do that again.
Since there is no way to use the product without using illegal drivers there is now way to use it period. Bricking it doesn't make it usable all of a sudden. Also "bricking" in this case doesn't actually mean that the entire device is non-functional. Just the USB capability. Plug into windows and windows just complains.
And that is from FTDI's and Microsoft's position the preferable solution. Otherwise they get support calls saying my device is not working with your operating system or your driver. After the modification the indication is that the device is broken. So instead of bugging FTDI or Microsoft the end-user will return the device to their supplier.
Until and unless that product id is used and expected to be used by (for example) Windows to load a driver that is owned by the people who own the product id that you are using.
At that point you are circumventing the Windows mechanism and gaining illegal access to software for your hardware. Since you don't have an alternate driver you cannot even make a case that you didn't intend for your customers to use something other than the software you don't own or have rights to.
Since the manufacturer should be doing quality assurance testing. That should include plugging devices in and checking that they work. So they should be the first to notice if there are any problems with devices getting bricked.
Since this bricking is probably done the first time the device is used, and nobody is going to "collect" a bunch of data without testing that the device works by plugging it in first, etc, etc....
The result is the same. It works and life goes on. Or it doesn't work and you send it back. Whether the device is bricked or simply doesn't work is pretty irrelevant to most end users. It goes back in both cases.
Sure, and if you are using legal software (for example a class driver provided by the host os) that may be legal.
What is not legal is using the device identifier descriptors that are owned by another company so that you can illegally get the host OS to use that manufacturers driver.
The issue is using other peoples copyrighted software illegally by pretending to be a compatible device.
I don't see that there is much if any difference in simply not working and bricking.
In either case, for most users, the result is exactly the same, their device does not work.
And if it doesn't work as advertised then they will return to store or online retailer.
If enough devices are returned the effect repeats itself up the chain and affects behaviour all the way along.
Using the device with unauthorized drivers is wrong and illegal. If your supplier told you to do that then sue them.
Since FTDI doesn't sell end user consumer products it is highly unlikely the end user will blame FTDI.
More likely they will blame (roughly in order): the place they bought it from, the distributor, the device manufacturer.
This will in turn train the retailer to distrust the distributor, the distributor to distrust the manufacturer.
Which hopefully will make the manufacturer select actual FTDI chips OR write their own drivers instead of stealing FTDI's.
That means more sales of FTDI chips or possibly a reduced customer experience if the manufacturer does their own driver which in turn will push them back to FTDI based devices which will increase sales for FTDI.
And take up more land.
Increased solar means increased habitat destruction.
Unlike Gas and Oil plants that produce plant fertilizer :-)
Not quite.
You need about double that to allow for losses pushing the power into storage and getting it back out.
And you need some additional capacity for generation and storage to allow for days when you run at less than 100% efficiency. E.g. cloud cover or winter.
So 1MW/h becomes 3MW/h becomes 6MW/h becomes maybe 10MW/h and you might have 1-2 days best case backup for bad weather.