librelist archives

« back to archive

[custom keymap] Towards `C-i` as TAB and `C-m` as ENTER

[custom keymap] Towards `C-i` as TAB and `C-m` as ENTER

From:
eniotna
Date:
2015-02-21 @ 12:15
Hello,

I'm trying to customize the keymap to be able to make C-i send TAB and C-m
send ENTER.

The reason I want this is simply a matter of coherence to me.
I like those bindings which are natively present in emacs and in the
terminal.
So I just want to be able to do the same on all the software I used without
tweaking each and everyone of them (conkeror, or keysnail, or ...).

I asked Phil some time ago which answered me it's possible.
Here is the context:

Me:
>> If you have some time, just a quick question about the firmware, do you
>> think I'll be able to tweak the firmware to send <enter> signal, <tab>
>> signal with the so long desired C-m and C-i?

Phil:
> Sure. So this is possible, but it'd be a bit tricky. What you'd end up
> doing is turning control into another fn key that would activate a
> separate layer. This layer would be comprised of ctrl- combinations for
> most keys, but you could replace the ctrl-m position with enter and
> ctrl-i with tab.
>
> I think this would work better on the TMK firmware than my own
> atreus-firmware project since it handles layer-switching a bit more
> smoothly. I'm working out some quirks in it that make it awkward to
> bind modifiers with keys into keymaps and will post to the mailing list
> once that's sorted out:

I'm trying to do as described and I *think* that now I understand his
sentence.

Here is my failed tryout:
-

https://github.com/ardumont/tmk_keyboard/blob/qwerty-modified-with-ctrl-i-and-ctrl-m/keyboard/atreus/keymap_qwerty_modified.c#L21-L26

<https://github.com/ardumont/tmk_keyboard/blob/qwerty-modified-with-ctrl-i-and-ctrl-m/keyboard/atreus/keymap_qwerty_modified.c>
-

https://github.com/ardumont/tmk_keyboard/blob/qwerty-modified-with-ctrl-i-and-ctrl-m/keyboard/atreus/keymap_qwerty_modified.c#L34

I've uploaded this without apparent problem.
(I'm resetting manually connecting RST+GND because of the known issue on
reset via buttons).

```sh
# tony at dagobah in ~/repo/perso/atreus/tmk_keyboard/keyboard/atreus on
git:qwerty-modified-with-ctrl-i-and-ctrl-m o [12:54:28]
$ make upload KEYMAP=qwerty_modified
while [ ! -r /dev/ttyACM0]; do sleep 1; done; \
avrdude -p atmega32u4 -c avr109 -U flash:w:atreus.hex -P /dev/ttyACM0

Connecting to programmer: .
Found programmer: Id = "CATERIN"; type = S
Software Version = 1.0; No Hardware Version given.
Programmer supports auto addr increment.
Programmer supports buffered memory access with buffersize=128 bytes.

Programmer supports the following devices:
Device code: 0x44

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e9587
avrdude: NOTE: "flash" memory has been specified, an erase cycle will be
performed
To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "atreus.hex"
avrdude: input file atreus.hex auto detected as Intel Hex
avrdude: writing flash (15082 bytes):

Writing | ################################################## | 100% 1.14s

avrdude: 15082 bytes of flash written
avrdude: verifying flash memory against atreus.hex:
avrdude: load data flash data from input file atreus.hex:
avrdude: input file atreus.hex auto detected as Intel Hex
avrdude: input file atreus.hex contains 15082 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 0.11s

avrdude: verifying ...
avrdude: 15082 bytes of flash verified

avrdude: safemode: Fuses OK (E:C8, H:D0, L:FF)

avrdude done.  Thank you.
```

The remaining keymap works as the qwerty.

Does anyone with some time (or interest) to look at this see anything
strange in this definition?
Is there some simpler way?

Thanks for any feedback.

--

Also, I have another question regarding this, how can I go and test the
mapping?

I just triggered some non aware of those bindings and not configured
software.
And try to see if this now work with the new uploaded firmware.

I remembered `xev` and gave it a shot.
I see only the `ctrl` and the `m` (or `i`) appearing separately.

Thanks for your time.

tony / @ardumont

Re: [custom keymap] Towards `C-i` as TAB and `C-m` as ENTER

