Debugger CLI is unusable when current keymap has no latin characters

[hitech]

When globally switching the system keymap to a language other than English (e.g. Russian or Hebrew), and the system crashes into KDL, keyboard doesn't print any characters. Probably because the keys send scancodes of a language which is not supported in KDL. Slashes, spaces etc. work as usual.

The KDL is totally useless in this case. The only way to continue is to literally pull the plug.

Possible solution: replace the current keymap with US_International system keymap upon entering into KDL regardless of what was chosen before.

hrev54106, x86-64.

[X512]

Many keymaps are compatible with English language and don't need replacing. Some of then have different key position of non alphanumeric characters like "_" character in Japanese layout.

[waddlesplash]

The KDL keymap is independent of the input_server keymap. Are you sure it always works when you do not change the keymap?

If you have a USB keyboard, note that you have to manually enter KDL once via the keyboard and then exit back to normal operation in order for it to function inside KDL.

[pulkomandy]

If you have a USB keyboard, note that you have to manually enter KDL once via the keyboard and then exit back to normal operation in order for it to function inside KDL.

That's not always true. My USB keyboard works fine in KDL here without doing this. I think it's only for xHCI or something like that? And it seems strange to me that this is needed anyway. Why can't the USB stack always prepare for this?

[hitech]

Whenever I enter the KDL unvoluntarily with US_International as my chosen language, my USB keyboard works well there.

[waddlesplash]

XHCI behaves no differently than EHCI with respect to keyboards in KDL; as far as I can see, it is the usb_hid driver that has to set up the variables for things to work in KDL. Part of it has to do with picking the right keyboard in case you have more than one, I think?

I do not know very much about usb_hid, but I'd guess that is where the problem lies in both instances.

[hitech]

The issue still exists in Beta2. WebPositive Just crashed me into KDL, the keymap I had there was Russian. I verified it by typing punctuation characters that are located on different keys in US_International and Russian keymaps; Shift+2 produced quotemark (suits Russian keymap) and not "@" sign (as in US_International). Shift+7 produced question mark "?" instead of the ampersand "&".

In short, the WebPositive was in Russian, it crashed into KDL, and the KDL still had Russian keymap, rendering the KDL prompt unusable.

I just thought that I'm using custom (not system-provided) Russian and US_International keymaps. Does it matter?

[waddlesplash]

WebPositive Just crashed me into KDL

Uh, are you really sure it was a KDL then? More likely it was an app_server crash, which also has the familiar white-screen debug console, but is really a Debugger CLI shell. This goes through input_server, I believe, which would make a lot more sense, as KDL has its own keymap independent of input_server as I said above.

[hitech]

Well, as I see, yes, it may be App Server debugger. Since I can't type anything in this shell, I can neither confirm nor deny.

Even though the input passes through the Input Server, the KeymapSwitcher does not replace the keymap, - that means its filter either doesn't work in this case or the keymap is not replaced.

[pulkomandy]

You don't need to type qnything, kernel debugging lqnd very clearly states "Welcome to the kernel debugging land!" at the top of the screen and the prompt is "kdebug>". If you see something else it's not KDL.

Please attach a screenshot of what you get, it will save some misunderstanding.