summaryrefslogtreecommitdiffstats
path: root/core/divelist.c
diff options
context:
space:
mode:
authorGravatar Linus Torvalds <torvalds@linux-foundation.org>2018-10-07 12:41:21 -0700
committerGravatar Dirk Hohndel <dirk@hohndel.org>2018-10-08 00:10:29 +0300
commit7618240009661c471334c903df67194fbd870202 (patch)
treecaf4c5e9307cff4844b3791d6845a27747af1787 /core/divelist.c
parent9e3a22c5220f72fb9b9358dc127808186d3398dd (diff)
downloadsubsurface-7618240009661c471334c903df67194fbd870202.tar.gz
ftdi: make the timeout be based on actual real time
bperrybap reported on github that the ftdi timeouts can be excessive: "the timeout period while waiting for read data to be 10x or even 100x longer than it should be when there are read issues on the data cable particularly when using Android and USB OTG cables. i.e. a 5 second read timeout for not receiving data can be as long as 7 minutes" and the reason is that the code at one point tried to use the regular "gettimeofday()" to handle timeouts, but that doesn't exist in Windows. We already have Windows-specific code to sleep for a number of milliseconds in "ftdi_serial_sleep()", let's just extend that same concept and add a "ftdi_serial_get_msec()" that returns the number of msec's since some arbitrary point in time. On Windows, that's just "GetTickCount()", and in sane environments it's just a trivial wrapper around gettimeofday() to turn sec/usec into msec. NOTE! The actual msec value doesn't have any meaning. Only the difference between two calls to ftdi_serial_get_msec() is meaningful. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'core/divelist.c')
0 files changed, 0 insertions, 0 deletions