QMK Powered Equivalent to Soarer’s Converter?

[depletedvespene]

Still doesn't look like anyone's tried building a firmware outside of my own testing. Dropping the link again in hopes someone is willing to try out the firmware.

I want to be of help here, but I am not sure whether I got the right hardware, converter-wise. I got plenty of Orihalcon's cables (meant for Soarer's Converter) and a couple PS/2 hasu-made TMK converters, but I don't know if either do support a QMK .hex file.

Since I usually live a couple layers above (logical layouts), whenever I have to get down to controller hardware, I need to ask n00b questions. :-/


I should start by getting one of those TMK converters and try to load a (regular QMK site) simple .hex file, to see what happens. I'll report back later.

[snacksthecat]

Appreciate it if you can but no worries if you can't.

So far I've tested on a Filco PS2 keyboard with a Japanese layout, a Model F AT and Model F XT. I think I also have a Terminal IBM but will need to use a breakout board to wire the cable up to a teensy.

The keyboard converter is working as expected aside from one one bug I've found. The lock keys (caps, scroll, num) sometimes freeze the keyboard on AT boards. From the comments in the firmware code it looks like this is because those keys don't send break codes, so the converter has to send a fake break code (0x00) which it then interprets as an instruction to reset all keys in the matrix to an unpressed state. But for whatever reason it isn't working consistently and sometimes you get the lockup after pressing those. I suspect that it's probably a timing thing. Anyways, I've tried comparing the ported code with TMK and so far haven't been able to find an obvious difference in how this is implemented between the two.

^ not sure any of this is accurate

Edit: Actually it seems to be an issue that I introduced, probably when I overhaled the matrix to fill in the missing codes. I'm not able to reproduce the bug on the original port. At least I hope that's the case since that would be simpler to tweak something in the matrix rather than the portion of the firmware that handles in incoming scan codes from the keyboard, which is a bit of a mouse trap.

^ wasn't this either

[snacksthecat]

So it turns out I was double wrong in my last post and that the lock keys work fine without freezing up the keyboard. What caused that problem to happen was the print lines I added to the code for debugging. I have no clue why that would have that effect but I'm happy it's working now that I've removed them.

What's not working correctly now is the lock lights. I've confirmed this in the original ported firmware as well as the one with my edits. I've reproduced the issue on keyboard from two different decades so I'm sure it's a consistent problem.

The lights work right sometimes but more often they don't do what they should. As an example, you'll get the caps lock light stuck on and try spamming the key trying to get it to turn off. Then you'll give up and hit the scroll lock key and the caps lock light will turn off. Meanwhile the scroll lock light doesn't turn on. It's like a maddening version of that old handheld game "Lights Out".

I haven't had much luck finding where the breakdown is happening. It's a bit trickier for me to understand because now it's a matter of understanding how the computer is communicating to the keyboard and not the other way around. Anyhow here's a video of this head-scratcher in action:

Also as a side note: Thanks to the kind soul who gave me this sweet Secret Santa gift a few years back. It's super cool and has been useful for testing all the keys.

[marfrit]

I haven't had much luck finding where the breakdown is happening. It's a bit trickier for me to understand because now it's a matter of understanding how the computer is communicating to the keyboard and not the other way around.

Since all keys seem to register just fine in the tester, I figure the problem is the way the led state command is sent. To see on the software side, I would start by putting prints in the part of the code where the ACK is received from the keyboard.

http://www-ug.eecg.toronto.edu/msl/nios ... otocol.htm shows the keyboard receives 0xED <0..7> for the lock light state, and it looks like the timings could be just a bit off, throwing the keyboard contoller off its game.

I only have pro micros to check; what MCU did you use in your video?

As for the rest of your work: awesome! I was playing around with the configurator, but never got it to work properly (the hard coded json location throwing me off). You don't happen to have written down what you had to change to point the qmk web stack to your repository?

[snacksthecat]

I only have pro micros to check; what MCU did you use in your video?

As for the rest of your work: awesome! I was playing around with the configurator, but never got it to work properly (the hard coded json location throwing me off). You don't happen to have written down what you had to change to point the qmk web stack to your repository?

Hey marfrit, thanks for popping by.

I used a pro micro in my test, I can also try on a teensy and teensy++. I'll give those a shot.

