Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Avoid error when changing the read timeout on a serial port #6068

Merged
merged 3 commits into from Aug 4, 2016

Conversation

dkager
Copy link
Collaborator

@dkager dkager commented Jun 14, 2016

Related issue: #6035
This explicitly uses SetCommTimeouts to change the read timeout of a serial port. In pyserial, the entire port is reconfigured, sometimes causing an error if the computer was busy. I've run this patch on the machine that was causing me the most problems for two days and didn't get the error.

Another request is to turn pyserial into a Git submodule and upgrade it to version 2.7 (tag release2_7).

@dkager
Copy link
Collaborator Author

dkager commented Jun 30, 2016

It would be hugely appreciated if this could be perused for 2016.2 (don't we all say that, haha). I have recently started to run large'ish batches of unit tests and that constantly causes this error even when working in another window. Still no lemons on this branch.

# timeout=None to clear all timeouts, else a positive number of milliseconds.
timeouts = COMMTIMEOUTS()
if timeout is not None:
timeouts.ReadTotalTimeoutConstant = max(int(timeout * 1000), 1)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While this certainly sets the read timeout, unless I'm missing something, it also resets all other timeouts to 0 (including the write timeout). We can't assume the caller is only interested in the read timeout. Drivers do set the write timeout. In fact, no write timeout could be quite bad for real serial ports, since they may have no way of knowing the device was disconnected.

@dkager
Copy link
Collaborator Author

dkager commented Jul 1, 2016

True. This patch is based on hwIo, which never sets the other timeouts. It doesn't help that drivers also talk to the serial port directly. This can probably be solved by first requesting the current timeouts, or maybe by grabbing these parameters from pyserial. Though I think those are private, so accessing them is ugly.

@jcsteh
Copy link
Contributor

jcsteh commented Jul 1, 2016 via email

@dkager
Copy link
Collaborator Author

dkager commented Jul 1, 2016

In pyserial 3.x hComPort actually has an underscore. I am using that code to deal with timeouts, since it is backwards compatible but looks a bit nicer (using a struct instead of a tuple). Of course for NVDA we decided to stick with 2.7.

I'll update my patch and test again with the Brailliant.

@jcsteh
Copy link
Contributor

jcsteh commented Jul 1, 2016 via email

@dkager
Copy link
Collaborator Author

dkager commented Jul 2, 2016

No dependency on pyserial 2.7, the only thing used from pyserial (except for attributes) is the _COMMTIMEOUTS struct. That is present in 2.5 as well.

@dkager
Copy link
Collaborator Author

dkager commented Jul 2, 2016

Pushed a fix and will test on Monday.

# Adapted from pyserial 3.1.1.
timeouts = COMMTIMEOUTS()
if timeout is None:
pass # default of all zeros is OK
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd prefer we didn't have empty blocks in an if like this. I'd change the else below to elif timeout is not None. Same with the later pass statements.

@dkager
Copy link
Collaborator Author

dkager commented Jul 4, 2016

I agree, but thought it might be less clear where the code came from if edited. But I'll change it. :)

@jcsteh
Copy link
Contributor

jcsteh commented Jul 4, 2016 via email

@dkager
Copy link
Collaborator Author

dkager commented Jul 4, 2016

Just pushed a fixup for both issues, and actually got to test it this time.

jcsteh added a commit that referenced this pull request Jul 5, 2016
@michaelDCurran
Copy link
Member

Can someone please provide a suitable what's new entry on this pr? Then I can merge this to master. I don't quite understand its user-facing change.

@jcsteh
Copy link
Contributor

jcsteh commented Jul 25, 2016

In Bug Fixes:

  • Baum compatible and HumanWare Brailliant B braille displays no longer occasionally stop recognising key presses.
    Obviously, add the issue number to that; can't get it right now. :)

@jcsteh
Copy link
Contributor

jcsteh commented Jul 25, 2016

Actually, that is better written as: NVDA no longer occasionally stops rrecognising key presses on Baum compatible and HumanWare Bralliant B braille displays.

@michaelDCurran michaelDCurran merged commit 9d78cdb into nvaccess:master Aug 4, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants