html lang="en" {
	head { m4_include(head.gsp) }
	body {
		header {
			div {
				h1 {-Framework is Awesome}
				m4_include(nav.gsp)
			}

			figure .quote {
				blockquote {
					p {=
						UNIX was not designed to stop its users from doing stupid things, as
						that would also stop them from doing clever things.
					}
				}
				figcaption {-Doug Gywn}
			}
		}

		main {
			h2 {-Table of Contents}

			ul {
				li {a href="#framework" {-Framework and the EC}}
				li {a href="#led" {-LED Fun!}}
				li {a href="#more" {-There’s More Than One LED‽}}
				li {a href="#hybrid" {-The Hybrid Key}}
				li {a href="#next" {-What’s Next?}}
			}

			h2 #framework {-Framework and the m4_abbr(EC)}
			p {-
				@a href="https://frame.work" target="_blank" {-Framework}
				— for those unaware — is the coolest laptop manufacturer ever.  Their
				whole @em{-shtick} is producing laptops that give the user the ability
				to easily and effortlessly disassemble, repair, and modify their
				hardware.  I highly suggest checking them out if you’re interested in
				computer hardware at all.  The laptops even have hotswappable I/O!
			}

			p {-
				Anyways getting back on topic, Framework has also been giving power to
				the user on the software-side of things too!  A good while ago they
				open-sourced the
				@a
					href="https://github.com/FrameworkComputer/EmbeddedController"
					target="_blank"
				{-code for the embedded controller}
				of their laptops, which offers all sorts of possibilities for
				customization of the keyboard, m4_abbr(LED) lights, and more.
			}

			h2 #led {-m4_abbr(LED) Fun!}
			p {-
				This is an area of the m4_abbr(EC) which I have not really looked at or
				touched much.  I do want to play around with this a lot more in the
				coming future though!  So far just for shits-and-giggles, I’ve patched
				the m4_abbr(EC) to make the power-button m4_abbr(LED) green instead of
				the normal boring white:
			}

			aside {
				p {-
					Just a tip: if you want to try any of these patches out,
					simply copy the diffs and paste them
					into @code {-git apply}.
				}
			}

			figure {
				figcaption {
					code {-~/board/hx20/led.c}
				}
				pre { m4_fmt_code(led.diff.gsp) }
			}

			p {-
				As you can see, it’s all fairly simple.  I just had to change our
				@code{-EC_LED_COLOR_WHITE} for @code{-EC_LED_COLOR_GREEN}.  The codebase
				defines a few colors, but they’re defined as m4_abbr(RGB) tuples which
				is awesome, because it opens the door to custom m4_abbr(RGB) effects in
				the future!
			}

			h2 #more {-There’s More Than One m4_abbr(LED)‽}
			p {-
				That’s right!  The Framework laptop I own (13″; the 16″ releases soon
				though!) has 3 more m4_abbr(LED) lights.  One on the left of the
				chassis, one on right of the chassis, and one on the capslock key.  The
				capslock m4_abbr(LED) acts as an indicator of whether or not you’ve got
				capslock enabled.  This is useless to me though, because my custom
				keyboard layout doesn’t even support capslock (see the next section) —
				so I patched it to be a function-lock indicator instead!
			}

			p {-
				Here’s the diff — but do take care if you want to apply similar patches
				to your laptop!  The files I’m editing are under @code{-board/hx20}
				since I’m on an 11th Gen Intel m4_abbr(CPU).  If you have a different
				m4_abbr(CPU), you will probably need to fuck with different code:
			}

			figure {
				figcaption {
					code {-~/board/hx20/board.h}
				}
				pre { m4_fmt_code(fn-lock-1.diff.gsp) }
			}

			figure {
				figcaption {
					code {-~/board/hx20/keyboard-customization.c}
				}
				pre { m4_fmt_code(fn-lock-2.diff.gsp) }
			}

			p {-
				As you can see, toggling the capslock m4_abbr(LED) is as simple as
				invoking @code{-gpio_set_level()}.  Not only that, but disabling its
				functionality with the capslock key is as easy as undefining the
				@code{-CONFIG_CAPSLOCK_SUPPORT} macro.  Figuring out if the function key
				is locked is also really easy.  The @code{-Fn_key} global variable is a
				bit-field containing information pertaining to the function key, and we
				also conveniently already have the @code{-FN_LOCKED} constant defined
				that we can bitwise-AND with @code{-Fn_key} to check the locked state!
			}

			p {-
				We also setup some hooks with the @code{-DECLARE_HOOK()} macro.  These
				just ensure that we are behaving properly on system resume and -suspend.
			}

			h2 #hybrid {-The Hybrid Key}
			p {-
				Wouldn’t it be cool if a physical key could represent two keys at the
				same time?  I thought so too.  Like all Emacs users, I suffer from a
				distinct lack of easily-accessible modifier keys.  I need escape because
				I use Vim bindings; I need left-control because all the Emacs bindings
				use it; I need super for my window-managers’ bindings; I need left-alt
				so I can type characters that don’t come on a standard American keyboard
				(such as @em{-ß}, @em{-€}, and @em{-é}), and now I have a problem.  All
				my modifiers are taken, but Emacs still needs a meta key to work!
			}

			figure {
				figcaption {-
					@cite{-Workflow} by Randall Munroe
				}
				img alt="XKCD Comic 1172" src="1172.png" {}
			}

			p {-
				What will I ever do‽  Well thanks to Framework making the m4_abbr(EC)
				open-source, and conveniently giving me a file called
				@code{-keyboard_customization.c}, I’m going to take two keys and stick
				them in one!  The basic premise is this: the capslock key is arguably
				the easiest modifier key to hit, and it’s currently bound to the escape
				key on my system.  This is inefficient though, because nobody makes
				key-bindings that chord the escape-key with another key;
				chords @x-ref{-1} are always done with a modifier like control, and
				Emacs is no different.  So my plan was to make it so that the capslock
				key when used on its own mimics an escape-key, while instead mimicking
				the left-control-key when used in a chord with another key.
			}

			p {-
				It took me a little longer this time to figure out how to implement what
				I wanted since the code isn’t as clear, but it was still a surprisingly
				easy feature to patch into the m4_abbr(EC)!  I basically just updated
				the scancode table, swapping out the capslock scancode for my own random
				one that I called @code{-SCANCODE_CTRL_ESC}.  I then created a new
				function called @code{-try_ctrl_esc()} which is called in the on-keyup
				and -down callback function.  The @code{-try_ctrl_esc()} function
				handles all of the logic as you can see in the following diff; it’s
				basically just a state machine:
			}

			aside {
				p data-ref="1" {-
					If you’re confused by what I mean by a “key-chord”, I am simply
					referring to pressing multiple keys in conjunction, such as when you
					press “@kbd{-Ctrl + C}” to copy text.
				}
			}

			figure {
				figcaption {
					code {-~/board/hx20/keyboard_customization.c}
				}
				pre { m4_fmt_code(hybrid.diff.gsp) }
			}

			p {-
				One thing that’s good to take note of is what I return from
				@code{-try_ctrl_esc()}.  The general pattern for handling a keyup or
				-down event is to stick the following code into
				@code{-keyboard_scancode_callback()}:
			}

			figure {
				figcaption {-
					@code{-keyboard_scancode_callback()} in
					@code{-~/board/hx20/keyboard_customization.c}
				}
				pre { m4_fmt_code(kbd-sc-cb.c.gsp) }
			}

			p {-
				In @code{-my_handler_function()} (or whatever you decide to name it),
				you attempt to handle the event.  If you don’t want to handle a
				particular event and instead want to pass it on to the next handler, you
				need to return @code{-EC_SUCCESS}.  If you managed to successfully
				handle the event though, then you need to return an error such as
				@code{-EC_ERROR_UNIMPLEMENTED}.  It’s pretty stupid and makes very
				little sense from a naming perspective, but oh well…
			}

			h2 #next {-What’s Next?}
			p {-
				m4_abbr(RGB) m4_abbr(LED)s maybe.
			}
		}

		hr{}
		
		footer { m4_footer }
	}
}