Setting up the configurator turned out to be a lot of trial and error so my notes degraded over time. I can piece together the necessary changes and write them up to share. I should be saving this info for my own use as well anyways

[snacksthecat]

You don't happen to have written down what you had to change to point the qmk web stack to your repository?

I just posted a write up with instructions to my blog. Hope this is helpful to anyone trying to get the configurator up and running.

https://www.snacksthecat.com/p/setting- ... vironment/

[pandrew]

Hey all,

I have also just recently looked at marfrit's port to QMK of IBMPC_USB, and I hit the same bug related to the lock lights, and fixed it. Both the situation where lock lights are not updated correctly, and the situation where pressing the lock keys causes the keyboard to reset, and not work for a few seconds is caused by the same bug.

Here's the fix

The explanation is that the TMK firmware disables the clock edge sensitive interrupt that is normally used to receive data from the keyboard, while it's sending the lock light update commands. This is okay, however, what really _should_ be happening is that all interrupts should be disabled, because something else stopping the ibmpc_host_send routine could result in clock cycles being lost (reminder: the clock is ALWAYS generated by the keyboard on PS/2, so the converter must react to clock cycles also when sending data). The reason this worked in pure TMK is probably because interrupts just don't tend to trigger during ibmpc_host_send on tmk.

Anyway, I believe my fix has already been taken up in marfrit's repository.

I also built a VIAL firmware for ibmpc-usb-converter:
https://github.com/purdeaandrei/vial-qm ... -converter
Including the following changes:

