There was a time where I though it was a great idea to use an alternate keyboard layout. Namely Dvorak. Now, Dvorak is ergonomically amazing and all, but the absence of being able to qwerty all that well it is a bit annoying when using others computers knowing I could be typing 60WPM in Dvorak (and using caps as backspace). Switching layouts on someone else's computer is easy, however just because you can doesn't mean you should. Personally I recommend against the practice, the muggles view it akin bewitching evil spirits upon their magic information box.
That is the basic problem that leads me to the following hair brain idea. The Yun has a female USB port on the Linux side and a micro usb on the Arduino side where said Arduino can theoretically receive a character like "b" over Serial1 and then send it as "Keyboard.write("x")" over the Mircro USB line. On the Linux side of things there would need to be something that grabs key events and send them over serial. I know a GUI library like TKinter can do this but I'm pessimistic about how TK would work on the Yun.
In short, a converter can be built, that converts QWERTY to "whatever layout needed", giving a plug n play Dvorak or Colmak experience.
Of course ctrl and alt-tabbing type things are easier said then done, but I have done them before with ps2 to usb converters I have worked on. My point of concern mainly lies in the peculiarities that surrounding bridge / Arduino <-> WRT communication. I'm curious if anyone here has better ideas about how to approach the problem? Specifically knowing maybe whether creating python script that grabs key events and passes them over serial is more of an afternoon event or two week nightmare. Or maybe there is a better strategy that is more obvious to someone other than myself.
Percentages of Letter Frequencies per 1000 Words. The average length of English words is 4.5 letters, while the average length of French words is 4.84 letters, and the average length of Spanish words is 4.96 letters.
Unfortunately Yun's bridge will be your bottleneck, but working perfectly for me since I type slowwwwww in English.
Serial1 communication should be about 250000 baud, which from my limited understanding should be a number of kilobytes per second right? Way faster than 40 baud. Although in my experience with the Yun that rate seems like it is too high and it seems to lose data which is definitely a problem.
I'm sorry, I guess maybe its unclear that I'm talking about a USB to USB converter because normally the Yun is exclusively used for wifi things, but even if I was crazy enough to want to turn the Yun into a Synergy server wouldn't the data rate be good enough? I mean I have definitely scp(ed) files over at a faster rate then 40 baud.
Yun has two USB ports, one host port from Linux side (AR9331), one device port from ATmega32u4. USB to USB converter is required bridge between them, and common way, bridge class is reported by member here which is quite slow. However you could directly connect UART port or SPI port but you are on your own.
P.S. for full speed USB 2.0 or 3.0 converter, AR9331 (400Mhz 32 bits single core CPU) is far slow to handle data flow as well.
My plan so far is to avoid bridge, I never really could get my head around it.
Already disabled actually.
Thinking UART right now just because I am more familiar.
Which is nice. Looking over Micah's code I'm getting an idea of the scope of what needs to be done.
sonnyyu, going over old forum post I can see you have delved into this type of thing a bit. I trust there may be some sort of speed bottleneck somewhere. Its no surprise to me when I see blocking operations mucking things up, but I think what you are suggesting is the hardware is just not cut out for this type of thing. Which is something I'm a bit dubious of. Is the AR9331 really that slow that it would have a hard time keeping up with any typist on a byte by byte basis? Or does it come down to more of a practical issue of buffering and garbage collection messing with responsiveness? I mean we are really only talking less than 20 bytes per second right?
OKAY! I got the basic thing working! ( was like a 2 afternoons project )
Here is the code, which I mostly have others to thank for to be honest, I just hacked somethings together
This is still not finished, but it does the basic conversion as of now.
Speed has really yet to be an issue even given how inefficient this hack is. sonnyyu must be specifically referring to using bridge to try and accomplish this task.
Any questions or interest are welcome, I'll be polishing the functionality of this off over the next couple of days so I can use it in actual real life situations. Solves a big issue for me!
USB 1.1 allowed Low Speed (1.5 Mbit/s) and Full Speed (12 Mbit/s). The now-aging USB 2.0 standard can theoretically transfer data at a very high 480 Mbit/s. That's impressive, but not as much as the newer USB 3.0, which can handle up to 5 Gbit/s. Uart will be suffer with even Low Speed (1.5 Mbit/s).
USB at AR9331 is 2.0, but since CPU power limit never reach theoretically transfer speed.
However since you transfer keystrokes every thing should be fine.
With the current code on Github it should be working albeit with one bug I know of (see below) and minus a few keys others might want but were left out.
In fact, I'm using the software right now to type this post.
N-Key Rollover Bug:
So the whole point of this was so I could bring my nice Cooler Master Keyboard around with me without switching everyone else's keyboard layouts. I have PS2 keyboard that I programmed to do the exact same thing (plus real time speed monitoring, which would be fun to add to this), however after using cherry key-switches I have little heart to use those cheap membrane boards on a regular basis.
OK so The Bug: Yesterday I was initially testing this code with a cheap membrane board everything worked, switched to my Mech board and I quickly realized many of the keys were not working. The only difference that I could think of was the N-key rollover mode, thankfully the board allows me to switch into 6 key rollover which come to find out today that works fine.
TL;DR - N-Key Rollover boards or modes will not work with this an it likely has to do with evdev which is still a bit of a mystery to me.
Auto-start Question:
In relation to bridge being disabled is there an easy way run this application when the Yun boots?
I can probably come up with one but it might be ugly.
Add a call to your application file in /etc/rc.local is a rather easy way. Start the line with an '@' sign so it runs asynchronously and doesn't cause rc.local to hang.
ShapeShifter:
Add a call to your application file in /etc/rc.local is a rather easy way. Start the line with an '@' sign so it runs asynchronously and doesn't cause rc.local to hang.
So tried this, and these things tend to be much more pedantic then the way we might like to communicate them.
I did get it to hang on printing a bunch of slashes, my saving grace is that unplugging the keyboard stops the program or prevents it from running at all.
(/etc/rc.local)
# Put your custom commands here that should be executed once
# the system init finished. By default this file does nothing.
wifi-live-or-reset
boot-complete-notify
@ python /mnt/sda1/qToDvorak/usbConverter/qwertyToDvorak.py '/dev/input/event1'
exit 0
I'm sure this is horribly wrong somehow.
or maybe just the fact that there are print statements in the absence of (an apparent) standard out is throwing an error, its hard to tell without being able to see the moment of explosion. I'll try commenting out the prints tomorrow.