deskthority

Vierax wrote:With a soft like PKL, you don't have to be admin to use an exotic layout on Windows

Except it doesn't work with UAC or the login screen... It's fun to type in Colemak in most programs, only to notice that you are typing Qwerty while editing Environment variables or logging in to run a program as a different user.

JBert wrote:I happen to have another (weird) question: will there ever be support for a few extra Fn keys connected directly to one of the free Teensy ports?

I'm thinking about adding an extra Fn key but I would like to avoid messing around with the keyboard's matrix. Connecting an external switch would mean that I'd just need to connect it between +5V + a resistor and ground, and it would even allow me to make it a foot switch.

Any thoughts on how complicated this is? I could understand that you wouldn't like to debounce the switch, but then again it's just an Fn key which is non-printable...

I have the exact same question: did you come up with a fix, JBert? Otherwise, I guess I need 2 Teensy's: one to control a few keys, another to convert/translate, then connect them to a USB hub. Any suggestions on controller code? I think the PJRC demo code could be easily tweaked to send a few keys.

But then Soarer's converter won't see the extra layer keys, so then we have to implement them on the host computer (AHK / Linux keymap).

Did you look into adding this to Hasu's converter?

EDIT: I suppose there's no way that Soarer's converter can listen to two keyboards? That would allow wiring the secondary controller to a plastic USB/PS2 converter, then into the converter which could now recognize the extra keys.

No, I just left the project for what it was after Soarer said he didn't want to add such a thing (I was trying to graft the converter onto a Poker in PS/2 mode).

On other keyboards I replaced the controller completely with a Teensy running controller firmware.

OK...sounds like maybe that's the way to go. I made a new thread about how to interface to the matrix of an existing keyboard; feel free to post any suggestions or links.
http://deskthority.net/workshop-f7/old- ... t4398.html

How can I get the lefthand keys working on a 122 model m with this firmware?

Which one? With Soarer's it should work out of the box. Wait, what do you mean by lefthand keys?

Icarium wrote:Which one? With Soarer's it should work out of the box. Wait, what do you mean by lefthand keys?

The function keys to the left of the keyboard.

IBM model m terminal. By left hand keys I mean the 10 key caps to the far left.

Ah, well those you actually have to add to the config afair. I can send you mine as a starting point when I get home tonight.

Edit: If you're just looking for the codes, this is c&p from the docs:
EXTRA_F1 0xB7 122-key Terminal lhs F1
EXTRA_F2 0xB8 122-key Terminal lhs F2
EXTRA_F3 0xB9 122-key Terminal lhs F3
EXTRA_F4 0xBA 122-key Terminal lhs F4
EXTRA_F5 0xBB 122-key Terminal lhs F5
EXTRA_F6 0xBC 122-key Terminal lhs F6
EXTRA_F7 0xBD 122-key Terminal lhs F7
EXTRA_F8 0xBE 122-key Terminal lhs F8
EXTRA_F9 0xBF 122-key Terminal lhs F9
EXTRA_F10 0xC0 122-key Terminal lhs F10

I will have to read up how to make configs, thanks.

Soarer's docs are insanely good. I would like to reward him with a virtual cookie or something.

I need to find how I mapped mine, but it involved mapping volume, the PrtSc/ScrLk/Pause block, Esc, and the Windows keys there.

PLEASE VOTE for my converter in the Deskthority Awards 2012: Best input device mod 2012.

The contenders are very strong indeed, so I hope we can at least make it a close race

Cheerleading is allowed... hint, hint!!! Sod the hint - post praise in the voting thread!!!


I'm also nominated in the Best deskthority forum contributor 2012 category, but since I constantly troll 7bit I don't stand a chance So vote for bpiphany!

Soarer wrote:Very nice! That USB extension fits tidily between the existing posts, I see!

Strictly speaking, you should ground the metal plate, but it's not anything like as vital on an M as it is on an F

Hello again Soarer!

Just nabbed myself a Model F off ebay (for cheap... great condition... I got lucky!)