From:
eniotna
Date:
2015-02-21 @ 15:43
After some more reading documentations, failed tryouts, setting my hair on
fire :D, etc...

I came across some issue on the repository tmk/tmk_keyboard, it seems Phil
is somehow blocked with a similar issue:
https://github.com/tmk/tmk_keyboard/issues/184.

So I believe I misunderstood his initial answer. He may have been talking
about his own technomancy/atreus-firmware repository.

I'm trying to see what I can do from this repository...


tony / @ardumont

On Sat, Feb 21, 2015 at 1:15 PM, eniotna <eniotna.t@gmail.com> wrote:

> Hello,
>
> I'm trying to customize the keymap to be able to make C-i send TAB and C-m
> send ENTER.
>
> The reason I want this is simply a matter of coherence to me.
> I like those bindings which are natively present in emacs and in the
> terminal.
> So I just want to be able to do the same on all the software I used
> without tweaking each and everyone of them (conkeror, or keysnail, or ...).
>
> I asked Phil some time ago which answered me it's possible.
> Here is the context:
>
> Me:
> >> If you have some time, just a quick question about the firmware, do you
> >> think I'll be able to tweak the firmware to send <enter> signal, <tab>
> >> signal with the so long desired C-m and C-i?
>
> Phil:
> > Sure. So this is possible, but it'd be a bit tricky. What you'd end up
> > doing is turning control into another fn key that would activate a
> > separate layer. This layer would be comprised of ctrl- combinations for
> > most keys, but you could replace the ctrl-m position with enter and
> > ctrl-i with tab.
> >
> > I think this would work better on the TMK firmware than my own
> > atreus-firmware project since it handles layer-switching a bit more
> > smoothly. I'm working out some quirks in it that make it awkward to
> > bind modifiers with keys into keymaps and will post to the mailing list
> > once that's sorted out:
>
> I'm trying to do as described and I *think* that now I understand his
> sentence.
>
> Here is my failed tryout:
> -
> 
https://github.com/ardumont/tmk_keyboard/blob/qwerty-modified-with-ctrl-i-and-ctrl-m/keyboard/atreus/keymap_qwerty_modified.c#L21-L26
> 
<https://github.com/ardumont/tmk_keyboard/blob/qwerty-modified-with-ctrl-i-and-ctrl-m/keyboard/atreus/keymap_qwerty_modified.c>
> -
> 
https://github.com/ardumont/tmk_keyboard/blob/qwerty-modified-with-ctrl-i-and-ctrl-m/keyboard/atreus/keymap_qwerty_modified.c#L34
>
> I've uploaded this without apparent problem.
> (I'm resetting manually connecting RST+GND because of the known issue on
> reset via buttons).
>
> ```sh
> # tony at dagobah in ~/repo/perso/atreus/tmk_keyboard/keyboard/atreus on
> git:qwerty-modified-with-ctrl-i-and-ctrl-m o [12:54:28]
> $ make upload KEYMAP=qwerty_modified
> while [ ! -r /dev/ttyACM0]; do sleep 1; done; \
> avrdude -p atmega32u4 -c avr109 -U flash:w:atreus.hex -P /dev/ttyACM0
>
> Connecting to programmer: .
> Found programmer: Id = "CATERIN"; type = S
> Software Version = 1.0; No Hardware Version given.
> Programmer supports auto addr increment.
> Programmer supports buffered memory access with buffersize=128 bytes.
>
> Programmer supports the following devices:
> Device code: 0x44
>
> avrdude: AVR device initialized and ready to accept instructions
>
> Reading | ################################################## | 100% 0.00s
>
> avrdude: Device signature = 0x1e9587
> avrdude: NOTE: "flash" memory has been specified, an erase cycle will be
> performed
> To disable this feature, specify the -D option.
> avrdude: erasing chip
> avrdude: reading input file "atreus.hex"
> avrdude: input file atreus.hex auto detected as Intel Hex
> avrdude: writing flash (15082 bytes):
>
> Writing | ################################################## | 100% 1.14s
>
> avrdude: 15082 bytes of flash written
> avrdude: verifying flash memory against atreus.hex:
> avrdude: load data flash data from input file atreus.hex:
> avrdude: input file atreus.hex auto detected as Intel Hex
> avrdude: input file atreus.hex contains 15082 bytes
> avrdude: reading on-chip flash data:
>
> Reading | ################################################## | 100% 0.11s
>
> avrdude: verifying ...
> avrdude: 15082 bytes of flash verified
>
> avrdude: safemode: Fuses OK (E:C8, H:D0, L:FF)
>
> avrdude done.  Thank you.
> ```
>
> The remaining keymap works as the qwerty.
>
> Does anyone with some time (or interest) to look at this see anything
> strange in this definition?
> Is there some simpler way?
>
> Thanks for any feedback.
>
> --
>
> Also, I have another question regarding this, how can I go and test the
> mapping?
>
> I just triggered some non aware of those bindings and not configured
> software.
> And try to see if this now work with the new uploaded firmware.
>
> I remembered `xev` and gave it a shot.
> I see only the `ctrl` and the `m` (or `i`) appearing separately.
>
> Thanks for your time.
>
> tony / @ardumont
>
>

