Unity on Linux bug makes RETURN keypress get ignored in kOS.

[Dunbaratu]

(This bug was found after some back and forth posts with a user on the forums performing some debug tests for me. I do not have a Linux platform to test this on myself.)

The correct ascii character for the carriage return, or "control-M" or "RETURN KEY" is 0x0d. This means that when padded out into a 16 bit unicode character, it is supposed to be 0x000d. This is not supposed to be OS-dependant. That IS the return character in ascii and unicode cross-platform standards.

But the Linux build of Unity that KSP is using has a bug in regards to this. It is returning a unicode character of 0xff0d for RETURN instead of the correct 0x000d. Unity on Windows returns 0x000d as expected. (I haven't tested on mac).

This bug makes kOS fail to detect the RETURN key properly in the terminal window, thus rendering the entire kOS mod utterly useless to Linux users since without RETURN, you can't execute any command, not even run a program. (That's why I'd classify this as a serious severity bug. It's one very tiny thing that's blocking an entire platform.)

Similar behavior seems to be happening for other control-characters like tab, which should be 0x0008 but is coming out as 0xff08 on Linux. The problem seems to be that Unity on Linux is padding out the keypress's unicode character high byte with 1 bits instead of 0 bits in the case of control characters. (Oddly, the printable ascii characters, like "A", are being padded correctly with zeros.)

Because KSP is unlikely to release a public patch just to update the Unity engine underneath, even if Unity itself fixes the bug we'll still be stuck with it for several months until the next KSP update at least, so we'll need to implement a workaround now if we want to have any Linux users.

(Yes, I know the usual argument about how small a sliver of the marketplace Linux constitutes "so let's not write special code to support it", but lets not forget that the filter "people who are interested in kOS" tends to select in favor of the more technical end of the userbase, making the Linux sliver of the pie a bit larger than it would be in a normal random sampling of users.)

[ddproxy]

I noticed this on my Linux machine but it has not presented a problem yet ( too little time to play = no kos parts in tech tree ).

I'd be able to test patches if you guys get around to working on this.

--edited email stub --

[Dunbaratu]

@ddproxy - I just made an experimental DLL build on my google drive you can try to see if it fixes it. I'm loathe to commit my changes without testing the code, and I can't test it myself (which is why it's not on github yet). If you report that it works, let me know and I'll commit my change and pull request it.

The experimental DLL can be found here: https://drive.google.com/folderview?id=0Bxkeai7oN35fY1cyeXNNTkNnX3c&usp=sharing

[ddproxy]

Fixes it in the Terminal only.

I was looking directly in the TextEditor.cs trying my best (I found MonoDevelop :)

case 36:  // Linux enter
    NewLine();
    break;

But I realize now I was in the wrong place. I should point out that additional issues lie in the Text Editor.

asdw keys pass directly through the editor to manipulate the ship. I figure there are additional keys that are not being caught by the editor.

[Dunbaratu]

Ah, I didn't realize the problem existed in the text editor as well.

By the way, this is going to confuse the heck out of you, the file TextEditor.cs actually has nothing to do with the current Text editor in kOS. In the old days when the Text Editor was inside the Terminal window, there was the text editor class for all terminal manipulations the text editor does, and then a subset of the text editor class was used by the interpreter (for stuff like editing the current command line with backarrow).

When I added the new popup Text Editor, I had to leave the old TextEditor.cs file in place because the interactive prompt interpreter is still a subclass of it even if the fullscreen file text editor is disabled.

The new popup text editor widget is actually controlled by the file KOSTextEditPopup.cs

I wish I could work out what the problem is. What's really annoying is that the text editor widget is processing the WASD keys itself. The kOS code isn't doing a darn thing with that - it's a Unity built-in GUI textarea widget that we're calling out to and it's supposed to be doing all that work itself.

[ddproxy]

Well, that explains why it's looking at keycodes by integer instead of the objects.

It's rather irritating that the Unity text area doesn't catch properly.

[ddproxy]

@Dunbaratu - Mind throwing a snippit of code and method location my way for the terminal fix? I'm messing with Unitys' TextArea a bit but I never caught how to actually fix the terminal's return key.

BTW, the return key is broken across the rest of KSP as well, so I figure it may be caught reported by a number of linux users.

[Dunbaratu]

Hmm. I suppose I could commit the change and upload it just to my fork without making a pull request for it yet. Here: https://github.com/Dunbaratu/KOS-1/compare/Dunbaratu:develop...test-linux-keyboard?expand=1

Please ignore all the diffs in the Docs/ directory - those are bogus diffs because of some files I didn't update on my side from the master. Just look at the diffs in the src/ directory only.

I'm off to bed now so I'll be out of contact until tomorrow. Good luck.

[kellpossible]

I'm pretty sure I've also experienced similar problems with typing values into MechJeb before on linux. What a pain to discover that typing words and text in a text area of mechjeb still affects the underlying game depending on which keys you press! Still haven't gotten around to trying kOS again, but will try out your dll patch when I get the chance.

[pjf]

Huh. I play exclusively under Linux, and don't remember having any problems pressing enter in the console and having things work. I've never seen a kOS editor window, but I just assumed one developed on the mission control mainframe (volume 0, with git and vim) and copied over to the probe cores as appropriate, right?

As for Linux being a small segment, I've seen lots of discussions of people installing ubuntu just so they can play a 64-bit KSP. :)

[pjf]

Mind you, I am running a community patched version of the 0.23.5 binary, so it might be that unwittingly applied a fix from one of the linux threads and didn't realise it.

[erendrake]

@pjf now that @Dunbaratu and i are back in the saddle after 0.24. would you mind linking to the community fix versions so we can get the mainline version back up to speed?

[Dunbaratu]

If anyone with a linux install, and the ability to compile and edit the C# code, is willing to try solving the problem further, please do so. I've sort of reached the end of what I can try myself because of not having my own Linux install to play with. I'm probably going to be getting back into Linux again in a few months but not until I get a new computer which is an expense I'm not in a position to justify at the moment.

As to Linux being a small segment, I was an avid Linux user since about Slackware 1.2, so I do get the frustration with the frequent statement, "there's no reason for our product to support Linux because it's not common", a statement which of course is the very reason Linux is not common, so it's a bit of an unfair situation of a social recursive effect without a base case (i.e. a self-fulfilling prophecy).

I quit a job back in the late '90s at a company over this very issue, as I was getting tired of the decisions from on high to take our product (an inventory control and work allocation system for massive warehouse distribution centers used by companies like UPS and Home Depot) off of flagging proprietary UNIXes like Solaris, HPUX, and AIX, and onto Windows NT, when Linux was right there! as a perfectly easy, very cheap replacement platform to migrate to and still leave most of our code untouched because our code was written for UNIX. I was partly annoyed because I liked Linux, but even more annoyed because it showed that the suits running the company were more willing to believe sales pitches from outside companies than to believe the advice of their own technical expert employees. It was a slap of disrespect in the face of all the software engineers and sysadmin experts who actually designed and created the product the company's existence depended upon.

So yeah, I get it about Linux. It matters, and I like it. I'm just not currently in a position where I can test on it, and won't be for several more months, and the bug reports I'm getting from different people on this are so contradictory that I really need to see with my own eyes what's happening if I want to try to fix it.

That's why I'm saying if any of the people who can run the linux version are willing to donate some developer time to looking at the issue, I'd really, really, appreciate it. If you can run Google Hangouts with Screenshare, we might even be able to arrange times to work as a pair together on it if you don't want to deal with setting up a C# development environment - I could try editing the code to insert diagnostic patches, then have you run them while I watch through Screenshare and we talk about what's happening and cycle back and forth a few times this way until we learn more about what's going on.

[ddproxy]

I completely understand the issues related to Linux adoption, I've left a company recently for similar issues but more along the lines of NOT wanting to spend ANY money on necessary upgrades.

I have not worked in mono, ever til last night. But I have done some C# in the last few years. The very reason I've become involved in kOS and other KSP projects is to have a more stable support 'group' to get back into working with C#.

So, I'm game. I run Ubuntu LXDE (hate Unity) with and without wine available.

I've already gotten my hands dirty playing with the interpreter and text editor (merging the objects to see if I can make it work). As soon as I get time, I'll be taking a look at the Unity text area to hook into the utility parser created to fix the return problem. On Jul 29, 2014 12:13 PM, "Steven Mading" notifications@github.com wrote:

If anyone with a linux install, and the ability to compile and edit the C# code, is willing to try solving the problem further, please do so. I've sort of reached the end of what I can try myself because of not having my own Linux install to play with. I'm probably going to be getting back into Linux again in a few months but not until I get a new computer which is an expense I'm not in a position to justify at the moment.

As to Linux being a small segment, I was an avid Linux user since about Slackware 1.2, so I do get the frustration with the frequent statement, "there's no reason for our product to support Linux because it's not common", a statement which of course is the very reason Linux is not common, so it's a bit of an unfair situation of a social recursive effect without a base case (i.e. a self-fulfilling prophecy).

I quit a job back in the late '90s at a company over this very issue, as I was getting tired of the decisions from on high to take our product (an inventory control and work allocation system for massive warehouse distribution centers used by companies like UPS and Home Depot) off of flagging proprietary UNIXes like Solaris, HPUX, and AIX, and onto Windows NT, when Linux was right there! as a perfectly easy, very cheap replacement platform to migrate to and still leave most of our code untouched because our code was written for UNIX. I was partly annoyed because I liked Linux, but even more annoyed because it showed that the suits running the company were more willing to believe sales pitches from outside companies than to believe the advice of their own technical expert employees. It was a slap of disrespect in the face of all the software engineers and sysadmin experts who actually designed and created the product the company's existence depended upon.

So yeah, I get it about Linux. It matters, and I like it. I'm just not currently in a position where I can test on it, and won't be for several more months, and the bug reports I'm getting from different people on this are so contradictory that I really need to see with my own eyes what's happening if I want to try to fix it.

That's why I'm saying if any of the people who can run the linux version are willing to donate some developer time to looking at the issue, I'd really, really, appreciate it. If you can run Google Hangouts with Screenshare, we might even be able to arrange times to work as a pair together on it if you don't want to deal with setting up a C# development environment - I could try editing the code to insert diagnostic patches, then have you run them while I watch through Screenshare and we talk about what's happening and cycle back and forth a few times this way until we learn more about what's going on.

— Reply to this email directly or view it on GitHub https://github.com/KSP-KOS/KOS/issues/206#issuecomment-50507374.

[Dunbaratu]

I'm glad to hear you're looking into it!

(When you said you "hate Unity" - did you mean the Ubuntu window manager "Unity", or the "Unity" we've been talking about here? This clash of terms made google searching on this problem yesterday a pain, by the way. Normally, google searching for problems in Unity is easy - until you add the word "linux" to the search terms - then all you see are posts about Ubuntu's window manager called "Unity".)

As a piece of advice about the issue with the popup text editor widget - from what people are saying about it I'm leaning toward thinking it's a difference in the "input stacking order" (I don't know what the correct term for it is in Unity). Whenever a GUI event-driven system like Unity gets mouseclicks, keypresses, or other events, it sends them around to all the potential candidate objects that might be interested in responding to them. Each object can either ignore the event, process it and NOT consume it, or process it AND consume it. If it does consume it, that means the search stops and no other objects will get the event. Thus the stacking order of window widgets is supposed to be the same order as the order in which an event is sent to the widgets for processing - try the topmost widget first, then the next widget under it, and so on.

What seems to be happening in the Linux Unity version is that the input stacking order is wrong such that KSP's main flight controls (the "background") are getting "first crack" at the WASD keys and consuming them before the textarea widget is getting to see them. It should be the other way around and the textarea should get to see them first before the flight controls do, which is what's happening on the Windows version.

So that's where I'd suggest you look for the problem - see if there might be some way to fix or override the input stacking order to force the textarea widget to come first in the input event processing.

[ddproxy]

Unity UI for ubuntu. Hate it.

I was going to extend the Unity GUI text area to define a method and listener to keypresses while the text area was 'active'/clicked into. I'm very likely using the wrong terminology for what I really mean, I've been working with MVC Java script way too much lately.

The input stacking would be a much more elegant solution though. Definitely going to look I to that first. On Jul 29, 2014 1:50 PM, "Steven Mading" notifications@github.com wrote:

I'm glad to hear you're looking into it!

(When you said you "hate Unity" - did you mean the Ubuntu window manager "Unity", or the "Unity" we've been talking about here? This clash of terms made google searching on this problem yesterday a pain, by the way. Searching for bugs in Unity works just fine until you add the word "linux" to the search terms. If the term "linux" and the term "unity" appear anywhere in the search terms, you get a flood of links about the window manager Unity instead of the Unity we're talking about. Adding extra terms like "textarea" and "focus" and "keycode" and so on don't help differentiate it, as those are all going to be terms appearing in Unity issues too.)

As a piece of advice about the issue with the popup text editor widget - from what people are saying about it I'm leaning toward thinking it's a difference in the "input stacking order" (I don't know what the correct term for it is in Unity). Whenever a GUI event-driven system like Unity gets mouseclicks, keypresses, or other events, it sends them around to all the potential candidate objects that might be interested in responding to them. Each object can either ignore the event, process it and NOT consume it, or process it AND consume it. If it does consume it, that means the search stops and no other objects will get the event. Thus the stacking order of window widgets is supposed to be the same order as the order in which an event is sent to the widgets for processing - try the topmost widget first, then the next widget under it, and so on.

What seems to be happening in the Linux Unity version is that the input stacking order is wrong such that KSP's main flight controls (the "background") are getting "first crack" at the WASD keys and consuming them before the textarea widget is getting to see them. It should be the other way around and the textarea should get to see them first before the flight controls do, which is what's happening on the Windows version.

So that's where I'd suggest you look for the problem - see if there might be some way to fix or override the input stacking order to force the textarea widget to come first in the input event processing.

— Reply to this email directly or view it on GitHub https://github.com/KSP-KOS/KOS/issues/206#issuecomment-50520863.

[pjf]

@erendrake : Here's the linux compatibility thread which included some binary patches to KSP (not KOS) in post number 5.

[erendrake]

@pjf Thank you

[NoPanShabuShabu]

Just out of curiosity I Googled some questions about this and the only places I could find stuff like this mentioned is in X11's keysym definitions (like keyboard keycodes.) For all the ASCII/Unicode charaters from 0x20 - 0x7e they are the same (these would be all the printable characters in ASCII.)

But the lower characters show this 0xff business: keysym unicode value 0xff08 0x0008 # BackSpace 0xff09 0x0009 # Tab 0xff0a 0x000a # Linefeed 0xff0b 0x000b # Clear 0xff0d 0x000d # Return 0xff13 0x0013 # Pause 0xff14 0x0014 # Scroll_Lock 0xff15 0x0015 # Sys_Req 0xff1b 0x001b # Escape

Also, there are these which I suppose are the keypad, so does this behavior also hold true for these keys? keysym unicode value 0xff80 0x0020 # KP_Space 0xff89 0x0009 # KP_Tab 0xff8d 0x000d # KP_Enter 0xffaa 0x002a # KP_Multiply 0xffab 0x002b # KP_Add 0xffac 0x002c # KP_Separator 0xffad 0x002d # KP_Subtract 0xffae 0x002e # KP_Decimal 0xffaf 0x002f # KP_Divide 0xffb0 0x0030 # KP_0 0xffb1 0x0031 # KP_1 0xffb2 0x0032 # KP_2 0xffb3 0x0033 # KP_3 0xffb4 0x0034 # KP_4 0xffb5 0x0035 # KP_5 0xffb6 0x0036 # KP_6 0xffb7 0x0037 # KP_7 0xffb8 0x0038 # KP_8 0xffb9 0x0039 # KP_9 0xffbd 0x003d # KP_Equal

I'm think that maybe what where seeing returned here isn't the unicode value but the keysym value, which would look the same for the printable English characters.

[Dunbaratu]

The values X11 lists for the keysym are correct. The values X11 lists for the unicode are correct. The error seems to be that it's returning the keysym in a context where it's supposed to be returning the unicode.

The Unity function call being made by kOS is Event.current.character, which the Unity docs claim will return the unicode of the character regardless of the key pressed (in other words, lets say you press keypad '3'. Event.current.character is supposed to return the same thing for keypad 3 as for typewriter key 3 - it doesn't care exactly which key was hit - only what the resulting character is.)

At any rate, the fix I made to my experimental version corrects this (if the unicode is 0xffNN, where NN is anything, then transform it into 0x00NN, because there's no way anyone would have a keyboard that actually types any of the unicode 0xffNN characters. They're very weird and specialized.) The only reason it wasn't made into a pull request is that other linux problems were found with the program editor popup that people had reported as still broken.

I'd prefer it if the text editor popup problems were made into a separate issue, so that this issue can be resolved and fixed independently of the text editor problem.

[NoPanShabuShabu]

That method will work for the under 0x20 ASCII characters, but if it's also returning the keysym values for those keypad entries too, those would get changed to something wrong. So, does that happen now? And if it does, do you want kOS to handle those properly? Just stripping out the 0xff from the front will make some of them return some other "high ASCII" character. Would it not be better to just re-map a selection of the ones you know you want to capture?

[Dunbaratu]

What would be better would be for Unity to fix their damn system!

It looks as if any solution that uses Event.current.character simply cannot be correct no matter what. If you map too many characters under the assumption that they're wrong on one system, you start getting the problem that it makes right characters to wrong ones on other systems.

It may be that the only solution that works is to utterly ignore Event.current.character since Unity refuses to implement it correctly, and instead always look at the keysym (regardless of whether it's on Linux or not) and map it ourselves.

[NoPanShabuShabu]

And until Unity fixes their system, you're going to have to work around it, and since you are working with Unity, you will have to use it's framework. In my opinion, the solution should only re-map keys which you know are coming back wrong and which are ones that you need to handle. That's all I'm trying to say here.

[Dunbaratu]

The problem with that is that I can't know they're coming back wrong unless I have the environment in question to test on. (And I'd prefer to make the solution as universal as possible. If the keysym is right across all platforms, and the unicode is wrong on some platforms, then it makes sense to use the keysym instead of writing special case exceptions into the code.)

[NoPanShabuShabu]

I understand about the testing trouble and how that would be frustrating, but I think you should think along the lines of "What does kOS need to function properly?" and "What would be the possible undesirable side effects?"

Second question first: Some unicode characters in the 0xffXX range will be incorrectly thought to be something else. Well, those can't be displayed or used by kOS in any way at all since they aren't part of the scripting language. In fact, just changing to 0x00XX shouldn't have any impact on a kOS user at all. The only argument against that is that it doesn't handle the keypad characters properly.

So, let's think about what we'd need to cover.

Let's start with those first 8 which are under 0x20: I doubt you'd need such things as Sys_Req or Scroll_lock for example, so you could leave those alone. But, since the likelihood of those unicode values actually legitimately being returned and being usable by kOS, is infinitesimal, you could include those 8, or even all of 0x00 to 0x1f.

Now consider the Keypad keys: It turns out that these are in fact not being returned correctly. I tried this out on an Ubuntu install I have, x64. I couldn't see what values it was actually returning, but could definitely see that it was just producing what looked like spaces, so I'm pretty sure it was returning those keysym values just like the Return key. So, even though I've never seen a keypad with a Space or Tab, include those 20.

So, you could do something as simple as 28 (or fewer if you decide you would never want to use something like Scroll_lock) case statements where you precisely control the mapping like: case 0xff0d return 0x000d, or even return KeyCode.Return.

Or you could do it as a few ranges like: if between 0xff08 and 0xff1b subtract 0xff00 if between 0xff89 and 0xffbd subtract 0xff80 if equals 0xff80 subtract 0xff60, or return 0x0020 or Space.

The case statements only change keys you want to, and you can choose exactly what you want to return. The ranges are simpler, but do wind up including some other highly unlikely characters.

I don't think there would be any measurable effect on Windows, on Linux it should (hopefully) make it work at least the same as Windows, and who knows about Mac (at worst it should be the same as Windows, at best it might fix something.)

[Dunbaratu]

Well, if you could implement a lookup table like so based on your being able to test on linux where I can't, then I could include it in the fix. If you provide me something formatted like so:

Unicode               |  Correct Unicode
That Unity returns  |  It should be
on Linux            |  returning
====================|=====================
0xff00              |  0x0000
0xff01              |  0x0001
0xff02              |  0x0002
0xff03              |  0x0003
0xff04              |  0x0004
0xff05              |  0x0005
0xff06              |  0x0006
0xff07              |  0x0007
0xff08              |  0x0008
0xff09              |  0x0009
0xff0a              |  0x000a
0xff0b              |  0x000b
0xff0c              |  0x000c
0xff0d              |  0x000d
0xff0e              |  0x000e
0xff0f              |  0x000f
0xff10              |  0x0010
0xff11              |  0x0011
.... etc ....

then I could just use that and do a dumb lookup replacement using the table. That way there's no logic, no thinking - just a crude table lookup.

Note, you don't have to mention every unicode char - just the ones that come out wrong. If Unity is giving the right unicode (i.e. like it does for the alphabet characters), then leave that out of the table. The algorithm I'd use is "if it's in the table, map it, else leave it alone as is."

As long as there's no cases where the mapping causes something to break on one system then I can just run it universally. (What I dislike, and want to avoid, is case statements like "if we are on Linux do this, else if we are on Windows do this, else if we are on Mac do this...")

[Dunbaratu]

Also, I'm going to split off the other issue that a user discovered, that the texteditor widget on linux doesn't seem to be processing the input in the right stacking order (so the background flight controls see "W,A,S,D" before kOS does, even when the kOS terminal is focused), and make it a separate issue to be solved independantly. Otherwise this keymapping issue wouldn't be close-able on its own.

[NoPanShabuShabu]

This should be the maximum you need, and even if some of them aren't necessary (I think backspace actually worked by some miracle) changing them should have zero impact on other OSes:

Incorrect	Correct	Description
0xff08	0x0008	BackSpace
0xff09	0x0009	Tab
0xff0a	0x000a	Linefeed
0xff0b	0x000b	Clear
0xff0d	0x000d	Return
0xff13	0x0013	Pause
0xff14	0x0014	ScrollLock
0xff15	0x0015	SysReq
0xff1b	0x001b	Escape
0xff80	0x0020	KeypadSpace
0xff89	0x0009	KeypadTab
0xff8d	0x000d	KeypadEnter
0xffaa	0x002a	KeypadMultiply
0xffab	0x002b	KeypadAdd
0xffac	0x002c	KeypadSeparator
0xffad	0x002d	KeypadSubtract
0xffae	0x002e	KeypadDecimal
0xffaf	0x002f	KeypadDivide
0xffb0	0x0030	Keypad0
0xffb1	0x0031	Keypad1
0xffb2	0x0032	Keypad2
0xffb3	0x0033	Keypad3
0xffb4	0x0034	Keypad4
0xffb5	0x0035	Keypad5
0xffb6	0x0036	Keypad6
0xffb7	0x0037	Keypad7
0xffb8	0x0038	Keypad8
0xffb9	0x0039	Keypad9
0xffbd	0x003d	KeypadEqual

[NoPanShabuShabu]

And now I'll describe some other weirdness.

I hacked in a remap like we're talking about just to see if this will work:
I created a remap function "char FixChar(Char ch)" for those keys in TermWindow.cs. In ProcessKeyStrokes() function I made a couple of changes: added ".. && Event.current.character != 0xff0d && Event.current.character != 0xff0a .." in the first part of the if..else if statement where it checks for return or linefeed. changed "Type(Event.current.character);" to "Type(FixChar(Event.current.character));"

Keep in mind this is not how I think it should be implemented, just a hacky test. Also it wouldn't be in a good position to help out the TextEditor.

So, Build and test:
Windows x32 & x64: All OK. Linux x64: All OK, also keypad works now. BUT! Now ctrl-c doesn't work? Nor ctrl-shift-x...

Which didn't make any sense since I didn't do anything to the second part of that if..else if. Then I thought "Why 'else if'?" and "How did that ever work in the first place?" The first part will run if the char is not 0, 13, or 10 (plus 0xff0d and 0xff0a now). The second part is where it calls Keydown which appears to be where it checks for ctrl-c, ctrl-shift-x and other special keys. Other than when that function handles the Return key, logically it shouldn't ever be called, should it?

Removing the "else" makes everything seem to work like normal in Windows and Linux. I just don't understand how it worked with the "else" in the first place, unless those special keys are also being handled somewhere else.

Well it's food for thought, and something I'll be sure to check when you implement your remapping.

[NoPanShabuShabu]

The issue I talked about earlier is because of this:

When you press a key on Windows, Unity sends 2 events (I suppose to OnGUI?).
The first gives the keycode: Event.current.keyCode has a value and Event.current.character is 0 The second gives the character: Event.current.keyCode is 0 and Event.current.character has a value. Some keys like Backspace, Home, and End only have one: Event.current.keyCode has a value character is 0.

On Linux, there is only one event: Event.current.keyCode has a value and Event.current.character has a value. The keys like Backspace, Home, etc. the same as above with on event with the character being 0.

So, on Windows it passes through ProcessKeystrokes 2 times for most keys, and on Linux only 1 time.

And one more thing of little consequence, but to keep in mind: on Windows when you press Enter, the KeyCode is 13, and the Character is 10. On Linux, KeyCode is 13 and Character is 13 (actually 0xff0d).

[Dunbaratu]

For crying out Loud! The whole POINT of Unity, and in fact the reason it's called Unity, was to be a platform-independant game engine. But they can't even get platform consistency with this basic feature of reading the keyboard, which has nothing to do with actual OS implemenation, but with how Unity chooses to package the information and pass it to software.

Sigh. Alright. Fine.

The problem is that if I try to react to either the character or the keycode, and make both work, I end up getting TWO keypresses per keypress on WIndows, because they come through as different events. Whereas if I react only to one or only the other, then I miss some of the events that are not generated (like Backspace not sending a unicode character).

[NoPanShabuShabu]

I hear ya man.

[qsantos]

Linux 64 KSP player here. I tested the result of some key inputs:

Key	Character
Backspace	0x0
Tab	0xff09
Return	0xff0d
Pause	0xff13
Escape	0xff1b
KeypadEnter	0xff8d
KeypadMultiply	0xffaa
KeypadAdd	0xffab
KeypadSubstract	0xffad
KeypadDecimal	0x2e (period)
KeypadDivide	0xffaf
Keypad0	0xffb0
Keypad1	0xffb1
Keypad2	0xffb2
Keypad3	0xffb3
Keypad4	0xffb4
Keypad5	0xffb5
Keypad6	0xffb6 most GUIs provides two values for key events
Keypad7	0xffb7
Keypad8	0xffb8
Keypad9	0xffb9

The only key that is not accurately detected (in the keyCode) is the keypad's period. The others, do have high values though. I think a simple 0x007f mask should retrieve the character value if you really need it.

[Dunbaratu]

This was implemented but I don't know if it's fixed. I'll reopen this if the complaint resurfaces.

[Xasin]

Hey! I've recently tested out kOS on my KSP, and it seems like this bug is still (or again) affecting linux users. (At least I would assume this, as I am running 64-Bit linux and KSP, 1.0.2, kOS directly downloaded via CKAN.)

Is there any way I could fix this myself?