Anyway, how would I go about grounding an F effectively? I noticed the little bugger is metal all around and I'm not a fan of shocking the hell out of myself from time to time.

sealclubber wrote: Hello again Soarer!

Just nabbed myself a Model F off ebay (for cheap... great condition... I got lucky!)

Anyway, how would I go about grounding an F effectively? I noticed the little bugger is metal all around and I'm not a fan of shocking the hell out of myself from time to time.

I can't remember it 100%. Which Model F?

I think in most cases the controller grounds the frame, and the grounding tag just grounds the shield of the cable.

So, probably nothing!

You might get the ground path of:

Base pan -> keyboard frame -> controller -> Teensy -> USB -> PC power supply -> AC ground

Nevermind its all good. Typing on it at the moment actually. Some of the keys needed a good whacking to get them to work. Was scared I bought a faulty board for a sec. This shit is dope. Thanks again soarer!

JBert wrote:I happen to have another (weird) question: will there ever be support for a few extra Fn keys connected directly to one of the free Teensy ports?

I'm thinking about adding an extra Fn key but I would like to avoid messing around with the keyboard's matrix. Connecting an external switch would mean that I'd just need to connect it between +5V + a resistor and ground, and it would even allow me to make it a foot switch.

Any thoughts on how complicated this is? I could understand that you wouldn't like to debounce the switch, but then again it's just an Fn key which is non-printable...

Hubbert wrote: I have the exact same question: did you come up with a fix, JBert? Otherwise, I guess I need 2 Teensy's: one to control a few keys, another to convert/translate, then connect them to a USB hub. Any suggestions on controller code? I think the PJRC demo code could be easily tweaked to send a few keys.

But then Soarer's converter won't see the extra layer keys, so then we have to implement them on the host computer (AHK / Linux keymap).

Did you look into adding this to Hasu's converter?

EDIT: I suppose there's no way that Soarer's converter can listen to two keyboards? That would allow wiring the secondary controller to a plastic USB/PS2 converter, then into the converter which could now recognize the extra keys.

Is there still desire for the extra few keys?

I've got v1.1 almost ready, and could possibly squeeze reading a few keys in somehow. There's 5 codes spare between AB and AF I could use, so it would be 5 key inputs - probably on PB0 to PB4, with each key simply grounding the pin (no matrix, and using the internal pull-up, although you could add an external pull-up resistor as well). If I do it, I might as well debounce them - any idea what the debounce time for footswitches is?

Soarer wrote:Is there still desire for the extra few keys?

I've got v1.1 almost ready, and could possibly squeeze reading a few keys in somehow. There's 5 codes spare between AB and AF I could use, so it would be 5 key inputs - probably on PB0 to PB4, with each key simply grounding the pin (no matrix, and using the internal pull-up, although you could add an external pull-up resistor as well). If I do it, I might as well debounce them - any idea what the debounce time for footswitches is?

I think I'm personally not going to use it anymore now that there are alternative Poker PCBs doing the rounds, but I still think it is a nice addition. Hubbert could have used it, and other users of the Poker or Pure might still want to make their keyboard programmable.

I don't have a footswitch, so I'm not sure how many ms it takes to settle. However, if those external switches are used as modifiers they're likely to remain pressed for a few seconds, which should leave room to take a larger settling time to be on the safe side.

That would still be great for me! And I like the no-matrix idea, both for simplicity and also because these are likely to be used as modifiers.

I think finger keys are the most likely use, so I would use keyboard timing. Unless the debounce times could be configurable on a per-input basis.

For now I've coded it to read 5 inputs at 1kHz with a simple 10ms batch debounce. That means it waits until there's 10ms of no change on any input; it doesn't matter if it bounces for a longer time before becoming stable. I might add a debounce setting in the config (in a future version), but it would still be the same for all keys (that's simply the nature of batch debounce, but even with individual debounce it would be awkward to have individual debounce times).

v1.10 is now available in the OP!

Nothing essential for most people, but it does have a lot of documentation updates which are worth having

