more on key locks, problems with unified patch

[Ben McKeegan <Ben.McKeegan@xxxxxxxxxxxxxx>]

On Wed, 10 Jan 2001, Peter Bystrom wrote:

> I believe the patch you are talking about is already included if I'm wrong, tell
> me. ;) 

As I said in my previous message I was looking at the wrong file.  :-)  
(I think its a bit confusing that the patch18 subdirectory doesn't
actually contain patch18 itself, and since the browser I was using to
read the patch wasnt set up to handle .bz2 files I wasn't able to read
the actual patch anyway.)

>by the way, is there anyway that the program could check the real status
> of the caps/num keys so they get synced?

I think the main problem is that we don't currently know to tell the
terminal server to set the lock status to a specific value or query its
current setting.  All we can do is toggle the status by sending a key
down/up pair of scancodes.  We can't even work the status out, because you
don't know what the starting status was (key lock status appears to be
preserved for disconnected sessions)  and some applications (e.g. ms word)
can toggle the lock status.

I've tried patch18, and unfortunately it breaks things for me in several
ways.  Firstly, on the subject of the lock keys it gives me the following
symptoms:

- You have to press a key lock key twice to change the corresponding lock
status.
- Since pressing the key lock a single time toggles the LED, the LED is
never properly syncronized with the key lock status.

Does anybody else at all experience the same thing, or is this just a
weirdness in my X server?

The problem is caused be the fact my X server treats the lock keys
differently to other keys, and generates only a single event per key.
i.e. when you turn on the key lock, it generates a single key down event.
When you turn off the key lock, it generates a single key up event.
Windows expects to see a key down and key up pair in each case.

The second version of my keyboard patch (on my web site along with the one
you used) included a fix for this, but if the problem is not experienced
by everybody else my fix would certainly break things for them.  In that
case, should I rewrite the fix to be a compatibility option that is turned
on via a command line switch?

The other problems I've had with the unified patch are:

- colour corruption on an 8 bpp display: e.g. bright green is substituted
for white.  This didn't happen before.   

- something is blocking in the event handling.  The symptoms of this is a
sluggish response and occasionally the screen freezes until I move the
mouse or press a key.  A neat trick I can do to demonstrate this is
dragging a window as a wireframe outline: sometimes when I release the
mouse it sticks with the outline of the new window showing.  I then have
to nudge the mouse or press a key before it actually redraws the window in
its new location. 

I suspect later problem is caused by the modifications to tcp.c
such that it does a select on ui_socket rather than just timing out: I
experienced similar problems when I tried applying the original patch for 
this.  I would guess that the problem might be because the 'select'
function can sometimes act counter-intuitively.  

Ben.

/   Ben McKeegan, I.T. Manager                                         \
\   Fitzwilliam College, University of Cambridge, UK.                  /