#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.
I believe I came across this myself. Running
wine <app>
directly underxpra start
appears to be totally functional, and responds to mouse input; however no keypress events are acknowledged by the wine application.I tried instead launching the
wine
process by hand under anxterm
instance viaxpra start --start-child=xterm
, and found that the keystrokes intended for thewine
application in fact reflect in the xterm window. From this behavior, I assumed the issue was focus based.I found that by running under
start-desktop
with a window manager, the process then begins to behave as expected; egxpra start-desktop --start=blackbox --start-child=wine winecfg
Hopefully 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/