STRUCT MESSAGE(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’– NAME πŸ’–

okay bestie, welcome to the Kernel API Manual page for struct message(9) ✨ β€” and yes, this is literally struct message β€” a complete spi message. Not a fragment, not a side quest: the whole message. slay. πŸ’…

✨ SYNOPSIS ✨

struct message {
    __le16 type;
    u8 zero;
    u8 counter;
    __le16 rsp_buf_len;
    __le16 length;
    union {
      struct keyboard_protocol        keyboard;
      struct touchpad_protocol        touchpad;
      struct touchpad_info_protocol   tp_info;
      struct command_protocol_tp_info tp_info_command;
      struct command_protocol_mt_init init_mt_command;
      struct command_protocol_capsl   capsl_command;
      struct command_protocol_bl      bl_command;
      u8 data[];
    };
 };

πŸŽ€ Members πŸŽ€

okay so here's the member-by-member tea, no cap β˜•:

  • type β€” the message type. that's the whole vibe.
  • zero β€” always 0. vibe check: passed, fr fr.
  • counter β€” incremented on each message, and it rolls over after 255; there is a separate counter for each message type. πŸ”
  • rsp_buf_len β€” response buffer length (the exact nature of this field is quite speculative πŸ™ˆ). On a request/write this is often the same as length, though in some cases it has been seen to be much larger (e.g. 0x400); on a response/read this is the same as on the request; for reads that are not responses it is 0.
  • length β€” length of the remainder of the data in the whole message structure (after re-assembly in case of being split over multiple spi-packets), minus the trailing crc. The total size of the message struct is therefore length + 10.
  • {unnamed_union} β€” anonymous. iykyk 🫢
  • keyboard β€” Keyboard message.
  • touchpad β€” Touchpad message.
  • tp_info β€” Touchpad info (response).
  • tp_info_command β€” Touchpad info (CRC).
  • init_mt_command β€” Initialise Multitouch.
  • capsl_command β€” Toggle caps-lock LED.
  • bl_command β€” Keyboard brightness.
  • data β€” Buffer data.

πŸ¦‹ Description πŸ¦‹

okay so each message begins with a fixed header, followed by a message-type specific payload, and ends with a 16-bit crc. it's giving very structured, honestly. because of the varying lengths of the payload, the crc is defined at the end of each payload struct, rather than in this struct. periodt. πŸ’…

🌈 SEE ALSO 🌈

obsessed with these refs, honestly:

  • Kernel file: ./drivers/input/keyboard/applespi.c
  • struct keyboard_protocol(9)
  • struct tp_finger(9)
  • struct touchpad_protocol(9)
  • struct command_protocol_tp_info(9)
  • struct touchpad_info_protocol(9)
  • struct command_protocol_mt_init(9)
  • struct command_protocol_capsl(9)
  • struct command_protocol_bl(9)
  • struct spi_packet(9)

Catch you later, bestie 🫢 β€” this page comes from ./drivers/input/keyboard, dated October 2026, and it's filed under struct message(9). πŸ’–

πŸ“¦ where this page comes from