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

Lost keyboard input after suspend on Windows 10 PowerShell #449

Closed
derailed opened this issue Apr 19, 2021 · 14 comments
Closed

Lost keyboard input after suspend on Windows 10 PowerShell #449

derailed opened this issue Apr 19, 2021 · 14 comments

Comments

@derailed
Copy link
Sponsor

I appears tcell v2.2.1 on Windows10 using powershell broke all keyboard inputs upon suspending and resuming an application. This behavior worked correctly of v.2.2.0.

@gdamore
Copy link
Owner

gdamore commented Apr 19, 2021

This does not seem to be a problem running the mouse.go demo application on Windows 10.

Can you share a bit more about what you're doing in the suspend?

@gdamore
Copy link
Owner

gdamore commented Apr 19, 2021

(For mouse.go, just press ctrl-z to "suspend".)

@derailed
Copy link
Sponsor Author

Thank you for the prompt reply Garrett!
I am doing a fork and exec and essentially running a shell so very close to what you're doing in mouse.go. I've checked out mouse.go on windows and you're correct it does seem to keep inputs upon resume. Also v2.2.1 works correctly on osx.
On windows, this worked correctly (minus cursor) on v2.2.0. I've just updated to v2.2.1 and my app is no longer responding to keyboard input upon resume. I haven't debugged it as of yet to see what's happening....

@gdamore
Copy link
Owner

gdamore commented Apr 19, 2021

The only thing I did in v2.2.1 for Windows different was to fix the cursor.

@derailed
Copy link
Sponsor Author

FYI I've reverted commits 3d0a and d20e and my app is now working correctly after suspend/resume on windows...

@gdamore
Copy link
Owner

gdamore commented Apr 19, 2021 via email

@derailed
Copy link
Sponsor Author

derailed commented May 2, 2021

@gdamore Any update on this issue? Fixed windows but broke linux. Any ways out of the predicament? Thanks Garrett!

@gdamore
Copy link
Owner

gdamore commented May 15, 2021

Please have a look at my "tty" branch. I think it works well on both Windows and Linux now. I haven't tested macOS as I don't have a macOS system handy at this precise instant.

@gdamore gdamore changed the title Lost keyboard input after suspend on Windows 10 PowerShell.... Lost keyboard input after suspend on Windows 10 PowerShell May 15, 2021
gdamore added a commit that referenced this issue May 15, 2021
fixes #449 Lost keyboard input after suspend on Windows 10 PowerShell
fixes #148 Make tcell usable with any io.Reader and io.Writer

This introduces a new Tty interface so that applications can supply
their own implementation.  This should facilitate work for applications
that wish to provide e.g. a webasm version of the terminal, or that need
to use different kinds of file plumbing.
@derailed
Copy link
Sponsor Author

Tx Garrett!
I could not find a branch tty on this repo?? but went to the commit instead...

Sadly I don't think it's fixed ;(

  1. Key bindings toast after resume on windows 10 Powershell.
  2. On OSX the screen only shows the first line on resume, try to resize to force a redraw bombs on tty_unix.go:80

Please reopen so we can track this down as my app is currently in no mans land ;(

@gdamore
Copy link
Owner

gdamore commented May 19, 2021

Please update to v2.3.1. If that still doesn't work, let me know.

@derailed
Copy link
Sponsor Author

Thanks Garrett! I did try out v2.3.1 seems to have resolved the resume issue on OSX. Thank you for that!
But still a dud on windows ie upon resume, lost all my keyboard inputs ;( This is using powershell on windows 10.

@gdamore
Copy link
Owner

gdamore commented May 19, 2021

Does the _demos/mouse.go program work for you? -- if you press ctrl-z it should work, and exit should work, with normal keys working. I'm using Windows 10 with powershell myself.

@gdamore
Copy link
Owner

gdamore commented May 19, 2021

Make sure you aren't calling Fini(). Only Suspend(). Fini() will probably do things you don't want.

@derailed
Copy link
Sponsor Author

Tx for the suggestions Garret!

I think the problem lies Here
When the screen is disengage stopQ channel is closed thus stopping the event loop since the select will fire on that case. I think the issue here is we should stop the event poll when the Fini is called. But for windows Fini just turns around and calls disengage thus there is no clean delineation when the screen is suspended vs when we're done with the screen.

Note: I could be totally off here as I am my phone as more mem than the crap windows box I am on ;( Less than ideal to debug in this env but changing the line above to read <-s.quit and having Fini close(s.quit) instead seems to fix particular issue.

Does this make sense?

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

No branches or pull requests

2 participants