You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@guacamole.apache.org by Greg Trasuk <tr...@stratuscom.com> on 2017/11/23 21:46:41 UTC
External keyboard with iPad
Hi all:
I’m trying to use Guacamole with an iOS device (I’ve tried both iPad and iPhone devices) with an IOGear GKB632B keyboard (https://www.iogear.com/product/GKB632B/)
The problem is that Guac doesn’t seem to understand the keyboard mapping, particularly for the escape key (and I would guess other keys as well, but all I’m trying to do is use ‘vi’). On this keyboard When used through Safari on the iOS devices, the escape key generates a ‘U’ character. It works when connected to a MacBook.
Any ideas?
Cheers,
Greg Trasuk
Re: External keyboard with iPad
Posted by Greg Trasuk <tr...@stratuscom.com>.
> On Nov 28, 2017, at 2:34 PM, Mike Jumper <mi...@guac-dev.org> wrote:
>
> On Tue, Nov 28, 2017 at 5:46 AM, Greg Trasuk <tr...@trasuk.com> wrote:
>> ...
>>>
>>> https://github.com/mike-jumper/incubator-guacamole-client/tree/fix-ios-external-kb
>>>
>>> Mind giving that a go?
>>
>> I’m traveling without that hardware, so it’ll be Friday or Saturday before I can try it out, but I certainly will give it a go.
>>
>> Probably a dumb question, but there’s nothing that would prevent me having a second client (your test branch) running in the same Tomcat instance as the stable release, is there?
>>
>
> There is, unfortunately. You can't run multiple copies of Guacamole
> under the same Tomcat instance - they would end up sharing the same
> configuration and extensions. For copies of Guacamole which are
> identical versions, this would work but would be strange (why not just
> have one instance). For copies of Guacamole which are different
> versions, the extensions and database schema from one will be
> incompatible with the other. There are sanity checks during startup
> which prevent Guacamole from trying to use extensions from other
> versions, but those checks will erroneously pass for builds from git
> as the version number has not yet been bumped.
>
> You'll need to use a different Tomcat instance, ideally running as a
> different user to avoid having to mess with GUACAMOLE_HOME.
>
> - Mike
So.. I’m guessing that I would need a different ‘guacd’ as well. OK, not a production instance so I’ll just switch the whole thing to the experimental version.
Cheers,
Greg Trasuk
Re: External keyboard with iPad
Posted by Mike Jumper <mi...@guac-dev.org>.
On Tue, Nov 28, 2017 at 5:46 AM, Greg Trasuk <tr...@trasuk.com> wrote:
>...
>>
>> https://github.com/mike-jumper/incubator-guacamole-client/tree/fix-ios-external-kb
>>
>> Mind giving that a go?
>
> I’m traveling without that hardware, so it’ll be Friday or Saturday before I can try it out, but I certainly will give it a go.
>
> Probably a dumb question, but there’s nothing that would prevent me having a second client (your test branch) running in the same Tomcat instance as the stable release, is there?
>
There is, unfortunately. You can't run multiple copies of Guacamole
under the same Tomcat instance - they would end up sharing the same
configuration and extensions. For copies of Guacamole which are
identical versions, this would work but would be strange (why not just
have one instance). For copies of Guacamole which are different
versions, the extensions and database schema from one will be
incompatible with the other. There are sanity checks during startup
which prevent Guacamole from trying to use extensions from other
versions, but those checks will erroneously pass for builds from git
as the version number has not yet been bumped.
You'll need to use a different Tomcat instance, ideally running as a
different user to avoid having to mess with GUACAMOLE_HOME.
- Mike
Re: External keyboard with iPad
Posted by Greg Trasuk <tr...@trasuk.com>.
> On Nov 28, 2017, at 3:27 AM, Mike Jumper <mi...@guac-dev.org> wrote:
>
> On Mon, Nov 27, 2017 at 4:23 PM, Jeff Herring <je...@sldsi.com> wrote:
>>
>> Might be a bit old:
>>
>> https://developer.apple.com/documentation/uikit/uikeycommand/input_strings_for_special_keys
>>
>
> Thanks, Jeff!
>
> Greg, I've opened GUACAMOLE-447 [1] for this and tried mapping these
> constants to their corresponding X11 keysyms within Guacamole's
> keyboard handling. The changes can be found on the
> "fix-ios-external-kb" topic branch of my GitHub fork:
>
> https://github.com/mike-jumper/incubator-guacamole-client/tree/fix-ios-external-kb
>
> Mind giving that a go?
I’m traveling without that hardware, so it’ll be Friday or Saturday before I can try it out, but I certainly will give it a go.
Probably a dumb question, but there’s nothing that would prevent me having a second client (your test branch) running in the same Tomcat instance as the stable release, is there?
Cheers,
Greg Trasuk
>
> - Mike
>
> [1] https://issues.apache.org/jira/browse/GUACAMOLE-447
Re: External keyboard with iPad
Posted by Mike Jumper <mi...@guac-dev.org>.
On Mon, Nov 27, 2017 at 4:23 PM, Jeff Herring <je...@sldsi.com> wrote:
>
> Might be a bit old:
>
> https://developer.apple.com/documentation/uikit/uikeycommand/input_strings_for_special_keys
>
Thanks, Jeff!
Greg, I've opened GUACAMOLE-447 [1] for this and tried mapping these
constants to their corresponding X11 keysyms within Guacamole's
keyboard handling. The changes can be found on the
"fix-ios-external-kb" topic branch of my GitHub fork:
https://github.com/mike-jumper/incubator-guacamole-client/tree/fix-ios-external-kb
Mind giving that a go?
- Mike
[1] https://issues.apache.org/jira/browse/GUACAMOLE-447
Re: External keyboard with iPad
Posted by Jeff Herring <je...@sldsi.com>.
Might be a bit old:
https://developer.apple.com/documentation/uikit/uikeycommand/input_strings_for_special_keys
--
Jeffry V. Herring
Seacoast Laboratory Data Systems, Inc.
From: Mike Jumper <mi...@guac-dev.org>
Reply-To: <us...@guacamole.apache.org>
Date: Monday, November 27, 2017 at 1:56 PM
To: <us...@guacamole.apache.org>
Subject: Re: External keyboard with iPad
On Sat, Nov 25, 2017 at 10:48 PM, Greg Trasuk <tr...@stratuscom.com> wrote:
Hi Mike:
Thanks for the reply. Here’s the result from the keypress tester:
keydown e.keyCode=0 e.which=0 e.keyIdentifier=Unidentified e.key=UIKeyInputEscape e.altKey=false e.ctrlKey=false e.altGraphKey=false e.metaKey=false e.shiftKey=false e.location=0 e.keyLocation=0
keypress e.keyCode=85 e.which=85 e.keyIdentifier= e.key=UIKeyInputEscape e.altKey=false e.ctrlKey=false e.altGraphKey=false e.metaKey=false e.shiftKey=false e.location=0 e.keyLocation=0
keyup e.keyCode=0 e.which=0 e.keyIdentifier=Unidentified e.key=UIKeyInputEscape e.altKey=false
So… looks kind of funny. The keycode reported is ’85’ which is the U character, but the key that’s reported is ‘UIKeyInputEscape’, which is clearly not ‘U’, and also not ESC (27). Googling ‘UIKeyInputEscape’ suggests that this is UIKit’s name for the escape key, but the keycode is wrong.
It's unfortunately fairly common for at least one or two JavaScript key events and their properties to be completely incorrect. Guacamole's keyboard handling is actually one of the more complicated parts of the JavaScript side of the stack. We employ retrospective inspection of key events, looking over either or both of the keydown and keypress events depending on how reliable the associated properties are given other factors:
https://github.com/apache/incubator-guacamole-client/blob/649fd8c036861014a6064f4af3e05f309cd92973/guacamole-common-js/src/main/webapp/modules/Keyboard.js#L934-L938
In this case, iOS Safari shouldn't actually be sending a keypress event, as that event is supposed to only be sent for keys which would result in a printable character. It is this event which is resulting in Guacamole interpreting the key as a "U":
https://github.com/apache/incubator-guacamole-client/blob/649fd8c036861014a6064f4af3e05f309cd92973/guacamole-common-js/src/main/webapp/modules/Keyboard.js#L940-L944
Does Guacamole have some idea of an editable keymap? And if it did, would it be looking at the ‘key’ value or the ‘keycode’ value?
The client side of things is meant to be independent of keyboard layout, so not exactly, but it does have a mapping of known key identifiers and known-accurate key codes (for the cases where a key code is always tied to a specific key). In those cases, it would ignore the keypress event and rely solely on keydown:
https://github.com/apache/incubator-guacamole-client/blob/649fd8c036861014a6064f4af3e05f309cd92973/guacamole-common-js/src/main/webapp/modules/Keyboard.js#L381-L506
https://github.com/apache/incubator-guacamole-client/blob/649fd8c036861014a6064f4af3e05f309cd92973/guacamole-common-js/src/main/webapp/modules/Keyboard.js#L174-L181
Though the "UIKeyInputEscape" identifier is non-standard, adding it to the above list would solve the issue. Do you perhaps know of where a full list of these UIKeyInput* names could be found? We could add them all in one fell swoop to fix this Safari quirk going forward.
- Mike
Re: External keyboard with iPad
Posted by Mike Jumper <mi...@guac-dev.org>.
On Sat, Nov 25, 2017 at 10:48 PM, Greg Trasuk <tr...@stratuscom.com>
wrote:
> Hi Mike:
>
> Thanks for the reply. Here’s the result from the keypress tester:
>
> keydown e.keyCode=0 e.which=0 e.keyIdentifier=Unidentified
> e.key=UIKeyInputEscape e.altKey=false e.ctrlKey=false
> e.altGraphKey=false e.metaKey=false e.shiftKey=false
> e.location=0 e.keyLocation=0
> keypress e.keyCode=85 e.which=85 e.keyIdentifier=
> e.key=UIKeyInputEscape e.altKey=false e.ctrlKey=false
> e.altGraphKey=false e.metaKey=false e.shiftKey=false
> e.location=0 e.keyLocation=0
> keyup e.keyCode=0 e.which=0 e.keyIdentifier=Unidentified
> e.key=UIKeyInputEscape e.altKey=false
>
> So… looks kind of funny. The keycode reported is ’85’ which is the U
> character, but the key that’s reported is ‘UIKeyInputEscape’, which is
> clearly not ‘U’, and also not ESC (27). Googling ‘UIKeyInputEscape’
> suggests that this is UIKit’s name for the escape key, but the keycode is
> wrong.
>
>
It's unfortunately fairly common for at least one or two JavaScript key
events and their properties to be completely incorrect. Guacamole's
keyboard handling is actually one of the more complicated parts of the
JavaScript side of the stack. We employ retrospective inspection of key
events, looking over either or both of the keydown and keypress events
depending on how reliable the associated properties are given other factors:
https://github.com/apache/incubator-guacamole-client/blob/649fd8c036861014a6064f4af3e05f309cd92973/guacamole-common-js/src/main/webapp/modules/Keyboard.js#L934-L938
In this case, iOS Safari shouldn't actually be sending a keypress event, as
that event is supposed to only be sent for keys which would result in a
printable character. It is this event which is resulting in Guacamole
interpreting the key as a "U":
https://github.com/apache/incubator-guacamole-client/blob/649fd8c036861014a6064f4af3e05f309cd92973/guacamole-common-js/src/main/webapp/modules/Keyboard.js#L940-L944
Does Guacamole have some idea of an editable keymap? And if it did, would
> it be looking at the ‘key’ value or the ‘keycode’ value?
>
>
The client side of things is meant to be independent of keyboard layout, so
not exactly, but it does have a mapping of known key identifiers and
known-accurate key codes (for the cases where a key code is always tied to
a specific key). In those cases, it would ignore the keypress event and
rely solely on keydown:
https://github.com/apache/incubator-guacamole-client/blob/649fd8c036861014a6064f4af3e05f309cd92973/guacamole-common-js/src/main/webapp/modules/Keyboard.js#L381-L506
https://github.com/apache/incubator-guacamole-client/blob/649fd8c036861014a6064f4af3e05f309cd92973/guacamole-common-js/src/main/webapp/modules/Keyboard.js#L174-L181
Though the "UIKeyInputEscape" identifier is non-standard, adding it to the
above list would solve the issue. Do you perhaps know of where a full list
of these UIKeyInput* names could be found? We could add them all in one
fell swoop to fix this Safari quirk going forward.
- Mike
Re: External keyboard with iPad
Posted by Greg Trasuk <tr...@stratuscom.com>.
Hi Mike:
Thanks for the reply. Here’s the result from the keypress tester:
keydown e.keyCode=0 e.which=0 e.keyIdentifier=Unidentified e.key=UIKeyInputEscape e.altKey=false e.ctrlKey=false e.altGraphKey=false e.metaKey=false e.shiftKey=false e.location=0 e.keyLocation=0
keypress e.keyCode=85 e.which=85 e.keyIdentifier= e.key=UIKeyInputEscape e.altKey=false e.ctrlKey=false e.altGraphKey=false e.metaKey=false e.shiftKey=false e.location=0 e.keyLocation=0
keyup e.keyCode=0 e.which=0 e.keyIdentifier=Unidentified e.key=UIKeyInputEscape e.altKey=false
So… looks kind of funny. The keycode reported is ’85’ which is the U character, but the key that’s reported is ‘UIKeyInputEscape’, which is clearly not ‘U’, and also not ESC (27). Googling ‘UIKeyInputEscape’ suggests that this is UIKit’s name for the escape key, but the keycode is wrong.
Does Guacamole have some idea of an editable keymap? And if it did, would it be looking at the ‘key’ value or the ‘keycode’ value?
Cheers,
Greg Trasuk
> On Nov 24, 2017, at 1:58 AM, Mike Jumper <mi...@guac-dev.org> wrote:
>
> On Thu, Nov 23, 2017 at 10:56 PM, Mike Jumper <mi...@guac-dev.org> wrote:
>> On Thu, Nov 23, 2017 at 1:46 PM, Greg Trasuk <tr...@stratuscom.com> wrote:
>>> Hi all:
>>>
>>> I’m trying to use Guacamole with an iOS device (I’ve tried both iPad and iPhone devices) with an IOGear GKB632B keyboard (https://www.iogear.com/product/GKB632B/)
>>>
>>> The problem is that Guac doesn’t seem to understand the keyboard mapping, particularly for the escape key (and I would guess other keys as well, but all I’m trying to do is use ‘vi’). On this keyboard When used through Safari on the iOS devices, the escape key generates a ‘U’ character. It works when connected to a MacBook.
>>>
>>> Any ideas?
>>>
>>
>> It's possible that iOS Safari is not actually generating JavaScript
>> key events for the keyboard at all. I've seen this in the past with
>> bluetooth keyboards on iOS.
>>
>> What do you see when you try using that keyboard on iOS with the
>> generic JavaScript key event tester at
>> http://guacamole.apache.org/pub/tests/key-event-test.html ? (Please
>> test both with and without the input field focused).
>>
>
> Errr ... never mind on not generating events - clearly, if a key is
> being typed as a result, even if incorrect, some sort of event is
> making it through.
>
> The JavaScript key event tester may reveal what's actually inside
> those events, and why Guacamole thinks you're typing a "U".
>
> - Mike
Re: External keyboard with iPad
Posted by Mike Jumper <mi...@guac-dev.org>.
On Thu, Nov 23, 2017 at 10:56 PM, Mike Jumper <mi...@guac-dev.org> wrote:
> On Thu, Nov 23, 2017 at 1:46 PM, Greg Trasuk <tr...@stratuscom.com> wrote:
>> Hi all:
>>
>> I’m trying to use Guacamole with an iOS device (I’ve tried both iPad and iPhone devices) with an IOGear GKB632B keyboard (https://www.iogear.com/product/GKB632B/)
>>
>> The problem is that Guac doesn’t seem to understand the keyboard mapping, particularly for the escape key (and I would guess other keys as well, but all I’m trying to do is use ‘vi’). On this keyboard When used through Safari on the iOS devices, the escape key generates a ‘U’ character. It works when connected to a MacBook.
>>
>> Any ideas?
>>
>
> It's possible that iOS Safari is not actually generating JavaScript
> key events for the keyboard at all. I've seen this in the past with
> bluetooth keyboards on iOS.
>
> What do you see when you try using that keyboard on iOS with the
> generic JavaScript key event tester at
> http://guacamole.apache.org/pub/tests/key-event-test.html ? (Please
> test both with and without the input field focused).
>
Errr ... never mind on not generating events - clearly, if a key is
being typed as a result, even if incorrect, some sort of event is
making it through.
The JavaScript key event tester may reveal what's actually inside
those events, and why Guacamole thinks you're typing a "U".
- Mike
Re: External keyboard with iPad
Posted by Mike Jumper <mi...@guac-dev.org>.
On Thu, Nov 23, 2017 at 1:46 PM, Greg Trasuk <tr...@stratuscom.com> wrote:
> Hi all:
>
> I’m trying to use Guacamole with an iOS device (I’ve tried both iPad and iPhone devices) with an IOGear GKB632B keyboard (https://www.iogear.com/product/GKB632B/)
>
> The problem is that Guac doesn’t seem to understand the keyboard mapping, particularly for the escape key (and I would guess other keys as well, but all I’m trying to do is use ‘vi’). On this keyboard When used through Safari on the iOS devices, the escape key generates a ‘U’ character. It works when connected to a MacBook.
>
> Any ideas?
>
It's possible that iOS Safari is not actually generating JavaScript
key events for the keyboard at all. I've seen this in the past with
bluetooth keyboards on iOS.
What do you see when you try using that keyboard on iOS with the
generic JavaScript key event tester at
http://guacamole.apache.org/pub/tests/key-event-test.html ? (Please
test both with and without the input field focused).
- Mike