Move /srp to /blog

1 files changed, 229 insertions, 0 deletions

diff --git a/src/blog/fw-ec/index.gsp b/src/blog/fw-ec/index.gsp
new file mode 100644
index 0000000..acd39b9
--- /dev/null
+++ b/src/blog/fw-ec/index.gsp
@@ -0,0 +1,229 @@
+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 }
+	}
+}