Re: [atreus] Re: [custom keymap] Towards `C-i` as TAB and `C-m` as ENTER

From:
Phil Hagelberg
Date:
2015-02-22 @ 01:21
eniotna <eniotna.t@gmail.com> writes:

> I came across some issue on the repository tmk/tmk_keyboard, it seems Phil
> is somehow blocked with a similar issue:
> https://github.com/tmk/tmk_keyboard/issues/184.
>
> So I believe I misunderstood his initial answer. He may have been talking
> about his own technomancy/atreus-firmware repository.

No, you had it right--jumping to the bootloader is totally broken in TMK
for me. I can copy the exact same bootloader C function from the
atreus-firmware codebase where it works into TMK and it will fail there.

My suspicion is that there is a fancy TMK feature that's interfering
with it; possibly one of the options set in the makefile, but I haven't
gotten the chance to dig into it.

-Phil

Re: [atreus] Re: [custom keymap] Towards `C-i` as TAB and `C-m` as ENTER

From:
eniotna
Date:
2015-02-22 @ 18:01
> No, you had it right--jumping to the bootloader is totally broken in TMK
> for me. I can copy the exact same bootloader C function from the
> atreus-firmware codebase where it works into TMK and it will fail there.

Yes! Ok.

So, I looked again at the code in the atreus-firmware and I think now I get
what I need to do. This is kind of similar of what I did in the
tmk/tmk_keyboard.

I need to play with the PRE_FUNCTION and the `layer_functions` array of
functions.
Then make the control behaves as the FN function by calling for example the
switch to another layer.

And you indeed told me this would need some more code manipulation. I
concur :D

As you said deprecation is one possibility, I will continue concentrating
on `tmk/tmk_keyboard` (in your atreus branch).

Thanks

> My suspicion is that there is a fancy TMK feature that's interfering
> with it; possibly one of the options set in the makefile, but I haven't
> gotten the chance to dig into it.

I'm still trying to figure things out on my absolute keymap... (I'd like
symmetry :D and I found out how with dual role key, but this broke what I
just reached about emacs bindings...).

If I find some time, I'll give it a shot (I have absolutely no idea where
to begin though...)
It's related to the reset which no longer works, right?


https://github.com/technomancy/tmk_keyboard/blob/atreus/keyboard/atreus/keymap_atreus.c#L33-L34

tony / @ardumont

On Sun, Feb 22, 2015 at 2:21 AM, Phil Hagelberg <phil@hagelb.org> wrote:

> eniotna <eniotna.t@gmail.com> writes:
>
> > I came across some issue on the repository tmk/tmk_keyboard, it seems
> Phil
> > is somehow blocked with a similar issue:
> > https://github.com/tmk/tmk_keyboard/issues/184.
> >
> > So I believe I misunderstood his initial answer. He may have been talking
> > about his own technomancy/atreus-firmware repository.
>
> No, you had it right--jumping to the bootloader is totally broken in TMK
> for me. I can copy the exact same bootloader C function from the
> atreus-firmware codebase where it works into TMK and it will fail there.
>
> My suspicion is that there is a fancy TMK feature that's interfering
> with it; possibly one of the options set in the makefile, but I haven't
> gotten the chance to dig into it.
>
> -Phil
>