Re: no key input

Re: no key input

[Dai Itasaka]

Thanks Harold for the special XWin.exe
but I must report "still no key input" on local xterms.

I noticed that my XWin.exe is dated as Oct 6. The latest
xserv went public on last Friday Oct 17 and I updated
it on the following Monday Oct 20. I know I was able
to move around on Oct 17(before I updated to the latest).

The latest package didn't update XWin.exe, did it?
Almost all other exe files in /usr/X11R6/bin are dated
as Oct 16 now so they are probably included in the latest
package but I don't think XWin.exe is.

This leads me to think that XWin.exe is not the culprit.

Re: no key input

[Harold L Hunt II]

Fabrice,

Fabrice Coudert wrote:

> After more investigation this bug appears when shared build of libXaw, 
> libXmu and libXt was
> enabled in the CVS 
> (http://cvsweb.xfree86.org/cvsweb/xc/config/cf/cygwin.rules.diff?r1=3.26&r2=3.27). 
> 
> Xterm works fine if I build the latest HEAD branch with cygwin.rules 
> rev. 3.26.
> 
> Now what is the real problem with those libraries ? Any clues will be 
> appreciated.

The real problem is that we need an OS/2-style call to the 
_XawFixupVendorShell function, along with a few other good bits.  I 
enabled a call to this function and tested a rebuild of Xaw... it works 
as expected.  The patch is in the following email:

http://cygwin.com/ml/cygwin-xfree/2003-11/msg00221.html


Harold

Re: no key input

[Fabrice Coudert]

After more investigation this bug appears when shared build of libXaw, 
libXmu and libXt was
enabled in the CVS 
(http://cvsweb.xfree86.org/cvsweb/xc/config/cf/cygwin.rules.diff?r1=3.26&r2=3.27).
Xterm works fine if I build the latest HEAD branch with cygwin.rules 
rev. 3.26.

Now what is the real problem with those libraries ? 
Any clues will be appreciated.

Fabrice.

Re: no key input

[Colin Harrison]

Hi,

>I didn't realize you were building from CVS... 
>I didn't realize anyone was doing that.

Yep some of us are still using CVS + various patches and customisations and
bodges (no pain no gain!).
My xc tree (XFree latest as of yesterday + patches) is as close as I thing
the game is and is still doing the job for me! (e.g. I've even patched for
new 'shared' rootless and haven't even used/tested it!).

Keep up the good work...I'll try to build/test new trees as they materialise
(within my scope...multiwindow and/or XDMCP on XP and Windows 2003 server
platforms)

Colin 

 

Re: no key input

[Harold L Hunt II]

Fabrice,

Fabrice Coudert wrote:

> Hi,
> 
> I made some investigation in -multiwindow mode :
> - the problem also occurs on latest Cygwin release with X-Win32 5.4 and
> Cygwin xterm 4.2.99.903(174)
> - remote xterm 4.2.99.3(172) from a Mandrake 9.1 is ok.
> - a port of the release 172 into Cygwin doesn't solve the problem.
> - cvs release xf-4_3_0 is ok
> - cvs release xf-4_3_0_1 is ok
> - cvs release xf-4_3_99_14 is ok
> - cvs HEAD grabed at 10.31.2003 00:05 GMT+1 doesn't build :p
> 
> xf-4_3_99_14 is enought for me to work with Cygwin/XFree86 in
> multiwindowed mode but, I continue further investigation in background
> on the HEAD branch trying to build it and using -D selector.

You mean to tell me that the problem doesn't happen in the XFree86-*
packages that I released?  I thought that was what had the problem.  I
didn't realize you were building from CVS... I didn't realize anyone was
doing that.  In any case, I think you know more about the problem that I
do now.  However, there have been updates to the XFree86 CVS that should
have been applied but were not, thus the public breakup that happened
earlier this week.  I am working on getting a tree setup at
freedesktop.org, so perhaps we can start debugging this better when that
tree is setup.

Thanks for looking into this,

Harold

Re: no key input

[Fabrice Coudert]

Hi,

I made some investigation in -multiwindow mode :
- the problem also occurs on latest Cygwin release with X-Win32 5.4 and
Cygwin xterm 4.2.99.903(174)
- remote xterm 4.2.99.3(172) from a Mandrake 9.1 is ok.
- a port of the release 172 into Cygwin doesn't solve the problem.
- cvs release xf-4_3_0 is ok
- cvs release xf-4_3_0_1 is ok
- cvs release xf-4_3_99_14 is ok
- cvs HEAD grabed at 10.31.2003 00:05 GMT+1 doesn't build :p

xf-4_3_99_14 is enought for me to work with Cygwin/XFree86 in
multiwindowed mode but, I continue further investigation in background
on the HEAD branch trying to build it and using -D selector.

Hope this help you.

Fabrice.

Re: no key input

[Harold L Hunt II]

Good point.  I think this has to do with the shared Xt library.  I will 
check into this.

Harold

Kensuke Matsuzaki wrote:

> Hi,
> 
> Even if I use X-Win32 and eXcursion trial version, I can't input using
> keyboard when mouse cursor is not on xterm.
> And remote xterm is all right.
> So perhaps this problem depends on client side.
> 
> Kensuke Matsuzaki

Re: no key input

[Kensuke Matsuzaki]

Hi,

Even if I use X-Win32 and eXcursion trial version, I can't input using
keyboard when mouse cursor is not on xterm.
And remote xterm is all right.
So perhaps this problem depends on client side.

Kensuke Matsuzaki

Re: no key input

[Harold L Hunt II]

Dai,

Very good documentation of your bug.  Thanks.

One undocumented change I made somewhere between October 4th and October
24th was to include the final version of Ivan Pascal's
xc/programs/Xserver/os/WaitFor.c patch:

http://cvs.sourceforge.net/viewcvs.py/xoncygwin/xc/programs/Xserver/os/WaitFor.c?r1=1.2&r2=1.3

I suspect that this patch may be involved with the keyboard focus
problems, since the problem seems to affect multi-window, rootless, and
standard modes of operation.  I have not yet merged Kensuke's new
rootless code into a release, so I know that his new code has nothing to
do with this at all.

I have built a special test version of XWin.exe for you to check out.
The test version's only difference from 4.3.0-20 is that it reverts the
above patch to WaitFor.c.  Please run it and report your results:

http://www.msu.edu/~huntharo/xwin/devel/server/XWin-4.3.0-20-Test01.exe.bz2


Thanks for testing,

Harold


Dai Itasaka wrote:

> My startxwin.sh gives me the root window and an xterm window in it.
> I login to a remote host from this xterm after doing xhost for it.
> From there, I invoke xterm specifying the local PC as the display.
> Now I have two xterm windows here: one invoked locally, the other
> invoked from the remote host.
> 
> TWM is my window manager. My preference is to show the IconManager
> at the upper right hand corner of the root, in which I can move
> from one icon to the next by pressing the keyboard combo specified
> in the ~/.twmrc as "f.downiconmgr" or "f.upiconmgr". If I press
> the key combo, no matter where the mouse cursor is at, it jumps
> to the IconManager area and points to the window that has the keyboard
> focus at the time. As I press the "up" or the "down" key, the mouse
> cursor jumps to one icon up or down, and the keyboard focus moves
> to the corresponding window at once. This is the equivalent of
> MS Windows' Alt-Tab for me in X(no autoraise by default though).
> This is how I move the keyboard focus from one window to another.
> I can't live without this as I have been doing this for over 10
> years now. I'm so accustomed to it that I sometimes do it in MS
> Windows.
> 
> Now, with the latest Cygwin install, I still can move the keyboard
> focus by pressing the "up" or "down" key, thus I can toggle the
> keyboard focus between the two xterm windows I mentioned above.
> But, the xterm that is locally executed(cygwin xterm) doesnt take
> any key input unless I move the mouse cursor over the xterm
> window area, while the one that is remotely executed can take key
> inputs as usual without moving a mouse(the mouse cursor stays in
> the IconManager area).
> 
> Until the one before the latest(XFree86-xserv-4.3.0-18?), this was
> not the case. I was able to move around AND TYPE. Something that
> was added since then broke this capability.
> 

no key input

[Dai Itasaka]

My startxwin.sh gives me the root window and an xterm window in it.
I login to a remote host from this xterm after doing xhost for it.
>From there, I invoke xterm specifying the local PC as the display.
Now I have two xterm windows here: one invoked locally, the other
invoked from the remote host.

TWM is my window manager. My preference is to show the IconManager
at the upper right hand corner of the root, in which I can move
from one icon to the next by pressing the keyboard combo specified
in the ~/.twmrc as "f.downiconmgr" or "f.upiconmgr". If I press
the key combo, no matter where the mouse cursor is at, it jumps
to the IconManager area and points to the window that has the keyboard
focus at the time. As I press the "up" or the "down" key, the mouse
cursor jumps to one icon up or down, and the keyboard focus moves
to the corresponding window at once. This is the equivalent of
MS Windows' Alt-Tab for me in X(no autoraise by default though).
This is how I move the keyboard focus from one window to another.
I can't live without this as I have been doing this for over 10
years now. I'm so accustomed to it that I sometimes do it in MS
Windows.

Now, with the latest Cygwin install, I still can move the keyboard
focus by pressing the "up" or "down" key, thus I can toggle the
keyboard focus between the two xterm windows I mentioned above.
But, the xterm that is locally executed(cygwin xterm) doesnt take
any key input unless I move the mouse cursor over the xterm
window area, while the one that is remotely executed can take key
inputs as usual without moving a mouse(the mouse cursor stays in
the IconManager area).

Until the one before the latest(XFree86-xserv-4.3.0-18?), this was
not the case. I was able to move around AND TYPE. Something that
was added since then broke this capability.