#2698 closed defect (worksforme)
wine console does not get keyboard events
| Reported by: | Antoine Martin | Owned by: | Antoine Martin |
|---|---|---|---|
| Priority: | critical | Milestone: | 4.1 |
| Component: | core | Version: | 3.0.x |
| Keywords: | Cc: |
Description
Change History (4)
comment:1 Changed 11 months ago by
comment:2 Changed 10 months ago by
| Priority: | major → critical |
|---|---|
| Status: | new → assigned |
Workaround for wine apps in r26291: start the server with:
xpra start --env=XPRA_FORCE_XSETINPUTFOCUS=1 ...
Maybe we can change the default to always call XSetInputFocus rather than checking the "input_field"? (or maybe it isn't set properly for wine apps?)
comment:3 Changed 10 months ago by
| Resolution: | → worksforme |
|---|---|
| Status: | assigned → closed |
r26312 changes the default to always call XSetInputFocus for 4.1
If this causes problems, we can revert it.
comment:4 Changed 6 weeks ago by
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/2698
Note: See
TracTickets for help on using
tickets.
copyleft 2010 - 2021
I believe I came across this myself. Running
wine <app>directly underxpra startappears to be totally functional, and responds to mouse input; however no keypress events are acknowledged by the wine application.I tried instead launching the
wineprocess by hand under anxterminstance viaxpra start --start-child=xterm, and found that the keystrokes intended for thewineapplication in fact reflect in the xterm window. From this behavior, I assumed the issue was focus based.I found that by running under
start-desktopwith a window manager, the process then begins to behave as expected; egxpra start-desktop --start=blackbox --start-child=wine winecfgHopefully this provides some assistance in tracking down the root cause of this behavior, or at very least, a viable workaround for others.
PS. Nice to see a Trac instance still going strong! \m/