kodeOS internals

Sheets and cards

The full-glass card kodeOS reuses for every page, the system cards and their shared frame, the keypad, the details of an app and a launch.

What it is

A sheet is a card that covers the whole glass. kodeOS builds one and writes a different page on it each time. The pages are:

• The pages of the settings screen, in kshell's rail dress: Wi-Fi, Bluetooth, Settings and the six pages Settings opens (Screen, Battery, Time zone, Kody, Self-test and About), and the lists of choices (the zones and the auto-lock times).
• The keypad, which a row of the Wi-Fi page opens to type a password or the name of a hidden network.
• The details of an app, which TOP held or a finger held opens over a row of Apps, and the two cards Remove adds.
• The system cards: the write screen and Didn't open, Stopped, Critical battery, Turn off, the Bluetooth pairing code and the two cards of the factory reset.

A sheet has at most one button, such as Remove, Try again or Run again. BOT closes it, and so does a finger that goes down on the header of a card. The screen writes BOT for the bottom button. The write screen and the Removing card stay until their work ends. A list of choices and the keypad close back to the page that opened them. A settings page goes back one level with BOT or a swipe right. A system card takes no drag, except Turn off, which a swipe down closes; BOT alone closes the others, or answers no where the card asks a question.

Some words name the marks and colours of a sheet:

• The ring is the yellow outline that marks the selected row or button. The pad moves it.
• The Ring, with a capital, is the circle or the line that fills while a button is held and turns while something is waited for.
• The accent is Kody Blue, the colour of a radio that is on and of the chosen thing.
• Level yellow is Bold Yellow, the colour of a level such as the brightness, and the ground of the one primary answer of a card.
• Off grey is the warm charcoal (KUI_COLOR_OFF) of a switch that is off.

An answer has a role: primary, secondary or tertiary. The ink of a text is Soft Black or Light Grey, whichever reads on its ground.

How it is connected

flowchart TB
trig["a row, a hold, a write,<br/>a pairing, the system"] -- "gui_sheet_open_kind()" --> sig["GUI_SHEET_OPEN_SIG"]
subgraph gui["AO_Gui"]
  face["Gui_awake"] --> sf["Gui_sheet_face"]
  brow["Gui_browsing"] --> sh["Gui_sheet_home"]
  set["Gui_settings"] --> ss["Gui_sheet_settings"]
end
sig --> face
sig --> brow
sig --> set
sf --> card["the one sheet<br/>on lv_layer_top()"]
sh --> card
ss --> card
class sf ao
class sh ao
class ss ao

One object, built once

ui_build() calls kui_sheet_create() on lv_layer_top(), the layer LVGL keeps above every screen, so one card covers the face, Apps and Settings without any of them knowing. The sheet is built at startup because a card created while a Bluetooth peer waits would spend the security manager's clock on an allocation.

• The blocker is the transparent root, as large as the glass and clickable. It takes every touch while the card slides. It has no callback: a press that opens a card can still be down when the card appears, and the lift would arrive as a click on the blocker and close the card at once.
• The card is the part you see. An animation moves it between y 0 and 502 (GUI_SHEET_HIDDEN_Y).
• The sheet slides with an lv_anim and not a screen load, which keeps it off the path that can freeze the interface.
• A system card rises on a spring instead, and the details open with the sheet's own rise.

Only one card exists at a time. When another page is wanted while a card is up, such as a pairing during a write or a zone list from the Time zone row, the same card is refilled (gui_sheet_fill_again_as()). You see its content change, and no second card slides in.

Three shells

QP gives a state one parent and a card can rise over three screens, so there are three short states, Gui_sheet_face, Gui_sheet_home and Gui_sheet_settings, each a child of its screen. Each calls the same gui_sheet_body(), which holds everything a sheet does: Q_SUPER(home) for what the sheet does not answer, Q_TRAN(home) for the close.

A transition from a child to its own parent runs no entry action, so the screen under the card is never reloaded.

Each shell swallows the auto-lock, the unlock, the door to Rest and the settings door, busy or not, because a door travels through the queue and could arrive after the card it was not meant to meet. GUI_LOCK_SIG and home are the two it answers.

How a card opens