• I completely reworked the layouts and the code set maps, so that it now matches TMK. This firmware should support all the same code sets as TMK does.
• Enabled VIAL support.
• I added VIAL layouts for all layouts supported by the TMK's web configurator (Full-Key, 122-key terminal, 84-key AT, 83-key XT), plus I added a DEC Televideo layout. (NOTE: These are VIAL layouts, as a pure qmk layout macro only Full-Key is supported at the moment.)
• I made variants for atmega32u4 for all possible bootloaders.
  • For pro micros you should normally use atmega32u4_caterina.
  • For teensy 2.0 you should probably use the atmega32u4_halfkay variant, although I haven't tested this one.
  • I have also tested this now with Orihalcon's Soarer's Converter cables (USB to SDL). The firmware that allows these to go into bootloader mode when commanded by VIAL is the atmega32u4_atmel_dfu variant. (Note: the bootloader on these seems to be bootloadHID-compatible protocol, but the bootloadHID variant of the firmware is not able to go into bootloader mode. So when flashing the cables you need need to first use 'scboot' to send it into bootloader mode, then use bootloadHID's command line utility, or QMK Toolbox, which autodetects what to use, but you should NOT flash the bootloadHID version of the firmware, you must flash the atmel_dfu version).
    
    WARNING: if you make a mistake, and flash the wrong firmware, or a firmware that can't enter bootloader mode, then the only way to get these cables into bootloader mode, is to cut them open, and to short the RESET pin to GND. Here's a tutorial how to do it: https://imgur.com/a/HT6RKKI
• I backported Televideo DEC keyboard support that is in current TMK, but isn't in Marfrit's port, because he started from a version that didn't yet have it.

You can download the pre-build VIAL images from the Releases page of the github project. The official downloadable VIAL host app works perfectly with it, and also the Vial Web client, if your browser supports giving access to the usb port.

Another minor note: the VIAL unlock combination has been set to Esc+non-keypad-Enter. If you use it with an SSK, and want to unlock the keyboard to do something that's normally blocked by security (such as going into bootloader mode), then make sure that Num Lock is not active, because Num Lock changes the Enter Key to Numpad Enter on the SSK. Anyway, we may change the combination in the future, if it's found to be not good enough.

[snacksthecat]

That's awesome, nice work, pandrew. You never cease to amaze me with your know-how.

Bringing the port in line with the latest TMK features was definitely something I wanted to do however it was way over my head. I'm not too shabby at making basic tweaks to stuff here and there but I'm out of my depth when it's more than a few lines.

I only stumbled across VIAL after I was already well down the QMK Configurator path. It piqued my interest but I didn't take the time to play with it. Nice to know that it's getting used by a sharp guy like yourself. That tells me it's probably worth checking out.

As for my goal to get the ported firmware added to QMK Configurator, I'm afraid I have to add another tick to the "unfinished stuff" column. I got busy with a work project for a few weeks and by that point it seems that community interest in this had fizzled out anyways. I guess it was a useful exercise that yielded a few good things:

• The IBMPC_USB port can and probably *should* be added to QMK Configurator
• We created a few layouts that would be good additions to this firmware. They're still on my github if needed for anything.
• Worked through the details of how to stand up a local/personal QMK Configurator for experimenting

I count all of those as wins so I'm pretty happy even though it didn't all pan out.

I also forgot about the VPS's I was still paying for. I'll leave the playground configurator that has just the ported firmware up for a few more weeks until it expires. Here's the link, feel free to play around:

http://195.88.25.119:5000/

That's a new link. The original VPS I had started misbehaving for some reason (configurator would say a job was queued even though nothing was going on). Hopefully the new one doesn't do that.

[ifohancroft]

Unfortunately, I can't help, but I wanted to let you (Mu) know that the latest version of VIA can be used online. https://usevia.app
Sorry, if someone has already mentioned this. I only read the first page.

[snacksthecat]

I was revisiting the setup steps for creating your own QMK Configurator instance with custom/unofficial keyboard support in order to update the guide I wrote a few months back.

The process is basically the same but with a few tweaks around some of the changes to the QMK repositories that have been implemented since I wrote the guide.

My goal was to stand up a more permanent instance of this custom configurator for people to use for generating Marfrit's ibmpc_usb converter firmware with custom keymaps having support for the 4 layouts that hasu has in his web configurator:

• fullkey
• xt83
• at84
• terminal

I was wondering if there's any interest/appetite in having something like this available and what features some people might be looking for. Some things I'm planning to do with this currently:

• add SSL to the web site
• keep the site up and available using a cheap VPS
• pull marfrit's latest changes and incorporate my modifications (for the different layouts). He fixed an issue with the lock lights that I was getting stuck on.
• (maybe) break the keyboard out into these 4 layouts so that each one can have a default keymap loaded. Otherwise selecting anything other than "fullkey" shows a blank keymap
• other suggestions?

Would there be any interest in this or do you think it would sit around unused?

brave_BrmLF0ACkT.png (185.81 KiB) Viewed 18570 times

[Muirium]

Well, personally, I have solved the specific problem of Soarer’s absent mouse key implementation by doing all of that on the host with Karabiner. I subsequently switched my QMK boards over from keyboard-side mouse keys to sending numpad keys, too, which I convert into an 8-way pointer control with Karabiner. Hold several keys and you get the additive effect of their movement. Much better behaviour than I ever had with QMK’s native mouse control.

So, no, I wouldn’t use it myself.

[Muirium]

Pedantic general QMK configurator whinge:

As for Pandrew’s server: every time I use it (yes, I’m a tweaker) I have to change those god awful colour schemes. Round 5 or Dolch, please. I don’t need unicorn puke barfed on me, Reddit. I never even signed up for you. Some of us were never fooled in the first place.

Anyway, QMK is now strictly limited to my Xwhatsit controller powered boards. Besides the occasional deep layer re-jig, I have little use for it. So even when Pandrew’s instance goes dark—this is the web, there is always a when—I’ll survive.

[snacksthecat]

Nice, I didn’t know pandrew had a server. I used his docker compose file to help when I was stumbling through the setup but even that I’m not sure where it came from. What is the address? Or is it super secret “if you know you know”?

[Muirium]

It’s, ah, common knowledge: for better or worse for Pandrew’s server bills.

I’d be happier hotlinking it if Ellipse hosted the thing himself, as surely most of the traffic is from his hardware sales. But that’s not how he rolls.

[snacksthecat]

It’s, ah, common knowledge

cool, I just have to know the exact IP to search for or read a 200 page thread to find it. How could I not have known? I’m on here so much

[Muirium]

I’m trying to keep it on the down-low because of exactly what I said. Ellipse should pay the bill.

If you read TS’s FSSK thread you’d find it prominently there, and many more places. I’m sure we all cost Pandrew an irritating penny for using his work, again and again, without a second thought. Or even necessarily knowledge that it’s his in the first place.

[snacksthecat]

Just curious: I assume these are not included in the official QMK repo for a reason. Why might that be if they have such broad usage? Sorry if that’s another stupid question.

[Muirium]

We are users. We wouldn’t understand the politics of a refused or withheld public GitHub commit if it spanked us. Maybe it even might!

Coders seem to talk a lot. We just want our hex files.

Pandrew’s have one appealing advantage on capsense controllers: they work.

[DMA]

Just curious: I assume these are not included in the official QMK repo for a reason. Why might that be if they have such broad usage? Sorry if that’s another stupid question.

I'm not even sure why QMK has such a wide apparent usage when it's not even really HID-compliant. Probably because they are super-loud about themselves, or may be those people demanding QMK support are fake accounts created by people behind QMK.. who knows.

I accidentally got a QMK board recently and lo - it doesn't even handle rollover correctly.
As in - you press 6 keys, then you press another - nothing changes (but keyboard doesn't send a packet with eKRO scancode - it just doesn't send any updates), then you release the key 1 AND NOTHING CHANGES (because QMK is too smart for it's own good and doesn't send the updated state to the host!) - and only when you release the second key, bringing total number of keys pressed to 5, it updates the host.

[ifohancroft]

Just curious: I assume these are not included in the official QMK repo for a reason. Why might that be if they have such broad usage? Sorry if that’s another stupid question.

I'm not even sure why QMK has such a wide apparent usage when it's not even really HID-compliant. Probably because they are super-loud about themselves, or may be those people demanding QMK support are fake accounts created by people behind QMK.. who knows.

I accidentally got a QMK board recently and lo - it doesn't even handle rollover correctly.
As in - you press 6 keys, then you press another - nothing changes (but keyboard doesn't send a packet with eKRO scancode - it just doesn't send any updates), then you release the key 1 AND NOTHING CHANGES (because QMK is too smart for it's own good and doesn't send the updated state to the host!) - and only when you release the second key, bringing total number of keys pressed to 5, it updates the host.

Obviously there are exceptions, but that's what I don't like about the modern keyboard community. They'd make something so it works, and call it a day, with no regards whether it's done properly. I've mostly noticed this with PCB designs. Famous example being Rama Works' PCBs not having any ESD protection. Some argue it's not needed in keyboards - first of all, that's bullshit. Second of all, the USB specification requires it, so you are literally breaking the specification in your implementation.

[Muirium]

Second of all, the USB specification requires it, so you are literally breaking the specification in your implementation.

What about the 1000s × more of us who don't design PCBs, don't write firmwares, and never will? Should we just let our keyboards lie useless, because of some coder jihad we neither understand nor respect? Pandrew's 'QMK' isn't 'upstream' QMK? I could care less. My IBM boards work brilliantly, and I thank him for it!

[ifohancroft]

Second of all, the USB specification requires it, so you are literally breaking the specification in your implementation.

What about the 1000s × more of us who don't design PCBs, don't write firmwares, and never will? Should we just let our keyboards lie useless, because of some coder jihad we neither understand nor respect? Pandrew's 'QMK' isn't 'upstream' QMK? I could care less. My IBM boards work brilliantly, and I thank him for it!

Oh, my critic is definitely not towards the users. Most of my keyboards are running QMK. I just wish people making stuff would put in the work to make them properly.

Also, I am mostly irritated about the hardware side of things. While I don't have any Rama boards, they cost a couple hundred bucks, and I know of more than one person whose keyboard was killed because of ESD because they live in a dry climate.

P.S. in case it wasn't clear, the specification breaking thing was about the lack of ESD protection on Rama PCBs. It has nothing to do with Pandrew's QMK. From what you wrote about it, Pandrew's QMK sounds awesome as fuck!

[Muirium]

We’re on the same wavelength.

I believe Pandrew chose QMK for his [insert correct technobabble terms including the word “stack” here] because it’s open source and brings a lot of things to the table, including that configurator. Sensible enough. What I don’t understand (and I must admit I’m incurious about) is why QMK didn’t “merge” [or whatever the term] his work into their own, forcing this fork. It all seems a bit Monty Python to me.

[DMA]

What about the 1000s × more of us who don't design PCBs, don't write firmwares, and never will? Should we just let our keyboards lie useless, because of some coder jihad we neither understand nor respect? Pandrew's 'QMK' isn't 'upstream' QMK? I could care less. My IBM boards work brilliantly, and I thank him for it!

If you don't design it, don't write firmwares, and never will - why do you care if it's QMK or not then? Especially when you can't tell the upstream QMK (which at least have some benefits) to QMK fork (which is, essentially, custom firmware, except more likely to break because the base software doesn't give a fuck about you when it's updated)?

[Muirium]

If you don't design it, don't write firmwares, and never will - why do you care if it's QMK or not then?

Emphasis added:

Pandrew's 'QMK' isn't 'upstream' QMK? I could care less. My IBM boards work brilliantly, and I thank him for it!

I just instinctively defend the honour of these supposedly shitty firmwares which I and many others use quite happily for years, vs. the hypothetical competition, which we can’t.

Honestly, I don’t give a flying monkey’s fart about the source tree and its politics. I’m focussed entirely on getting my keyboard to work and helping the inquisitive with theirs.

except more likely to break because the base software doesn't give a fuck about you when it's updated)?

