Tom Scott talks about the general concept of a hack (or a "bodge" as he calls it) and how he learned to coble stuff together, and then goes to explain how he bodged the emoji keyboard into a real thing. He has some history with emojis just in case you were thinking wtf?
Also there is a dig at Linux (not really) but its an interesting reason, and I'd love to hear if anyone would know how to get around it using Linux. Maybe come up with a legit reason why he should have used Linux?
I think his reasoning was that it might be easier in windows. He might not have a lot of experience with linux, but I think he has some. He admits a little bit that it may be easier on linux, if you know what you're doing. I'm not really sure about the cheaper part of using windows... maybe he doesn't have as much experience as I thought. I thought he had a lot, he seems pretty smart. I think he does some security research too, he seems pretty well versed.
Generally a hack isn't an elegant solution so this makes sense from a repair point of view. It will do the job but it ain't pretty and will probably break again requiring another bodge.
Nah that translates to English too, makes perfect sense.
I am now very tempted to learn how to do this in Linux using 1 keyboard and stick it to him as I have even less experience than he seems to have. The other thing is he says there is not an emoji keyboard, well... also up my street is custom mechanicals. I am sure with the reprogrammable mechs I can make it type native emoji, and an F24 key.
Basically as good as I am sure he is, he seems like an ignorant know nothing. Not to put him down at all he is certainly smarter than me in some (probably most) aspects, but he comes off as someone who is bullheaded and does not like to research jack shit. He would rather waster hours possibly even days bodging rather than spend a small amount of time to find the best tool for the job, which is odd because as a programmer you are taught to be as "lazy" as possible to make your work faster. Lazy in that you are told if you don't have to rewrite something don't, just copy paste it, you know make your life easy. So a best tool for the job approach would have been much faster.
That and he says at one point "This is Windows! Someone is bound to have done this before." Or something along those lines. That struck me as that is the Linux mentality, with the failover that if it has not then bodge it. Seems odd that he has such a vendetta against Linux, even going so far as to ignore android and talk solely about iOS in his examples.
I would have thought that is a Windows things purely on the fact that Windows has been big for so long that somebody was bound to have built something like that before. And they did, in the flight sim communities. Not sure why you thought that would be Linux. Yes it would be true for the Linux community in terms of things that people are likely to find, but for something as obscure as connecting 14 keyboards together?
I'm not sure he has a vendetta against Linux. More that he is comfortable with Windows and probably gets asked a million times "why don't you use Linux". But who knows though.
But with Linux you would not have needed that as you could just get input from individual device IDs. No mucking about. Like how you can plug two keyboard in and have one solely dedicated to a VM. Both are still recognised by the host but it ignores one, unlike windows where both of them are essentially one keyboard.
I'm not trying to convert you but have you seen any of his other stuff? I believe he is primarily a linguist but he does quite a few things science related. I have to say I quite like his channel. Originally came across it from Computerphile.
From the comments: blenderpanzi (https://youtube.com/#/user/blenderpanzi) It's hard to send unicode characters on Windows? Guess what, under Linux you just do: xdotool key U2603 (you can provide a window id via --window if you want/need to) That will input ☃ (unicode codepoint U+2603). That means all you need is this small helper C-program and then you can write the rest in bash! https://gist.github.com/panzi/8d3233ec7ecb4cc2c27b (53 lines including error handling)
Run for each keyboard something like that: ./kbcodes /dev/input/by-id/KEYBOARD_ID | while read code; do xdotool key printf U%X $((code + keyboard_start_codepoint)); done
You could also do it in one single C program using the XTest API if you want.
Then by the same person: Just realized there is the evtest tool, so no C component needed at all: sudo evtest /dev/input/by-id/$ID |grep --line-buffered 'EV_KEY.value 1>'|sed 's/.code ([0-9])./\1/'