gui_sheet_open_kind() posts the kind and whichever screen is up answers with its shell. Over the face (awake or at Rest) only a system card that opens no page behind it may rise: the write screen, Didn't open, a pairing, Stopped, Critical battery and Turn off. gui_sheet_open_taken() refuses every other kind there, because a settings page over the lock screen would open the board from behind. A list of choices and the keypad open only in place over their own page.

Two bodies

• A sheet with rows shows a column of pill rows in body: the pages of Settings and the two lists of choices.
• A sheet with text shows three lines, a note, a large code and one answer button, all permanent children of the card that the kit hides and C shows.
• The keypad is neither: kgui_keyboard.c builds a field, a pill and twelve keys on the card.

me->sheet_n says which is up, and the pad's grammar follows it.

What closes a card

This is the whole list of causes. Anything else leaves the card up, so a page never vanishes while you read it. The auto-lock never closes a card.

A busy sheet answers no pad button and no touch: the write screen and the Removing card. The board does something a person cannot stop. They still disarm the presses they swallow, swallow HOME.

Specifications

The kinds

Every kind of card, what opens it and what it shows.

The geometry

The kit decides it (kui_sheet.c). Pixels on the 410 x 502 glass.

The settings pages do not wear the header disc: they stand in kshell's dress (internals/gui/settings-screen), with a centred title and a flat list of rows. Wi-Fi and Bluetooth wear a header of their own, the radio's disc, name and state, and their switch stays at the top while the rows under it scroll.

The system cards

A system card is a card the system raises, not a page a person opened. One table in kgui_ao.c, gui_syscard_of(), lists them, and every question about which kinds are system cards is asked of it: whether a kind is a system card, whether its answer is a hold, and whether it may rise over the face.

Every one of them may rise over the face. The rule is the same for every row:

