Hacker News Reader

Comment by mkj | Hacker News Reader

Why do people need a FTDI driver, it appears that Windows has a USB Serial Class driver? https://msdn.microsoft.com/en-us/library/windows/hardware/dn...

At least on recent OSX the OS CDC one seems more robust than the FTDI provided one if you pull a cable while it's running. (I assume it's a genuine chip, who knows!)

View on HN

People need a FTDI driver because the UARTs by FTDI aren't "class compliant". Just as most other interface chips aren't "class compliant".

Here are all the drivers for "proprietary" USB UARTs that are currently supported by Linux: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux....

Here's the class compliant "Abstract Control Model driver for USB modems and ISDN adapters": https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux....

One gem in the driver heap is Linux' FTDI driver: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux....

Hah. Wonderful.

  /*
   * Certain versions of the official Windows FTDI driver reprogrammed
   * counterfeit FTDI devices to PID 0. Support these devices anyway.
   */
  #define FTDI_BRICK_PID		0x0000

I seem to recall that the reason was that Windows XP had a very badly broken CDC class driver so everyone (FTDI and Prolific own this market) ignored CDC and made their interfaces vendor specific.

Here's the old knowledge base article for the fix that eventually patched usbser.sys:

https://support.microsoft.com/en-ca/kb/943198

Windows 10 automatically installs FTDI's driver without asking the user, or giving the user the option to opt-out, or a way to downgrade to a working version of the driver.

The best Windows ever keeps getting better; or something.

Those FTDI chips and clones only work with that driver. They aren't class compliant. What should Windows do here when a device gives the FTDI USB ID? Seems like its doing what it should.

Use the old driver? At least give the user the option to keep using the old driver?

Windows has driver roll-back built-in.

Also, businesses typically use WSUS, where you need to intentionally whitelist driver updates.

If you have a CNC machine set to get all Windows Update from MS without oversight and testing, well, you're doing it wrong. I suspect a lot of "GUISE MY CLIENTS ALL HAVE DOWNED MACHINES THIS MORNING" is straight-up bullshit. In my experience, CNC machines are sacred cows and never, ever updated, let alone ever get driver updates. Hell, it isn't even patch Tuesday.

This does punish the hobbyist who just bought some toy and WU grabbed the latest driver. The world's manufacturing isn't going down this morning. Lets stop being naive.

Any time you use words "typically" and "doing it wrong", you can assume that thousands of people are typically doing it wrong.

Also, it's a little late for driver rollback if your hardware is already bricked.

Had to resort to the FTDI supplied driver on OSX because the OSX bundled FTDI driver caused the entire usb subsystem to die.

I reproduced the issue by connecting two FTDI serial ports, opened each /dev/cu.usbserial* device node with a screen session, and piped War and Peace.txt through at 115200 baud. Closing the screen session on the read end would cause ALL usb devices connected to the Mac to cease functioning.

You can get better performance using the proprietary driver because you get access to all the device parameters. Depending on your application this can be critical.

Reply on news.ycombinator.com