i$k - Setting (or not) a project to create a keyb converter

Are you interested in this project ?

a) Yes - Only as a user
5
63%
b) Yes - As a user/developer
2
25%
c) No - It is similar to Soarer's Converter
1
13%
 
Total votes: 8

User avatar
idollar
i$

26 Oct 2014, 18:38

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$
Attachments
i$k - draft architecture 0.2
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.

User avatar
idollar
i$

26 Oct 2014, 18:39

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:
  1. Open source (GPL license ?)
  2. Conversion from XT/AT/PS2 (any other ?) to HID
  3. Maps with the possibility to load configurations. I mean that one should not recompile / re-flash to install new maps
    1. Conversion table (mapping)
    2. Macros definition
    3. Mouse emulation
  4. Serial interface to command the converter (Debug information, Control information, Enable/Disable USB HID)
  5. Multiple hardware platforms (Arduino, Teensy, self-designed PCB)
Nice to have:
  • 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.
To my best knowledge 2, 3a, 3b and 4 (using a different mechanism) are covered by Soarer's firmware and tools.

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$

User avatar
idollar
i$

26 Oct 2014, 18:40

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
Attachments
i$k architecture Draft 0.1
i$k architecture Draft 0.1
Architecture 0.1.jpg (80 KiB) Viewed 4182 times

User avatar
idollar
i$

26 Oct 2014, 18:44

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.
Attachments
edison.jpg
edison.jpg (31.67 KiB) Viewed 4178 times

User avatar
idollar
i$

26 Oct 2014, 18:45

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.

Arakula

26 Oct 2014, 19:02

idollar wrote: I have drawn a potential architecture (draft 0.1).
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.

User avatar
idollar
i$

26 Oct 2014, 19:04

Attached a new draft architecture V0.2 including bluetooth :-)
Attachments
i$k draft architecture V0.2
i$k draft architecture V0.2
Architecture 0.2.jpg (136.63 KiB) Viewed 4155 times

User avatar
idollar
i$

26 Oct 2014, 19:14

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
Attachments
Architecture 0.2.odg
i$k draft architecture V0.2 - (Libre Office)
(30.33 KiB) Downloaded 151 times

Arakula

26 Oct 2014, 19:21

As you asked, I want you to do it 8-)

User avatar
idollar
i$

26 Oct 2014, 19:28

I have added a poll at the beginning of the thread.
If you read this post, you may want to participate

i$

User avatar
idollar
i$

26 Oct 2014, 19:44

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

mtl

27 Oct 2014, 04:14

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.
Spoiler:
Architecture.png
Architecture.png (180.1 KiB) Viewed 4080 times

User avatar
idollar
i$

27 Oct 2014, 07:19

Hello mtl,

Regarding:
What do blue and yellow represent?
The two blue boxes are actually the same module. The same applies to the orange ones.
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$

jacobolus

27 Oct 2014, 08:43

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?)

User avatar
idollar
i$

27 Oct 2014, 08:50

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

mtl

27 Oct 2014, 13:30

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.
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).

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.
idollar wrote:I have a attached the libre-office version of the drawing.
Can you draw it in Inkscape?

User avatar
idollar
i$

27 Oct 2014, 13:58

Code: Select all

Can you draw it in Inkscape?
I have never used Inkscape but it sounds an interesting tool.
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

Post Reply

Return to “Workshop”