This looks like a great converter project. I was just wondering, is the source also available? All I could find are the .hex images.

It's the best!

Sorry, no source. It probably will become open eventually, but for now at least I don't want there to be forks.

Thanks for the quick response. I was only wondering how the usb nkro was handled in the firmware. Keep up the good work and +1 for open source.

Ah, that's done using a bitmap, with a bit for each key. For an almost identical setup, you could have a look at hasu's code - the report descriptor is defined as keyboard2_hid_report_desc in protocol/pjrc/usb.c (currently at line 184).

Thanks for the link.
Isn't the usb keyboard spec limited to 6kro? I believe that is the reason why some are using a usb composite device with multiple keyboard devices to increase the number of keys before roll over. I was wondering if you were using the same method to get nkro on a usb keyboard.

The main limit isn't in the HID keyboard spec (it's very flexible), rather that low-speed USB can only send 8 bytes in a packet. With full-speed USB that limit is 64 bytes, which is more than enough for a clean and widely compatible NKRO implementation. The Atmel chips (as used on the Teensy etc) can do full-speed, and there's a small number of keyboards that do (Microsoft Sidewinder X4, CoolerMaster Quick Fire Pro (and TK, I think), but that's about all, so far).

wcass wrote:feature request:

i know that all of the guys that like trackpoints would like to see a PS2 pass through and keyboard equivalent to left, right, center mouse buttons. i personally am not a trackpoint fan, but i would like to make ...

I've been thinking a bit more about adding a second PS/2 input. There are... multiple issues

Looking at hasu's code, it seems that PS/2 mouse is only supported with a keyboard (matrix) project. It's much harder to run two PS/2 inputs concurrently, since they would both have to respond quickly to incoming signals at arbitrary times. I've had to work on all the other interrupts used in my converter to make sure they don't take too long, so that the PS/2 interrupt isn't ever delayed too much, but doing the same with the PS/2 interrupt would be quite a bit harder (mostly thanks to it being bidirectional).

With a keyboard, it really doesn't matter if you misread an input occasionally - you can just ask it to resend (except for PC/XTs, but they already have simpler interrupt handling). With a pointer device that can be almost constantly streaming events, that's probably not viable. (That said, I think working on all the other interrupts solved any resends that were caused by the converter).

Refactoring the code to cope with two inputs would be quite painful. As typical with embedded code, there's a lot of hardcoded stuff to do with ports etc, and lots of static/global variables. The simplest (but hackiest) way would be to copy all the PS/2 code to another file, rename the functions and variables, and modify the ports, interrupt and timer. Or I could change to C++, and implement it as a class with virtual functions or as a template. As a class would give the smallest code size, but performance would suffer. As a template would perform nicely, but would probably result in less readable code. All things considered, the hackiest way has its merits!

Then there's potential issues with the non-interrupt main loop code. Writing to a PS/2 port (e.g. setting LED state) currently blocks the main loop, so processing completed PS/2 inputs from the other PS/2 port could be delayed. Possible solutions might be to add extra buffering, or to make the writing a task with it's own state machine. Either would be fairly straightforward, but it's still extra work.

Overall, perhaps the biggest problem is that there would such major changes that it's almost inevitable that the new version would have some bugs affecting keyboards that could take a few revisions to iron out. That would be made more difficult because a lot of people wouldn't use the new version, if they don't want the new features (take-up of v1.1 has been pretty slow even compared to v1.01/v1.02/v1.03, which fixed things that didn't affect many people).

Still, just to tease you, this is how it WOULD logically look IF the dream was realised...

Hey Soarer,

Just installed a Teensy 2 on my Model F PC/AT with great success! Now I'm trying to convert the layout to as close to ANSI as possible -- how would I go about remapping the forward slash which is normally unused on the Model F, right above Enter? I installed a spring and hammer where the physical key is, obviously, but it doesn't register as anything when I type with it.

Thanks a lot for a great program, by the way! It feels so nice to type on a Model F.