How to detect USB device disconnect under Linux/Qt/C++

Question

I'm writing a system (X-Platform Windows/Linux) that talks to a custom device using an FTDI USB chip. I use their D2XX driver for device open/close/read/write. So far, so good.

I need to know when the device is disconnected so the program can respond gracefully. At present, under Windows the application receives a sudden unexpected close. Under Linux, when the device is disconnected, there is a sgementation fault.

I have found informaiton under Windows about listening for the WM_DEVICECHANGE message. However, I have not found how to detect this event under Windows. There is information for the device driver level interacting with the kernel. However, I can't figure out how to do this at an application level. The FTDI driver does not offer any such service.

The system is written using the Qt framework with C++. The device driver is FTDI's D2XX driver.

Can anyone point me in the right direction?

Thanks so much in advance! Judy

Answer 1

You'll probably want to use HAL (freedesktop.org's Hardware Abstraction Layer).

In the future you will probably want to use DeviceKit. It is a project fix the many problems with HAL. It hasn't been adopted by all major distros yet though (I think just Fedora), so you probably don't want to use it right now.

Edit: As Jeach said, you can use udev also. I wouldn't suggest this, as it is much lower level, and harder to program, but if latency is very important, this might be the best option.

Answer 2

Hi Judy,

Although what I'm about to tell you won't directly answer your question, it may give you a hint as to your next move.

I use udev rules configured in '/etc/udev/rules.d/' which run various scripts. When a USB device gets connected/disconnected I run a script which sends a HUP signal to my binary. Since my requirements can handle a bit of lag it works perfectly fine for me.

But my point is that maybe there is a udev library you can link to and register events programmatically (instead of scripts).

Hope it helps... good luck!

Answer 3

Don't forget that you have two problems here :

• Detecting device insertion / removal
• Properly terminating your application.

The first problem has been adressed by Zifre.

But the second problem remains : your Linux app should not be segfaulting when the device is removed, and I think the two problems are unrelated : if the device is removed in the middle of a write or read system call, then those system call will return with an error before you get any notification, and this should not segfault your app.

Answer 4

Valid point. I think it's the FTDI D2XX library that is creating the segfault when the next call is made to it after the device has been disconnected. I'll do some testing and verify. The Linux verision of the FTDI D2XX library seems prone to segfaults. – Judy Duncan Jun 18 at 19:03

I too am working with a custom device with an FTDI chip. I found that the jd2xx Linux driver runs a seperate pthread ('readerThread' i think it is called). This seperate thread seems to do some polling. This thread is what generates the segfault, most likely becuase it is assuming there is always the two FTDI status bytes available when it reads.

The FTDI jd2xx driver is closed source on both windows and linux, so I can't be certain. After looking through stack and system call traces, this is what I have come to.

I am currently trying to use the open-source libftdi in linux to accomplish what we need (it doesn't segfault). Both the libraries use libusb in linux. But I am having some problems, as it appears the jd2xx driver performs some weird magic (good reason to keep it closed-source, you don't want anyone to get your magic).