grag38 / qextserialport

Automatically exported from code.google.com/p/qextserialport
0 stars 0 forks source link

Need device discovery / removal notification on *nix #2

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
We have support now for event-driven (non-polling) notifications on Windows & 
OS X for device 
discovery / removal.  It would be great to determine how best to support this 
on the various *nix 
platforms.

If you have any experience with this, please chime in with what technology 
might work best and 
especially with any patches!

Original issue reported on code.google.com by lst...@gmail.com on 3 Jun 2009 at 3:28

GoogleCodeExporter commented 8 years ago
The problem is that /dev interfaces vary wildly per platform. I'd take a look 
at what
KDE's Solid did for udev and devfs for Linux. I'm not sure if Solid supports 
more
obscure platforms like HP-UX, AIX, etc.

For a hack solution one could use a QFileSystemWatcher on /dev and look for 
changes
in "known names" like /dev/ttyUSB0 showed up where there was only /dev/ttyS0 
before.
These names also tend to be platform specific though.

Original comment by noel.jus...@gmail.com on 3 Jun 2009 at 3:55

GoogleCodeExporter commented 8 years ago
I hacked Linux device discovery/removal notifications using libudev into my 
cloned repository. It may need some refinement and polishing, but it seems to 
work:

https://code.google.com/r/doug-qextserialport-linuxnotifications/source/detail?r
=d8d124b21d5a4b1d1ec54690e6b7b5fba9541db2

(Also added in the patch from issue #69 to fix Windows notifications for USB 
serial converters)

I couldn't figure out how to differentiate Linux from other Unix-like OSs 
(except OS X) in qmake, so I just replaced the reference to the existing 
qextserialenumerator_unix.cpp with qextserialenumerator_linux.cpp. If someone 
could figure out how to differentiate Linux from the other OSes in 
qextserialport.pri, that would be great...

Not sure if this change has any licensing implications (looks like libudev is 
LGPL, so we probably have to include a notice of some kind).

Thoughts?

Original comment by d...@schmorgal.com on 19 May 2012 at 8:38

GoogleCodeExporter commented 8 years ago
  "I couldn't figure out how to differentiate Linux from other Unix-like OSs (except OS X) in qmake"

linux-*: should be used in such case.

  "Not sure if this change has any licensing implications (looks like libudev is LGPL, so we probably have to include a notice of some kind)."

I have no idea. Perhaps we had better add a option to disable it if we made it 
as default.

Original comment by dbzhang...@gmail.com on 21 May 2012 at 7:19

GoogleCodeExporter commented 8 years ago
Thanks for the advice -- I made the change to use linux-*, so now Unix-like 
OSes other than Linux and OS X use the original qextserialenumerator_unix.cpp. 
Seems to work OK.

I think linking against libudev doesn't present much of a problem. The big deal 
of the LGPL is being able to take the combined program/QextSerialPort/libudev 
and being able to replace libudev with a newer/changed version. As long as it's 
dynamically linked against libudev, we shouldn't have any problems. I just 
don't know how to include licensing documentation with QextSerialPort stating 
that it uses libudev on Linux. Most examples I see are of programs linking 
against LGPL libraries -- not libraries linking against LGPL libraries.

The only other problem I can think of with my change is that it finds several 
devices that are not actually serial ports -- virtual tty devices like 
/dev/tty1, /dev/ttyprintk, /dev/console, and /dev/ptmx. I suppose I could add a 
blacklist to ensure those devices don't appear in the list.

Original comment by d...@schmorgal.com on 22 May 2012 at 2:07

GoogleCodeExporter commented 8 years ago
doug, I have merge your patch to default branch.And you can do more work based 
on this.

https://code.google.com/p/qextserialport/source/detail?r=0b78eb88bd8c93c0c440c80
d0ab54e4b2076f8fe

Thanks

Original comment by dbzhang...@gmail.com on 12 Jun 2012 at 8:17

GoogleCodeExporter commented 8 years ago
How can I use some event fired on disconnect?

Original comment by da...@supridatta.com.br on 29 Nov 2012 at 5:49

GoogleCodeExporter commented 8 years ago
How I can download this merged version with notification working?
I need this on my project!

Thanks all!

Original comment by da...@supridatta.com.br on 30 Nov 2012 at 11:31

GoogleCodeExporter commented 8 years ago
Found a bug in the libudev monitor code - a Latin1String is used to wrap a 
const char pointer which is deallocated before we are done using it. This part:

    QLatin1String action(udev_device_get_action(dev));
    udev_device_unref(dev);

    if (action == QLatin1String("add"))
        Q_EMIT q->deviceDiscovered(pi);
    else if (action == QLatin1String("remove"))
        Q_EMIT q->deviceRemoved(pi);

should be:

    QLatin1String action(udev_device_get_action(dev));

    if (action == QLatin1String("add"))
        Q_EMIT q->deviceDiscovered(pi);
    else if (action == QLatin1String("remove"))
        Q_EMIT q->deviceRemoved(pi);

    udev_device_unref(dev);

Patch attached.

Original comment by nilsson....@gmail.com on 4 Mar 2013 at 2:44

Attachments:

GoogleCodeExporter commented 8 years ago
Oops, totally my bad. I didn't realize that QLatin1String was a light wrapper 
class until now. Thanks for pointing that out!

Original comment by d...@schmorgal.com on 4 Mar 2013 at 7:06