Support for ARTSEY layouts

[ChrisChrisLoLo]

Great project! Really happy with how easy it was to get the firmware customized and flashed on my custom ch32 board!

What work would it take for smart-keymap to support layouts like ARTSEY?

The two biggest blockers I can see from being able to have an ARTSEY layout is:

• Need chording to support up to 4 keys (over the current limit of 2)
• Need support for overlapping chords (I'm assuming this is the case based on the nickel error I see here chorded_keys: multiple chords for key)

Really curious to hear about what would need to be implemented for these blockers (and maybe others that I'm not aware of) to be fixed. I think support for the above would put this firmware in the leagues of ZMK or QMK if it's possible

[rgoulter]

Need chording to support up to 4 keys (over the current limit of 2)

This explanation might sound complicated.

The reason chording is limited to 2: On the rust side of things, the key chording is implemented in key::chorded in src/key/chorded.rs.

• The chords are defined in key::chorded::Config, as an array of ChordIndices.

  smart-keymap/src/key/chorded.rs

  Line 50 in 95cb609

  pub chords: [Option<ChordIndices>; MAX_CHORDS],

• This ChordIndices is a rust enum, with one variant: Chord2.

  smart-keymap/src/key/chorded.rs

  Line 19 in 95cb609

  Chord2(u16, u16),

  (and also MAX_CHORDS is defined, for an conservative computation of the length of pressed key indices the Context keeps track of).

So, ChordIndices would need to have variants for Chord3 and Chord4 added, and the respective methods has_index and is_satisfied_by would need to be implemented. And for Context::sibling_indices, too. (Perhaps this method doesn't have the best name). As far as I can tell, the rest of the key::chorded logic doesn't assume chords are only two keys.

On the Nickel side:

• For the Nickel code generating the Rust keymap.json:

  • The code for generating the key chords is here.

    smart-keymap/ncl/keymap-codegen.ncl

    Line 1411 in 95cb609

    [i, j] => "Some(crate::key::chorded::ChordIndices::Chord2(%{std.to_string i}, %{std.to_string j}))"

• For the keymap.ncl processing code in keymap-ncl-to-json.ncl:

  • I don't think anything here assumes chord index length.

Need support for overlapping chords

Right, the question is what this would take. As you observed, on the Nickel side, the ncl/keymap-ncl-to-json.ncl assumes there are not overlapping chords:

• The main problem is the assumptions being made here

  smart-keymap/ncl/keymap-ncl-to-json.ncl

  Line 650 in 95cb609

  _ => std.fail_with "chorded_keys: multiple chords for key",

The reason this assumption is made is due to key::chorded::Key's definition. -- e.g. look at the integration test in Rust for an example of where things get defined.

smart-keymap/tests/rust/chorded.rs

Lines 21 to 37 in 95cb609

	const KEYS: Keys2<CK, AK, Ctx, Ev, PKS, KS> = tuples::Keys2::new((
	composite::ChordedKey::Chorded(chorded::Key::new(
	composite::Layered(composite::TapHold(keyboard::Key::new(0x06))),
	composite::Layered(composite::TapHold(keyboard::Key::new(0x04))),
	)),
	composite::ChordedKey::Auxiliary(chorded::AuxiliaryKey::new(composite::Layered(
	composite::TapHold(keyboard::Key::new(0x05)),
	))),
	));
	const CONTEXT: Ctx = key::composite::Context::from_config(composite::Config {
	chorded: chorded::Config {
	chords: [Some(chorded::ChordIndices::Chord2(0, 1)), None, None, None],
	..chorded::DEFAULT_CONFIG
	},
	..composite::DEFAULT_CONFIG
	});

-- I mean, at the moment, the 'chorded key' (the key that's output as a result of the chord being pressed) as defined on the key::chorded::Key, and that only allows 1. -- I think fixing this would involve either reworking this so that Key holds an array of keys for its chords. (Changing Config's chords to take in keys is an intuitive alternative solution, but, each src/key/*.rs is decoupled, so Configs never have any key definition values). -- Also, it gets a bit messy, since this array of chorded keys would need to be something like [Option<K>], because you can't just have [K; 3] with only 1 value. (Using an enum for number of overlapping chords would also be an option).

(There's some wiggle room: e.g. I believe at the moment, if you had a keymap "a b c" with chording over "X X " and "X _ X" and " X X", I think smart keymap currently does support this so long as the indices don't collide; but, it's 'tidier' and less obnoxious to always have chords defined with keymap indices in ascending order).

Aside from that, on the Rust side, key::chorded, the PendingKeyState::check_resolution method also assumes no overlapping chords.

smart-keymap/src/key/chorded.rs

Lines 601 to 617 in 95cb609

	match chords.as_slice() {
	[ch] if ch.is_satisfied_by(&self.pressed_indices) => {
	// Only one chord is satisfied by pressed indices.
	//
	// This resolves the aux key.
	Some(ChordResolution::Chord)
	}
	[] => {
	// Otherwise, this key state resolves to "Passthrough",
	// since it has been interrupted by an unrelated key press.
	Some(ChordResolution::Passthrough)
	}
	_ => {
	// Overlapping chords.
	None
	}
	}

If the Rust code can support overlapping chords, updating the keymap-codegen.ncl and keymap-ncl-to-json.ncl is a more straightforward thing to update.

others that I'm not aware of

smart-keymap/src/key/layered.rs

Line 18 in 95cb609

pub enum ModifierKey {

Currently, only "Hold" and "Default" layer modifier keys have been implemented. At a glance, looks like artsey requires toggle or sticky. -- I don't expect other layer modifier keys to be too difficult to implement.

[ChrisChrisLoLo]

Thanks for the thoughtful breakdown! It seems like there's at least 3-4 high level tasks one could do to get us to fully supporting ARTSEY (3 and 4 key chords, overlapping chords, toggle, sticky)

To me the most interesting one is probably overlapping chords, since that alone could probably allow me to make an alternate cording layout that gets us closer to ARTSEY. I'm not sure if I'll have the bandwidth in the immediate future to look at it, but I'll keep all of the above on my radar if or when I get the chance

[rgoulter]

It's tickled my curiosity, I'll have a go at these tasks.

I hadn't been aware of MaybeUninit in Rust's core: https://doc.rust-lang.org/core/mem/union.MaybeUninit.html -- This allows for a more natural implementation for the chord indices and overlapping chords than what I commented upthread.

Nickel's expressiveness also allows for a nicer way of expressing chord indices: #359

I see artsy's layer navigation uses "set active layers". Toggle wouldn't quite work.

[ChrisChrisLoLo]

That'd be awesome! I'd love to show off my project using it!

[rgoulter]

Some progress.

I was able to implement overlapping chords, as well as the "set active layers" modifier key.

I then had a go at implementing the artseyio layout in #373.

The next blocking issue is smart-keymap doesn't handle chords over tap-hold keys. (More precisely, keys with pending key states don't resolve correctly into other keys with pending key states).

In its current implementation, seems that this artseyio might be too big for the CH32X. There are likely different ways to reduce the firmware size so that it could.

Trying on an RP2040 board that I have, the artseyio implementation in #373 ... EDIT: seems good to me now.

[ChrisChrisLoLo]

Exciting stuff! Excited to play around with it when I get the chance! Thanks for adding a lot of this in and making a good chunk of the layout possible!

[rgoulter]

Some good news. @ChrisChrisLoLo

I do recall that when I'd tried it a month ago, the firmware size for the artseyio keymap was too large for CH32X. I tried it again just now, and it does seem to fit on the CH32X; although, it's close, at about 95% of flash size.

I did look into ways to reduce the firmware size. In #381 I rewrote the key system implementations from tree-base values, to a flatter struct of arrays. This has significantly reduced the firmware size. I think for the artseyio keymap, it got down to around 60% of the CH32X flash size.

[ChrisChrisLoLo]

That's HUGE! Thanks Richard, that's awesome to hear! Will try this out when I get the chance

[rgoulter]

Sure, try it out when you have time to.

Another update, I have also:

• added dedicated Consumer & Mouse key codes to smart_keymap,
• implemented consumer & mouse reporting in the ch32x firmware example (& in the rp2040 rtic example).

With that, mouse & consumer of artseyio (#373) should work without much more fuss for the keymap & HID reporting parts of things.