i$k - Setting (or not) a project to create a keyb converter
- idollar
- i$
- Location: Germany (Frankfurt area)
- Main keyboard: IBM F or M
- Favorite switch: BS
- DT Pro Member: -
Hello,
I open this new thread to organise the discussion on the potential collaborative, open source, multi-interface and who-knows-what-more-is-to-come project to convert and control keyboards.
-----
Progress summary:
Date: 26.10.2014
Started
Draft architecture 0.2
Added poll
Added GitHub Repository
Other projects:
tmk_keyboard
kiibohd
xwhatsit's Grand Unified IBM Capsense USB controller thread
OSs:
Chibios
-----
Following this post I will attach the posts that we already had in the forum:
Cheers
i$
I open this new thread to organise the discussion on the potential collaborative, open source, multi-interface and who-knows-what-more-is-to-come project to convert and control keyboards.
-----
Progress summary:
Date: 26.10.2014
Started
Draft architecture 0.2
Added poll
Added GitHub Repository
Other projects:
tmk_keyboard
kiibohd
xwhatsit's Grand Unified IBM Capsense USB controller thread
OSs:
Chibios
-----
Following this post I will attach the posts that we already had in the forum:
Cheers
i$
- Attachments
-
- i$k - draft architecture 0.2
- Architecture 0.2.jpg (136.63 KiB) Viewed 4157 times
Last edited by idollar on 27 Oct 2014, 10:10, edited 9 times in total.
- idollar
- i$
- Location: Germany (Frankfurt area)
- Main keyboard: IBM F or M
- Favorite switch: BS
- DT Pro Member: -
Original Post 1
Hello Arakula (and all others in the forum),
An alternative would be to create a project to implement a new version from scratch.
I need to be careful with what I will say now. I do not have lot of time and it seems to me that to get where his software is, there is a need to put lot of effort.
My personal interest - features - that I would like to have are:
I am an telecommunications (electrical) engineer.
I am not an expert on Keyboards and/or mice protocols. I heed to learn HID, I have some experience with Arduino.
Again, I do not promise anything but I would like to know the ideas from others.
I would love Soarer to participate, comment and/or tell me where I am mistaking.
Cheers
i$
Hello Arakula (and all others in the forum),
An alternative would be to create a project to implement a new version from scratch.
I need to be careful with what I will say now. I do not have lot of time and it seems to me that to get where his software is, there is a need to put lot of effort.
My personal interest - features - that I would like to have are:
- Open source (GPL license ?)
- Conversion from XT/AT/PS2 (any other ?) to HID
- Maps with the possibility to load configurations. I mean that one should not recompile / re-flash to install new maps
- Conversion table (mapping)
- Macros definition
- Mouse emulation
- Serial interface to command the converter (Debug information, Control information, Enable/Disable USB HID)
- Multiple hardware platforms (Arduino, Teensy, self-designed PCB)
- Integration with a mouse - Soaerer already thought about it but I guess that it was never implemented.
- Ethernet interface to simulate key-strokes over the network.
- Multi-host (serve two computers) that could be selected using combinations of keys.
I am an telecommunications (electrical) engineer.
I am not an expert on Keyboards and/or mice protocols. I heed to learn HID, I have some experience with Arduino.
Again, I do not promise anything but I would like to know the ideas from others.
I would love Soarer to participate, comment and/or tell me where I am mistaking.
Cheers
i$
- idollar
- i$
- Location: Germany (Frankfurt area)
- Main keyboard: IBM F or M
- Favorite switch: BS
- DT Pro Member: -
Original Post 2
Hello again,
I have drawn a potential architecture (draft 0.1).
Black items are, to me, the first to implement. But the interfaces, data structures etc ... should be defined from the beginning. This would allow people to focus on different modules.
I attach the image here, but I guess that it may be better to create a separated entry in the forum.
If people is willing to support this idea, we should create a repository in a collaborative site. I have not experience doing it, but this fact only adds to my interest in this (potential) project.
Attached you can find the VERY draft 0.1 architecture
Cheers
Hello again,
I have drawn a potential architecture (draft 0.1).
Black items are, to me, the first to implement. But the interfaces, data structures etc ... should be defined from the beginning. This would allow people to focus on different modules.
I attach the image here, but I guess that it may be better to create a separated entry in the forum.
If people is willing to support this idea, we should create a repository in a collaborative site. I have not experience doing it, but this fact only adds to my interest in this (potential) project.
Attached you can find the VERY draft 0.1 architecture
Cheers
- Attachments
-
- i$k architecture Draft 0.1
- Architecture 0.1.jpg (80 KiB) Viewed 4182 times
- idollar
- i$
- Location: Germany (Frankfurt area)
- Main keyboard: IBM F or M
- Favorite switch: BS
- DT Pro Member: -
Original Post 3 - quantalume wrote:
Between the TMK controller and xwhatsit's controller, there is a large body of open source code already available.
I've been thinking about the possibilities of using the Intel Edison. Imagine having wifi, bluetooth, USB (including host mode) and Linux inside your keyboard.
Between the TMK controller and xwhatsit's controller, there is a large body of open source code already available.
I've been thinking about the possibilities of using the Intel Edison. Imagine having wifi, bluetooth, USB (including host mode) and Linux inside your keyboard.
- Attachments
-
- edison.jpg (31.67 KiB) Viewed 4178 times
- idollar
- i$
- Location: Germany (Frankfurt area)
- Main keyboard: IBM F or M
- Favorite switch: BS
- DT Pro Member: -
Original Post 4 - mtl wrote:
I'm dabbling with implementing a new firmware based on ChibiOS. My custom keyboard has a lot of components and would benefit from the multithreading support. Like you say getting it off the ground is a large undertaking so it would be great to collaborate with others.
I'm dabbling with implementing a new firmware based on ChibiOS. My custom keyboard has a lot of components and would benefit from the multithreading support. Like you say getting it off the ground is a large undertaking so it would be great to collaborate with others.
-
- Location: Austria, Europe
- Main keyboard: Unicomp PC/5250
- DT Pro Member: -
- Contact:
Missing IMO is a PS/2, a serial, and a parallel output module; I got some (VERY old, admittedly) computers that get their input in ASCII from an 8-bit 6821 port (and a strobe line, IIRC - would have to look that up again). Would be nice to get that working, too... your "USB 1, 2, ..., N" output implies a multichip solution anyway, so why not.idollar wrote: ↑I have drawn a potential architecture (draft 0.1).
- idollar
- i$
- Location: Germany (Frankfurt area)
- Main keyboard: IBM F or M
- Favorite switch: BS
- DT Pro Member: -
Hello Arakula,
I have a attached the libre-office version of the drawing.
Feel free to add the modules that you are missing.
If you want me to do it, tell me.
PLEASE - use the naming conversion to keep the versioning until we do something proper.
PLEASE - post the new v0r3
Cheers
I have a attached the libre-office version of the drawing.
Feel free to add the modules that you are missing.
If you want me to do it, tell me.
PLEASE - use the naming conversion to keep the versioning until we do something proper.
PLEASE - post the new v0r3
Cheers
- Attachments
-
- Architecture 0.2.odg
- i$k draft architecture V0.2 - (Libre Office)
- (30.33 KiB) Downloaded 151 times
-
- Location: Austria, Europe
- Main keyboard: Unicomp PC/5250
- DT Pro Member: -
- Contact:
As you asked, I want you to do it
- idollar
- i$
- Location: Germany (Frankfurt area)
- Main keyboard: IBM F or M
- Favorite switch: BS
- DT Pro Member: -
I have created a GitHub repository: https://github.com/idollark/idollark
For the time being we will host the documentation for the discussion.
Who knows what the future will bring
Cheers
For the time being we will host the documentation for the discussion.
Who knows what the future will bring
Cheers
-
- Location: USA
- Main keyboard: Custom
- Main mouse: IBM TrackPoint IV
- Favorite switch: Cherry MX Clicky
- DT Pro Member: -
Nice figure. What do blue and yellow represent?
FWIW, the code I was working on is here. So far all I've done is start porting ChibiOS to the Teensy 2.0/2.0++ (feature/teensy20pp branch) and start re-implementing maxtrix scanning code (feature/keyboard branch).
Here's an updated architecture that accounts for PS/2 mouse -> USB conversion as is common for keyboards with integrated TrackPoint. Changes in red. The mouse "remapping" is where middle button scrolling would be implemented.
FWIW, the code I was working on is here. So far all I've done is start porting ChibiOS to the Teensy 2.0/2.0++ (feature/teensy20pp branch) and start re-implementing maxtrix scanning code (feature/keyboard branch).
Here's an updated architecture that accounts for PS/2 mouse -> USB conversion as is common for keyboards with integrated TrackPoint. Changes in red. The mouse "remapping" is where middle button scrolling would be implemented.
Spoiler:
- idollar
- i$
- Location: Germany (Frankfurt area)
- Main keyboard: IBM F or M
- Favorite switch: BS
- DT Pro Member: -
Hello mtl,
Regarding:
I did not know find out a way to position them a single time in the drawing
Regarding the updated drawing:
I thought that we could treat the mouse as a keyboard. why not ?
The internal representation should include a parameter indicating the amount of displacement but the rest would be the same. This would allow to remap the keys and movements. One could also run a macro when a button is pressed.
If you agree, we should add a new section in the configuration for the mice.
Let me (us) know what do you think. I offer again the option of updating the drawing (if you accept this approach)
Regarding your code:
I need to go to work now. I have downloaded the code.
Cheers
i$
Regarding:
The two blue boxes are actually the same module. The same applies to the orange ones.What do blue and yellow represent?
I did not know find out a way to position them a single time in the drawing
Regarding the updated drawing:
I thought that we could treat the mouse as a keyboard. why not ?
The internal representation should include a parameter indicating the amount of displacement but the rest would be the same. This would allow to remap the keys and movements. One could also run a macro when a button is pressed.
If you agree, we should add a new section in the configuration for the mice.
Let me (us) know what do you think. I offer again the option of updating the drawing (if you accept this approach)
Regarding your code:
I need to go to work now. I have downloaded the code.
Cheers
i$
-
- Location: geekhack ergonomics subforum
- Favorite switch: Alps plate spring; clicky SMK
- DT Pro Member: -
You should go look at Soarer’s firmware, hasu’s https://github.com/tmk/tmk_keyboard firmware, and HaaTa’s http://github.com/kiibohd/controller firmware. I expect that most of what you want to do is covered already.
(Or perhaps you can explain concisely what’s new and different about your proposal?)
(Or perhaps you can explain concisely what’s new and different about your proposal?)
- idollar
- i$
- Location: Germany (Frankfurt area)
- Main keyboard: IBM F or M
- Favorite switch: BS
- DT Pro Member: -
Hello,
This thread started when I asked Soarer where could I find the source code. Do you know where to find it ?
What I intend to do is to have one single way to approach all what you have mentioned. If I am correct, with the architecture that I am proposing it should be possible to convert and control most of the hardware in a modular way.
Does the above paragraph answer your question ?
Regards.
Íñigo
This thread started when I asked Soarer where could I find the source code. Do you know where to find it ?
What I intend to do is to have one single way to approach all what you have mentioned. If I am correct, with the architecture that I am proposing it should be possible to convert and control most of the hardware in a modular way.
Does the above paragraph answer your question ?
Regards.
Íñigo
-
- Location: USA
- Main keyboard: Custom
- Main mouse: IBM TrackPoint IV
- Favorite switch: Cherry MX Clicky
- DT Pro Member: -
If you draw the architecture more abstractly, then yes, keyboards and mice can both be considered generic devices to be translated by the remapper. At this level however, it makes sense to distinguish between keyboards and mice because the interfaces will be different. For instance, probably what you have coming into the keyboard remapper on the left are physical key switch actuation events (scan code make/break signals), and on the right interface coming out are key press events (key codes).idollar wrote:I thought that we could treat the mouse as a keyboard. why not ?
The internal representation should include a parameter indicating the amount of displacement but the rest would be the same. This would allow to remap the keys and movements. One could also run a macro when a button is pressed.
There are some points of interaction between the two for keyboard mouse emulation and (as you mentioned) mouse-involved keyboard macros. So again it would be useful to draw keyboards and mice separately to indicate this.
Can you draw it in Inkscape?idollar wrote:I have a attached the libre-office version of the drawing.
- idollar
- i$
- Location: Germany (Frankfurt area)
- Main keyboard: IBM F or M
- Favorite switch: BS
- DT Pro Member: -
Code: Select all
Can you draw it in Inkscape?
I will check how long it would take me. But I would prefer to focus on more interesting aspects, I mean the architecture itself
Cheers