• Raised by the system. A write, the failure of a write, a pairing, an app that stopped, a nearly empty cell or the hold of BOT on the face raises the card. It takes no drag, and the only tap that acts is the one on its button.
• Rise. A system card with no card under it rises from the bottom edge on a critically damped spring of 180 ms (KGUI_RISE_PERIOD_MS) and leaves in 160 ms. A veil in the card's colour lies over its content and clears over the last tenth of the way, so the text and the button are not there before the card is up.
• A gate of 700 ms. The card ignores every input for 700 ms (KGUI_RISE_INPUT_MS) from the moment it began to rise, landed or not: the pad, the click of the button, TOP, and a held BOT. A press that began under the gate answers nothing even when its lift comes later.
• A press already down is nobody's. A finger that is down as the card arrives, and a BOT that is down, are made to wait for their lift. The lift clicks nothing under the card, and the held button closes no card and locks nothing over it.
• Home closes it where it can be closed, over the face as over Apps. The face stays locked. The hold of the thumb that woke the face is not a door.
• A system card that takes over another in place (the write screen by Didn't open) does not rise again. Its gate shuts again for 700 ms.

The button of Turn off is the red one: a tap or TOP released confirms, and the card asks first, as the question of a card must.

The system frame

kgui_sysscreen.c draws the frame of every system card, adapted from the system screens of kshell. The frame is a black page with the edge along the glass: a line 24 px wide whose outer side is flush with the glass, with corners of 102 px, over a dark track. Inside the edge stand these parts, dressed for each card:

• The protagonist is small, with its middle at y 104: an app's disc of 88 px, a glyph scaled to 96 px, a word, or the red battery of the Critical battery card.
• A write's face: the share in kui_font_hero_160 (DM Sans Bold 160) with its top at y 172, the % under it in kui_font_display_40 at y 300, the name at y 359 and a second line at y 403, and small print at y 431.
• A card's words: a name at y 160, a second line 46 px under it and up to three lines of detail, each 40 px under the one before. The words are centred in 350 px from x 30.
• A pairing's code in kui_font_code_80 (DM Sans Bold 80) at y 160.
• The pill with its top at y 370, 72 px tall and at least 173 px wide, with room for its yellow focus ring.

The edge has forms of its own: it fills with the percentage of a write, it spins while something is waited for (22 steps make a lap of 1,980 ms), it closes in 297 ms when the work is done, turns green and pops, thickening by 8 px and back, and it is cut when the work failed: it turns resting grey and a red dot of 15 px stands where it stopped. kgui_edge.c holds the curves with no LVGL, and a host test walks them.

The Ring

The Ring is one module, kgui_ring.c, for the progress and the waits of the interface. A Ring is made once and moved by number, so a pass allocates nothing. It has three shapes and several forms.

• The circle is one LVGL arc that starts at the top and fills clockwise over a track. The launch turns one round the icon, 144 px across with a line of 12 px.
• The screen Ring is a line that follows the edge of the glass, 12 px wide and 6 px in, over a track. It starts at the top middle. It lives on the card of the sheet and serves the write screen.
• The edge of the system frame, above.

The forms:

kgui_ring_pct_at() and kgui_ring_spin_at() are the model, with no LVGL in them.

The ink on a ground

A text that stands on a ground asks gui_ink_on() for its colour. Soft Black or Light Grey, whichever has the better contrast. Light Grey on Kody Blue or on Bold Yellow is the pairing the brand forbids, and a hand-written colour on a row would bring it back.

The rows that change in place

Four rows of the Settings list are settings that change where they stand, each with its value on the second line. No page opens for them:

A row that steps is Light Grey. A switch is Kody Blue while on and the off grey while off, and its second line says what it does, so colour is never the only sign.

The ring starts on row 0, so left and right change the brightness as soon as the page is up. A change applies at once, is stored, and is logged as <key>: <word> (stored). The same code serves the console, so a value changed there rebuilds the page too. A change clicks after it is made, so the level of haptics you chose is the one you feel; a change to Off is silent.

The brightness. Left and right change the level by 5 % (GUI_LEVEL_STEP), never below 10 % (GUI_BRIGHT_MIN_PCT), because zero would blank the screen that shows the control. config key="bright" keeps its own range, 5 to 100. A finger on the bar sets the level at its x and a drag follows it, at most one change per 50 ms (GUI_LEVEL_DRAG_MS). Every change goes to AO_Display with display_brightness_request(pct, persist). A press and its drag samples pass persist false and the lift writes once, so a drag of twenty samples a second never writes twenty times. The row clears LV_OBJ_FLAG_SCROLL_CHAIN and sets LV_OBJ_FLAG_PRESS_LOCK, so a drag on the track never scrolls the page.

Wi-Fi

The Wi-Fi page has a header: the Wi-Fi disc, the name, and Off, On or the network the board is on. Row 0 is the switch, always, and it stays at the top of the page while the rows under it scroll: accent when the service is on, KUI_COLOR_OFF when off, with on or off on its second line. With the service off it is the only row, over the line "Turn it on to see the networks near you". With it on, these follow:

1. The network the board is on (accent, check glyph, Connected, -58 dBm).
2. Kode ecosystem, while the board is linked. Its second line follows the channel's state (below).
3. The networks the board remembers, most recently used first, minus the one it is on, with the lock glyph: Saved, or Saved, -60 dBm while the scan finds it.
4. The networks found by the scan, minus the ones already shown and the ones that hide their name (Open, -71 dBm or Password, -71 dBm, with the lock glyph on those that need a password). Until a scan has found anything the page says Looking for networks..., or No networks found.
5. Hidden network, the last row, with the second line Type its name.

What TOP does on each row:

Rows follow WIFI_STATE_SIG, never the press. While the page is open and the service is on, it scans by itself: a scan and a listing of the remembered networks on its first tick and every 10 s (GUI_WIFI_SCAN_MS) after the last answer, never while one is out. There is no row to search again. The channel's own switch is config key="chan".

The keypad

The keypad types a password or a hidden network's name on twelve keys, the way a phone with no touch screen did. It opens in the place of the Wi-Fi page. The card shows, from the top down:

• The title: the name of the network, or Hidden network until the name is in.
• The field, a dark capsule. A password shows as dots except the last character, which stays plain while pending and for 1 s (KUI_MULTITAP_SHOW_MS). A name shows plain. An empty field asks for Password or Network name.
• The yellow pill: Join for a password, Next for a name.
• The Show password row with a switch, for a password only.
• Twelve keys in four rows of three: 1 to 9, then the mode key, 0 and Delete. The mode key wears abc, ABC, 123 or #+=.

The card has no header disc. The pad moves the focus over the controls, TOP presses the control with the focus, and a tap presses the control it lands on. The focus opens on the key 5. The keys type by multitap, the rules of kui_multitap (sdk/kui): the same key pressed again within 800 ms replaces the pending character with the next one of the key. A password holds up to 63 characters and a name up to 32; at the cap a press that would add a character is refused with the hint Password is full or Name is full.

A hidden network has two stages, the name and then the password. Next with nothing typed shows Type the name; Join with nothing typed shows Type the password. While the radio scans, Join shows Scanning, try again. While the join is out, the field says Joining, the pill is dimmed and no control acts; BOT, home and the lock still leave.

The card reads WIFI_STATE_SIG as the answer:

DISCONNECTED covers both a wrong password and a network out of range, and Wrong password is the driver's best word for it.

The text is a secret. It lives in kgui_keyboard.c and nowhere else: in the multitap's buffer and in the 64 plain characters the field shows. It is not in the Gui struct, a log line, gui_info or any event but the join request, which carries its own copy. The module zeroes both buffers through a volatile pointer on every road away from the keypad. While the keypad is up, AO_Gui holds the log tags kaos.buttons, kaos.touch and kcli at NOTICE with kode_log_hold(), writes its own gesture lines without coordinates, and writes no haptic: line, so a log read in order would not spell the password. gui_info says keypad: <stage>, mode <word>, show on|off and nothing of the text, not even its length.

Bluetooth

The Bluetooth page has a header: the Bluetooth disc, the name, and the name the phones see. Row 0 is the switch (Off, On, or Visible while advertising), and it stays at the top of the page as Wi-Fi's does. With the stack off it is the only row. The page lists no devices and runs no scan. With the stack on, three more rows can appear:

• Console (Connected) appears while a central is subscribed to the console's output.
• Paired shows N devices.
• Forget all (danger colour) appears when N is above 0. It calls ble_unpair_request(). AO_Radio refuses while a central is attached, and the row's second line says Disconnect first.

Console and Paired are readings. The circle on the control centre pulses at 1 Hz while the radio advertises; the switch row does not.

Battery

Every row is a reading and nothing acts. Row 0 is a bar with the percentage. Then the flow (Charging, Charged or Discharging) with the current in milliamps, then the cell voltage, and, once the gauge reports a value from -20 to 80 degrees C, the temperature. Readings move in place; the page is rebuilt only when its shape changes. The temperature is asked of the gauge every 30 s.

About

The rows of the About page, with the ring starting on kodeOS. The zone and Kody's pack are rows of the Settings page.

Factory reset is the last row and Update the one before it, on purpose: a press that rewrites the OS or erases the unit must not be one that can happen by accident. The row stays enabled without the file and its second line says there is none. During the write the write screen reads Updating with the name kodeOS.

The lists

The list of zones has 21 rows, west to east, the zone in force checked in accent and a Custom zone checking none. A pick asks AO_Boot to take the zone with the same config key="zone" set a console line makes (gui_zone_pick()), then goes back to the page. AO_Boot applies and stores it in kset/zone, and its answer repaints the face and the Time zone row. The list of auto-lock times has six rows, 30 s, 1 min, 2 min, 5 min, 10 min, Never, and a pick stores kgui/lock and goes back to Screen.

How a list answers input:

• Up and down move the ring with wrap, TOP or a tap picks, and left and right do nothing.
• BOT, a swipe right or a drag down on the header go back to the page with nothing changed.
• BOT held takes the whole card away to Apps' root.
• Both lists open with the current choice under the finger that opened them, so a second tap picks the same choice again.

The 21 zones and the POSIX TZ string each one stores:

The Kody card

The Kody page says which pack plays and where it comes from. It has one capsule.

Small print says why the button is missing, or what it does:

• Connect Wi-Fi to update.
• Wait for the write to end.
• The card's pack is in use. Updates go to the Dot.
• Replaces the pack on the Dot. Your own scenes go on the card.

Update fetches the pack named by CONFIG_KGUI_ASSETS_URL into the internal FAT and never writes the card. The install is on internals/gui/kody-pack.

The details and Remove

The details of an app and the two cards of Remove are described with the rail they open from, on internals/gui/launcher. In the sheet they are the kinds DETAILS, REMOVE and REMOVING. kgui_details.c builds the page once on the card and takes the kit's handle and header disc off the screen; kgui_dtext.c writes the size, the build date and the line under the name. The whole card is its header, so a drag down from anywhere on it closes it.

Launching an installed app

The launch of an installed app is a short scene on the layer above everything. The icon leaves its row and flies to the middle of the glass while the screen darkens under it. A Ring turns round the icon. Then the Ring closes in green and the icon pops, the screen fades to black, and the board resets into the app. The scene shows no words: the icon and the Ring are all there is.

The scene covers the glass and takes every touch. While it runs, Apps under it is locked: no pad, no touch, no Settings, no home and no lock. It starts only from an icon that is on the screen: the row the launcher launched, or the disc of the Stopped card. A launch with no icon to start from takes the write screen at 100 % and asks for the run at once.

gui_launch_tick() steps the scene before the pass that draws. When the fade is over, it logs launching <name> (the fade is over), arms a 3 s wait (GUI_OPEN_RUN_MS) and calls appmgr_run_request(). AO_Boot then writes the boot request. A run AO_AppMgr refuses turns the card into Didn't open after the 3 s.

The write screen and Didn't open

A flash write shows two kinds of card on the system frame: the write screen (opening, the Opening card of the pages about AO_AppMgr and AO_Storage) and Didn't open (failure). A flash write never uses the loading screen.

The write screen shows how far a write has gone. The edge fills round the glass, and the share stands in the middle in kui_font_hero_160 with its % under it. A small protagonist stands above: the app's disc, or a glyph for the system. Under the figure stand the name and a second line. It is busy: it answers no pad button and no touch, and BOT does nothing.

How a write ends. The figure follows APP_FLASH_PROGRESS_SIG. When a write that runs reaches its end, the edge closes in 297 ms and the figure climbs to 100 with it; the edge turns green and pops, the second line says Opening, and only then is the run asked for. A write that does not run closes the same way, the card leaves, and both lists of apps are asked again because the directory changed. The write screen of a run carries the small print Hold BOT+LEFT to come back. A write of the OS publishes no done event and ends with the restart into the new kodeOS.

Kody's writing and goodbye animations are not played by any screen in this interface: the write screen shows the edge and a figure, and an app runs when the edge has closed.

Didn't open is the write screen filled again. The edge is cut: it turns resting grey and a red dot stands where it stopped. The title is Didn't open, Didn't install or Didn't update, with the name under it and three lines of why. The pill says Try again when the request can be repeated, and Close otherwise. Try again asks the question again, and for a file it asks which apps the write would evict first, because the failed write may have evicted apps already. A refused launch, an install that fails and a run that never took the board away turn the write screen into this card. The card does not leave by itself.

Making room

An install of a file from the SD card asks no question. The apps region keeps its apps oldest first, and when the file does not fit, the oldest apps make room for it, as install does from the console. AO_AppMgr copies each app it pushes out to the SD card before it removes it; a copy that fails stops the install with nothing removed.

The install begins with a question to AO_AppMgr, in two stages that gui_info shows as launch: asking and writing. AO_Gui calls appmgr_evict_query() with the size and project name; AO_AppMgr answers one entry for each app that would go and an end marker.

• busy: AO_AppMgr could not look. AO_Gui asks again after 150 ms, up to 4 times, then says Busy. Try again.
• The image is bigger than the region: nothing is written and the hint says Too big for this Dot.
• It fits, with or without apps to push out: the write screen rises and the write starts. The log says install: <n> app(s) make room for <app> when some go.
• A locked card is up while apps would go: the install is given up with Busy. Try again.
• No answer within 1,500 ms: the hint says No answer. Try again, and a late answer is ignored.

There is never more than one question out. An end still missing 35 s after its question is taken as lost, so one dry event pool cannot block the installs for good.

Stopped

When a board comes back from an app that panicked, hit a watchdog or lost its supply, the Stopped card rises over Apps. The system frame shows the face of the app that ran, its name, and Stopped. The body gives one line of why:

The small print under it is Hold BOT+LEFT and to come back. The button is Run again, the yellow pill, and it is there only when the app is in the list. When no installed app sits where the app ran, the card says An app and has no button. A clean end shows no card, and an end that cannot be told reads as clean, so a healthy app is never accused.

Run again plays a click and launches the app as Apps launches any app. A run that is refused turns the card into Didn't open. BOT closes the card, and Apps stands as it was.

Critical battery

When the charge falls to 10 % or less (KGUI_BAT_CRIT_PCT) and the cell is not charging, the Critical battery card rises. The system frame shows a red battery with a sliver of charge, the name Battery and the second line Critical, <n> %. The detail says Plug in the cable., and The cable is in. while a cable is in. The card follows the charge and the cable while it is up. It has no button; BOT closes it.

The card rises over any screen, the face at Rest included, where its arrival lights the screen. It rises once for each entry into critical. A charge that wobbles around the line is not a new entry: the card can rise again after the charge climbs 3 points (KGUI_BAT_CRIT_REARM_PCT) above the line, or after the cell charges. A board that has not read a charge above 0 % yet raises nothing, because a gauge that reads no cell says 0 % on every reading. It does not rise over a locked card, another system card or a guided test.

Turn off

The Turn off card asks to confirm that the board switches off. The board never does this by itself. Two things raise it: BOT held on the face for 5 s after the red arc has filled, and the Turn off circle of the settings screen. The system frame shows a red power glyph, the title Turn off? and two lines: Hold the red button and to turn it on again.. The card has one red Turn off pill.

When a cable is in, the board does not switch off: AO_LowPower refuses the request. So the two lines give way to Not while USB is in and the pill is grey. The pill is still there, because AO_LowPower is the one that refuses, and it says why over the screen as a hint.

For 700 ms after it began to rise the card answers nothing. Then:

• TOP released, or a tap on the pill, confirms. The card asks and the button confirms: there is no hold.
• BOT released answers no, and closes the card with nothing done.
• A swipe down answers no too, at the lift, and the swipe must be at least 40 px.

gui_off_ask() raises the card and logs turn off? asked (<why>). A confirmation logs turn off: confirmed and calls gui_power_off() once. That function logs power off requested before it calls kode_power_off(), and AO_LowPower asks every owner to rest and turns the board off (internals/power-and-sleep).

Pairing

When a central connects to the BLE console the board picks a six-digit passkey and the pairing card rises with it, broken after three digits (482 913), in kui_font_code_80. Two lines read "Type this code" and "on the other device". The system frame shows the Bluetooth glyph as its protagonist, with the title Pairing and the second line Another device. The card has no button.

The digits go nowhere else: no log line carries them, because AO_Log copies every line to the BLE console and a paired peer would read the next one's code.

The outcome replaces the digits for 1.2 s, then the tick posts the close. Leaving the card in any other way while the code is live refuses the pairing in the shell's exit, so the peer fails at once. A busy sheet, Gui_btn_test, Gui_tp_test and Gui_selftest refuse a pairing outright, and a write that takes the card over refuses it through gui_pair_yield(). The pairing policy is on internals/ble-console.

Self-test

The first row, Run the test (level yellow), starts the whole-unit check. Under it come the rows of the last run in plain words (Charger, Touch, Card slot):

• OK on green with a check.
• Problem on danger with the row's own line such as Light not working.
• No answer and Skipped with no icon.

Problems come first and the header counts them (13 Oct 09:41 - All good, 1 problem), in the face's time zone. Small print says Tap a row to test it again, and TOP or a tap on a row of the last run repeats that one row.

When a run starts the screen stops being a sheet and AO_Gui enters Gui_selftest, which shows the loading screen with Kody in his wheel. The line under him reads:

AO_Autotest owns the rows and the report (sdk/kaos/autotest). The auto-lock does not count during a run, and a stopped run keeps no report. After a run, the board opens Settings and then the Self-test page.

Gotchas

Example code

Pair a computer over Bluetooth and watch the card:

1. Open a console session over the USB-C cable first. Opening the port resets the board, and attaching the cable after the card is up would end the pairing.
2. Clear the bond on both sides, on the board with Forget all on the Bluetooth page and on the computer in its Bluetooth settings.
3. Attach over Bluetooth from the computer. The pairing card rises with a code such as 482 913. For 700 ms it answers no button.
4. Type the code on the computer. The card reads Paired for 1.2 s and closes.
5. Repeat and press BOT while the code shows. The card closes and the computer reports a failed pairing at once.

In the SDK

• kui_sheet.c: the kit's sheet, built once by kui_sheet_create().
• kgui_ao.c: the three shells, gui_sheet_body(), gui_syscard_of() and every page's fill function.
• kgui_sysscreen.c and kgui_ring.c: the system frame, the edge and the Ring.
• kgui_assets.c: the update behind the Kody card.