I’m quite aware of that.

We are users. We wouldn’t understand the politics of a refused or withheld public GitHub commit if it spanked us. Maybe it even might!

But then the chances of me ever pulling out the Terminal and typing git update -fuckitallup YES on a firmware I already use and consider feature complete are right up there with compiling my kernel from source.

[DMA]

I just instinctively defend the honour of these supposedly shitty firmwares which I and many others use quite happily for years, vs. the hypothetical competition, which we can’t.

But the thing is - if there's a keyboard, there's _some_ firmware running on it. So it's not about "use happily" vs "can't use" - it's about forcing people to waste their time on QMK support for the keyboards they make instead of wasting their time on something else instead.

But then the chances of me ever pulling out the Terminal and typing git update -fuckitallup YES on a firmware I already use and consider feature complete are right up there with compiling my kernel from source.

So, essentially zero? Not sure why would one want to compile firmware if layout can be edited without reflashing. Looks like you're expecting other firmwares to have same limitations as QMK - which isn't actually fair. Like, literally, "they might have less or more features, but QMK's _limitations_ are the gold standard everybody must abide by".

[ifohancroft]

But then the chances of me ever pulling out the Terminal and typing git update -fuckitallup YES on a firmware I already use and consider feature complete are right up there with compiling my kernel from source.

