When receiving a key event on Linux, set host lock state to match client's

When receiving a key event on Linux, set host lock state to match client's

BUG=176436
Review-Url: https://codereview.chromium.org/2844533002
Cr-Commit-Position: refs/heads/master@{#467116}
Committed: https://chromium.googlesource.com/chromium/src/+/f232398ebba7a9074272ac9c9c5fd0f73c73a5da

[rkjnsn, 2017-04-25 19:25:02]

rkjnsn@chromium.org changed reviewers:
+ jamiewalch@chromium.org

[rkjnsn, 2017-04-25 19:25:03]

https://codereview.chromium.org/2844533002/diff/1/remoting/host/input_injecto...
File remoting/host/input_injector_x11.cc (right):

https://codereview.chromium.org/2844533002/diff/1/remoting/host/input_injecto...
remoting/host/input_injector_x11.cc:369: lock_values);
We could check the existing states first instead of indiscriminately setting
them, but I'm not sure that would offer any advantages. Certainly, it would
result in an extra server round trip in the out-of-sync case.

XkbLockModifiers could fail, which would leave things no worse than today.
However, would it makes sense to log a warning in that case? It could
potentially be triggered every key press, so I currently just ignore any errors.

[rkjnsn, 2017-04-25 19:25:32]

Description was changed from

==========
When receiving a key event on Linux, set host lock state to match client's.

BUG=176436
==========

to

==========
When receiving a key event on Linux, set host lock state to match client's

BUG=176436
==========

[Jamie, 2017-04-25 20:15:57]

lgtm

https://codereview.chromium.org/2844533002/diff/1/remoting/host/input_injecto...
File remoting/host/input_injector_x11.cc (right):

https://codereview.chromium.org/2844533002/diff/1/remoting/host/input_injecto...
remoting/host/input_injector_x11.cc:369: lock_values);
On 2017/04/25 19:25:03, rkjnsn wrote:
> We could check the existing states first instead of indiscriminately setting
> them, but I'm not sure that would offer any advantages. Certainly, it would
> result in an extra server round trip in the out-of-sync case.
> 
> XkbLockModifiers could fail, which would leave things no worse than today.
> However, would it makes sense to log a warning in that case? It could
> potentially be triggered every key press, so I currently just ignore any
errors.

I think this is fine. The documentation suggests that it can fail if the request
wasn't sent, but gives no indication as to why that might be.

[rkjnsn, 2017-04-25 20:29:42]

The CQ bit was checked by rkjnsn@chromium.org

[commit-bot: I haz the power, 2017-04-25 20:30:32]

CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-04-25 21:21:49]

CQ is committing da patch.

Bot data: {"patchset_id": 1, "attempt_start_ts": 1493152182455750, "parent_rev":
"b474ac026a716ec1858d12888193993ba70bd868", "commit_rev":
"f232398ebba7a9074272ac9c9c5fd0f73c73a5da"}

[commit-bot: I haz the power, 2017-04-25 21:22:01]

Description was changed from

==========
When receiving a key event on Linux, set host lock state to match client's

BUG=176436
==========

to

==========
When receiving a key event on Linux, set host lock state to match client's

BUG=176436

Review-Url: https://codereview.chromium.org/2844533002
Cr-Commit-Position: refs/heads/master@{#467116}
Committed:
https://chromium.googlesource.com/chromium/src/+/f232398ebba7a9074272ac9c9c5f...
==========

[commit-bot: I haz the power, 2017-04-25 21:22:02]

Committed patchset #1 (id:1) as
https://chromium.googlesource.com/chromium/src/+/f232398ebba7a9074272ac9c9c5f...