Bug 177889

See also:
https://bugs.kde.org/show_bug.cgi?id=164274

*** Bug 262053 has been marked as a duplicate of this bug. ***

Copied from bug #262053:
Product:	systemsettings
Component:	kcm_keyboard

I have two keyboards, one with language A printed on it, the other with
language B on it. I would like to set the first to layout A and the latter to
layout B.
X.Org / XInput seems to support that, looking at xorg.conf examples.

P.S: The bugtracker component "kcm_keyboard" has the help text "Keyboard
configuration module (repeat speed, NumLock, click volume, **keyboard
layouts**)" (emphasis by me), while kcm_keyboard_layout ("Keyboard Layouts
configuration module") also exists. This is confusing.

*** This bug has been confirmed by popular vote. ***

No movement since 2013.

This seems to be a simple addition to the "KDE Keyboard Control Module". For that matter, "Mouse", "KDE Joystick Control Module", and "Touchpad KCM" as well. Odd that they have wildly different documented names in their help.

I propose a dropdown or tab listing the related objects in each module as presented in /dev/input/ directory (or /proc/bus/input/devices file)...or however KDE is getting and coordinating the device names and types.

The biggest problem is restoring devices of same type. They may not be guaranteed to have the same prior event #, so order may not be preserved. Some solutions:
1. Bluetooth devices can have unique names.
2. Serial numbers? I don't know if every device has or can report a serial number.

The /proc/bus/input/devices file list these entries which might help to uniquely identify devices:
1. Name
2. Phys
3. Sysfs
4. Uniq
Sometimes the Phys and Uniq look like they are using MAC, other times not or not used at all. Phys always has something.

However, for my systems, I always see at least two keyboards (when I really only have one): one named by manufacturer AND a second "AT Translated Set 2 keyboard". What is KDE actually using as the keyboard device?  Is the "AT Translated Set 2 keyboard" the default?

Keven, if you're on a laptop, that must be the built-in keyboard, connected via PS2.

That being said, as a first step which would leave very little from this issue, it would be sufficient to use a model identifier like a USB id, in particular if different variants of the same keyboard have different USB id-s. Unfortunately that doesn't seem to be the case for my Microsoft Natural Ergonomics 4000:
          bCountryCode            0 Not supported

This also has security implications. Plugging in a dongle can p0wn a system. A dongle can appear as a usb thumb drive and a HID device.

I propose that a second keyboard should start with a very limited input method(maybe two keys work), and a captcha should be completed to enable the keyboard.

This requires some low level digging, maybe down to  QT or xkb or kernel hid support, but this is highly related to that.

I am very interested in helping further this. if anybody can tell me what libraries to start looking at, I'll research.

I fail to see how that relates to the issue tracked here.

I believe the security concerns are out of scope.  It is natural for a "docked" laptop to have two keyboards.  Inline keyboard taps are generally more of a security concern and would likely show as a single device anyway.  Also, hacker devices could masquerade as any device.  So, IMHO, this is chasing a lost cause.

Security depends on the foundation of the system being good.

Low level is the place to be able to choose to trust or not trust an input device.
A captcha to verify that the keyboard isn't just a script inputter is a great idea.    This feature may be off by default, but truely, any device being added needs to be vetted.   So maybe that portion is higher level than this particular feature, but this feature is the place to have the interface to deal with it...  any new keyboard plugged in should be limited, and the interface that deals with removing the limit on it is part of the keyboard configuration.

This is still a concern in 6.2.5 / git-master
Only one keyboard can be configured, even in the original described scenario of a laptop with a built-in keyboard and an external USB keyboard

*** Bug 384702 has been marked as a duplicate of this bug. ***

I'm very interested in a per-keyboard configuration of a layout as well. The following real life example is actually the one situation I'm in right now: a laptop with 1) an internal keyboard, which is German (de-latin1). This is also the system configuration. Additionally I have 2) a USB keyboard connected with a US English layout that I would like to function as such, while the first one would remain German. 3) an additional external USB keyboard with either German or US layout, but with Korean stickers on it to function in Korean. For the 3rd one I'm currently using Fcitx5. I also tried IBus, but this didn't work well.

I use this Korean keyboard on Debian Linux and Microsoft Windows 11. Here is some more information for Arch Linux: https://wiki.archlinux.org/title/Localization/Korean. On Debian Linux, with Fcitx5, I can use a German keyboard and put Korean keys on it, which means that Shift + 1-0 remains in the German layout, and also the brackets and punctuation marks. Microsoft Windows always automatically falls to a US English basic layout when Korean is selected, with all the punctuation marks and the like switching too. This is unfortunate when the basic keyboard layout is German.

The point being that it should be possible, for all inputs (also mice), to have a layout selected per device. I.e. I should be able to use one keyboard in ISO German, another in ANSI English and so forth. I also should be able to use one mouse in right-handed configuration and another in left-handed configuration.

I'm running KDE Plasma on Wayland. I know, there are differences when it is run on X11.

Off topic: I get where this security thing is coming from. E.g. on macOS, when a new (USB) keyboard is connected, a window is presented asking about it's layout and it will only be usable, once this layout is selected. This could add to additional security, but I don't know if it has something to do with different layouts or not. I don't know if macOS allows them... Again, the point being that KDE Plasma should.

I haven't tried this (not using X11 right now), but it seems that it could work with X11, as mentioned here: https://unix.stackexchange.com/questions/739471/xorg-2-keyboards-with-different-layouts/752082, on the other hand it doesn't seek to always work, as mentioned here: https://unix.stackexchange.com/questions/762900/using-different-layout-for-each-keyboard.

I think that KDE Plasma should have a working configuration of its own, including languages like Korean. (While I think, I've seen Korean in KDE Settings, I think I remember that this wasn't satisfactory, and the solution was to use Fcitx5 instead.)