Now I wish -fuckitallup was a real command argument

Unfortunately, when you implement a feature and the fork doesn't get merged upstream, the maintainer has to continue maintaining the fork on their own. But that's the beauty of open source and how we as users benefit from it. Even if the upstream doesn't implement a feature we want, there's always a chance of someone else forking the project and doing it there.

P.S. DMA, Muirium - I think you are both talking about different things. Which is funny that I'm saying this, because here I am talking about a third thing, to no one in particular.

In this context though - I do agree with DMA. We do need something better than QMK. While I like the widespread support it's gotten and the features it implements, I am not really happy with how it does some stuff and how it implements others. I do have an idea for my own firmware, but that would be in the future. Also, always happy to discuss it with others if anyone is interested.

[DMA]

In this context though - I do agree with DMA. We do need something better than QMK. While I like the widespread support it's gotten and the features it implements, I am not really happy with how it does some stuff and how it implements others. I do have an idea for my own firmware, but that would be in the future. Also, always happy to discuss it with others if anyone is interested.

Well, there's ZMK and kiibohd, and I have my own custom firmware of course.

[ifohancroft]

In this context though - I do agree with DMA. We do need something better than QMK. While I like the widespread support it's gotten and the features it implements, I am not really happy with how it does some stuff and how it implements others. I do have an idea for my own firmware, but that would be in the future. Also, always happy to discuss it with others if anyone is interested.

Well, there's ZMK and kiibohd, and I have my own custom firmware of course.

Tell me more about yours.

[DMA]

Tell me more about yours.

Not much to tell, really. https://github.com/dmaone/CommonSense, runs on previously-unobtainium, but now back in stock (albeit $20 now, not $15) CY8CKIT-059, passes USB2-CV, has no static protection. Can read capacitive, inductive and ohmic switches, can also be used as ADB-to-USB and Sun-to-USB converter.

MCU is ~$9.50@25 parts from mouser, needs ~4 capacitors, 2 resistors, USB protection chip and USB connector - so whole BOM is like $11 for a lot of 25.