re: numlock sync patch

[Peter Bystrom <peter.bystrom@xxxxxxxxx>]

a correction is at place, it _does_ send the information, I missed this part 
earlier... 


During an AS session, an ASCE need only send keyboard events when providing 
input to a remotely hosted application. It need not send keyboard events for 
keys typed before it became active, or when the conference is in conducted 
mode and it does not have conductorship privileges, or it is not in control, 
or it is detached.
A sending ASCE shall ensure that the portions of the local input stream that 
are sent in keyboard events in InputPDUs are internally consistent. For 
example, suppose that the local end-user had CapsLock on before the ASCE 
became active in the AS session, and then takes control of a remotely hosted 
application and starts typing. The ASCE must precede sent keyboard events 
with additional keyboard events containing CapsLock down/up events, and rely 
on peer ASCEs to prepare their local keyboard state so that the CapsLock 
down/up takes effect (which may be a null operation if CapsLock was on 
remotely as well) to ensure that the input is capitalized on the remote 
system.
The general requirement is that the sending ASCE inserts keyboard events as 
required into the outgoing input stream to synchronize the remote keyboard to 
the local keyboard state.
During an AS session, an ASCE may receive input from multiple peer ASCEs. For 
example, where an ASCE is hosting an application in a multipoint conference, 
several peer ASCEs may provide input in turn, as the remote end-users 
exchange control and provide input to the hosted application. While an ASCE 
can rely on the sending ASCEs inserting any required state (see above), it is 
responsible for undoing any local keyboard state established on behalf of 
other peer ASCEs before processing input from a new ASCE. For example, if 
ASCE A is hosting the application, ASCE B is in control and has CapsLock on 
and control switches to ASCE C who already has NumLock on, then when ASCE A 
switches input from ASCE B to ASCE C, it can rely on ASCE C prefacing its 
input stream with a  NumLock-down, NumLock-up, but is itself responsible for 
undoing the CapsLock state established on behalf of ASCE B. When ASCE A 
subsequently switches input from ASCE C back to ASCE B, it is then 
responsible for re-establishing the CapsLock on state on behalf of ASCE B.
The general requirement is that a receiving ASCE is responsible for taking 
any local action required to synchronize the local keyboard state to that of 
a new input stream.