Mapping International Characters

I Know you guys are incredible busy right now, but I really need a pointer on how to make flash work again. I have no idea what to try next.
Any hints are welcome. Thanks

You’re on a mac?
With the keyboard, give us the output of ls -al /dev/tty.usbmodem*

Alternatively, use the Arduino IDE to do your compile and flash. Its autodetection works better than ours does right now. (I have a branch that improves this for linux and know what to do for OSX. I just had to deal with flashing on WIndows 7 not working at all first)

I’ll try the IDE. Didn’t realize it could make a difference. Thanks

1 Like

So just to answer the question. The output:
crw-rw-rw- 1 root wheel 20, 8 Oct 28 09:15 /dev/tty.usbmodemCCkbio01

Same output with either usb port on my 2014 MBP. If I unplug it, the usbmodem goes away.

As an outsider I’d expect that using bash for the autodetection should be easy. :wink:

But I’ll just get the IDE installed and try that out asap.

2 Likes

…ish. That second C is surprising to me in the name. But the right way to do it is to use OS level tools to search by device and vendor ids.

Making sure you found the docs here:

I’ll be up a little longer and can help as well. We can definitely sort it out this weekend.

Thank you. It got it installed and managed to flash my keyboard with the IDE.
So I can move on with tinkering and you guys can get some well earned sleep :sleeping:

2 Likes

excellent! I’m hoping to get into documenting some of the more advanced tinkering this weekend. If you have questions don’t hesitate to ask!

So after trying a danish layout. My brackets button broke and so I am moving on with the unicode approach for now. It seems that there are only imperfect options with trade-offs I have yet to learn about :confused: I’ll just have to try and see, where I get the least amount of trade offs.

I learned that the HOSTOS_GUESSES doesn’t work for me. But setting the OS explicitly works.
I opened an issue on that matter on github:

I was hoping that the keyboard could wrestle the OS into not interfering with my layout. But from what I have learned so far, the amount of legacy around scancodes and shift behaviour is scary.

Not keyboardios fault. No sir! You guys are doing a great job. I was just kinda envisioning something, where I could just declare my layout and it would just work™, no matter the OS settings.

To make sure my layout will actually work at work, I might as well move on to developing and testing the layout on windows from now on.

2 Likes

The legacy aspect is kind of shocking, isn’t it? I had all kinds of ideas around separating shifted characters from their unshifted counterparts that I’ve put on hold for future study. :slight_smile:

I think, the way the community is starting to engage and contribute, we’ll end up in a place where the things it’s natural to do are doable, and eventually all this complexity will be hidden away in the guts of the system, and the average person will never need to learn about this stuff. Language based layout shifts and OS idiosyncrasies are thorny problems with a huge mess of cases and interactions, but hopefully once we traverse the graph it will settle out and just work.

It is fascinating having a kickstarter reward be the beginning of a process, not the end of waiting. I look forward to seeing where we are in a year.

2 Likes

The host os guessing hasn’t worked for me either, tbh…Looking at FingerprintUSBHost, it seems like we could do a lot to try to improve it, as it is very simple right now – as the comments there say, it is mainly a proof-of-concept by Jesse.

I don’t know much about how that might work, but I will give it a go at some point in the near future.

2 Likes

So with the real danger that I am exposing, that I have still not understood anything about shifting …

I hard coded the OS to Mac OS and set the keyboard to unicode.
So now I can map æøå to the fn layer. Yay!

Now I am trying to extend the macro to handle that if shift was pressed, it should send another unicode instead. But it doesn’t work. With shift the small letters are sent anyway.

Here is my macro:

static void unicode(uint32_t codepoint, uint8_t keyState) {
  if (!keyToggledOn(keyState)) {
    return;
  }
  Unicode.type(codepoint);
}

const macro_t *macroAction(uint8_t macroIndex, uint8_t keyState) {
  bool shifted = kaleidoscope::hid::isModifierKeyActive(Key_LeftShift)
              || kaleidoscope::hid::isModifierKeyActive(Key_RightShift);

  switch (macroIndex) {
    case L_AE:
      unicode(shifted ? 0x00c6 : 0x00e6, keyState);
      break;
    case L_OE:
      unicode(shifted ? 0x00d8 : 0x00f8, keyState);
      break;
    case L_AA:
      unicode(shifted ? 0x00c5 : 0x00e5, keyState);
      break;
  }
  return MACRO_NONE;
}

The bool shifted was lifted from @james.nvc bitbucket link at the start of this thread. So I was hoping it might just work.

Can any of you see what might go wrong with this code.

Ha, so I wrote that code before I had a keyboard to test on, and now that I do I also see that it doesn’t work. I will try to figure out what’s going wrong & report back.

1 Like

Thanks. I have never done any arduino before. I am mostly a java guy and I get stumped pretty fast in this environment :blush:

I am in the same boat, tbh :stuck_out_tongue: Just trying to read the source enough to figure things out…

Do you think this thread holds an answer?

Hrm, I’m not sure. Reading the source seems to indicate that the isModifierKeyPressed is ultimately checking the keyReport that Jesse talks about in that thread…my thought is maybe we’re checking this in the wrong place? I looked at the source for ShapeShifter, which checks if the shift keys are held in the same way that we’re trying here, but it does the check in the loop and refers to it later…I will give that a try.

(There’s also a wasModifierKeyPressed, but I don’t think that’s what we want either)

I wonder if it would be possible to map fn + shift to a new layer?

I think that would be straightforward enough to do by putting a ShiftToLayer(whatever) on the shift key in the fn layer.

I’m realizing that, for Linux at least, the situation for this may be complicated by the fact that entering Unicode characters entails faking holding down a shift key, which may be breaking this? I feel like it should work on macOS at least thought. I am a little confused.

1 Like

The reason why checking in the report does not work is that we clear the report each cycle, and fill it again. If your shift is later on the matrix than the unicode symbols, when we process the symbols, shift won’t be re-added yet. This is why ShapeShifter checks it in the loop hook too.

This is something we need to address one way or the other, because checking modifier state is going to be a very common thing.

1 Like