Yamato 1.1.1

Fixed: Yamato could crash when you clicked the tray icon

Reported on Windows 10: a quick double-click on the tray icon closed the program with
"Yamato has stopped working". Single clicks, taken slowly, were fine.

Two of Yamato's windows could end up working on the same state twice at once. Several
ordinary Windows calls — showing a window, bringing it to the front, moving it, closing
it — deliver messages before they return, and those messages went straight back into
code that was already running. The guard that was supposed to stop that only covered
menus and dialog boxes, and the settings window was not opened through either.

That is the kind of fault that shows up on one machine and not another, which is why it
reproduced on Windows 10 and not on Windows 11: the older notification area reports a
double-click as two separate clicks, so the settings window was built and torn down
inside a few milliseconds.

Both windows now refuse the second pass. Measured before and after: the messages still
arrive, and none of them reaches the code that was overlapping.

Fixed: a settings window that never drew

If any single drawing step failed, Yamato left the drawing half-finished and every
later attempt failed too. The window stayed blank — the white panel in the bug report —
and stayed that way until the program was restarted. One unlucky moment cost the window
its drawing for the rest of the session. It now finishes the drawing whatever happens,
and rebuilds cleanly on the next attempt.

Fixed: the mode you pick from the tray now sticks

Choosing BIOS control or Smart from the tray menu lasted only until the machine
restarted, and then came back as whatever Start in said. Picking a profile from the
same menu had always been remembered; picking a mode had not, and nothing on screen told
you which was which.

A mode picked from the tray is now written down as the one to start in.

Manual levels are deliberately excluded. A fixed fan level holds with the firmware's own
thermal management switched off, and that is not something to restore unattended at boot,
so choosing one leaves the start-up setting alone.

Fixed: unsaved curve edits when closing settings from the tray

Closing the settings window with its own X saved your curve. Quitting Yamato saved
it. Clicking the tray icon to put the window away threw it out without a word. All three
now save.

Fixed: the About box on scaled displays

It was drawn at a fixed size regardless of your display, so on a laptop panel at 150% it
came out about two-thirds the size it should be, with type to match. It now scales
properly.

---

New: Check for updates

A Check for updates item in the tray menu. It asks GitHub for the latest release,
downloads the installer, and opens it.

Nothing installs itself. Yamato fetches the file and hands it to Windows; from there it
is the ordinary installer, which asks for permission on its own behalf, and you can stop
at any point.

Yamato also looks once, quietly, a short while after it starts. That check is silent
unless there is something new — no box on every logon telling you nothing has changed —
and it waits a little so it is not competing with everything else that runs when you log
in.

When there is a newer release you get three answers, because there are three things you
might mean:

Download it	Fetch the installer and open it.
Not now	Change nothing. You will be asked again next time.
Skip this version	Do not raise this release again.

Skip this version is remembered between sessions and applies to that release only —
the next one is offered normally, so skipping one is never a way to stop hearing about
the rest. And it never applies to a check you asked for: picking Check for updates
always reports what is actually published, even for a release you skipped earlier.
Closing the window without answering counts as Not now.

Downloaded installers go to a folder of Yamato's own inside your temporary directory and
are cleaned up the next time Yamato starts, which is the first moment one can safely be
deleted. Nothing is left lying around.

The update windows are drawn in Yamato's own colors, like the About box, and are sized
from their own text so nothing is cut off at any display scale.

---

Notes

• The update check talks to api.github.com over HTTPS and identifies itself as Yamato.
  It runs when you ask it to, and once shortly after start-up. It sends nothing about
  your machine.
• No new dependencies. The update check uses the copy of WinHTTP that ships with Windows.
• Nothing in this release changes how the fan is driven.

Yamato 1.1.0

Superseded by 1.1.1 due to close button regression.

Yamato 1.0.10

• add current version to settings window title

Thank you @FanDjango!

Yamato 1.0.8

• Opening/Closing Settings window: Remember position and Size
• Let right-click on the tray icon TOGGLE the settings window instead of just displaying it without toggle

Thank you @FanDjango!

Yamato 1.0.7

• left click on icon displays the settings panel
• change color of changeable settings
• add EC byte to the status display and change ordering

Thank you @FanDjango!

Yamato 1.0.6

Three fixes to how Yamato leaves the embedded controller, found while chasing a freeze on a P1 Gen 7. They are real defects and worth having on their own account. Whether they are the whole of that freeze is not settled, and this release should not be read as claiming so.

A command is never left half-issued. A register write is three bytes, a command then an address then a value, across two ports with no framing on them and no way to say "never mind" part way through. Yamato used to give up where it stood when the controller stopped acknowledging, which left the controller still counting and still owed a value it was never going to get. The next byte written to those ports became that value, whoever wrote it: Yamato's own next pass, Vantage reading temperatures, or Windows' ACPI driver opening a burst with 0x82. It landed in whatever register had already been addressed, and the writer was left waiting to be acknowledged for a command the controller never saw. Every command now finishes with the bytes Yamato chose even when the handshake fails half way through. The failure is still reported; the controller is simply left at a command boundary.

A lock taken from a holder that died now resyncs the controller first. Finishing our own timeouts does nothing for a process killed between two bytes, because then no Yamato code runs at all. Windows releases the mutex, the next holder is handed the lock, and the controller is still owed an operand with nobody left to send it. Nothing in the status register distinguishes that from idle: both read with the buffers clear. The only way to tell is to drive a whole transaction and see whether it answers, so that is what happens now, up to three times, since a command is owed at most two operand bytes and each attempt satisfies one.

It resyncs with a read rather than a write, and that is deliberate. The byte it puts on the wire while finding out is the read command, 0x80, which is also the value that hands the fan back to the firmware. The one stray byte a resync can land in the fan register is therefore the state the handback would have set anyway. Probing with a write risks pinning a fan on the way past.

The cross-process lock refuses instead of carrying on when it cannot be had. Yamato takes Global\Access_EC before touching the controller, the same mutex the other ThinkPad tools take, and it used to treat a handle it could not create as proof that nobody else was there. It means very nearly the opposite: that call fails when the name already exists under a security descriptor that shuts us out, which is exactly when another tool is arbitrating on the controller. It now tries a smaller open first, asking only for the right to wait and to release, and gives up rather than driving the controller unguarded if that does not work either.

Handing the fan back to the firmware is unchanged. It still chases the lock and still writes without it as a last resort, because a fan pinned at a fixed level with nothing managing it is worse than a byte written at a bad moment.

Yamato 1.0.5

The Mode row in the settings window is now a control, and it reaches a held level.

Clicking Mode steps through BIOS control, your curve, and a level you hold yourself. It used to be drawn like a reading and behave like one, sitting right next to a Profile row that opens a menu when you click it.

While a level is held, a Level row appears underneath and steps 1 through 7. It goes away again when you leave that mode.

Entering a held level inherits the level the fan is already running at, which in Smart mode is whatever your curve last asked for. The step changes who is deciding, not the speed, so it never arrives as a sudden roar or a sudden silence. Coming from BIOS control there is no level to inherit and it starts at 4.

Level 0 is not in the ring. The controller accepts it and Yamato refuses to hold it: it stops the fan with the firmware's own thermal management switched off, and the only way out of that is the temperature escape rather than the fan.

A sent mode is now held on the row until the engine's own sample agrees with it. Without that, clicking through the modes stuck: the engine publishes on its poll interval and picks a command up on the same pass, so for a few seconds every sample still described the mode you were leaving, the row snapped back to it, and the next click repeated the step you had just made. If a command never lands, the row returns to the truth on its own rather than reporting a mode nothing is running.

All three live rows say they are live now. Mode, Level and Profile take the same hover highlight the profile picker uses, and hovering any of them gives its description to the help text on the right, the way the settings rows already did.

Yamato 1.0.4

Memory.

The tray idles at about 2 MB. Opening the fan-curve window used to take the process to around 60 MB and leave it there until you quit. It now gives it back: roughly 28 MB with the window open, under 8 MB once you close it.

Two things were doing it, both measured rather than guessed:

• The window asked Direct2D for its default render target, which is a hardware one. That creates a D3D device, which loads the graphics vendor's user-mode driver into the process and keeps it there. It now renders in software, which costs a fraction of the memory and is not slower for a panel and a line graph that repaint about once a second.
• Closing the window hid it and kept everything behind it alive. It now destroys the window and releases the drawing state with it. Reopening builds a fresh one.

Also in this release: an About screen in the tray menu, with the attributions, the warranty disclaimer and the hobby-project note; and a fix for a short stall when the tray was checking the PawnIO driver version.

Yamato 1.0.3

Add about screen, test CI pipeline.

Yamato 1.0.2

Machines whose embedded controller lives at 0x1600 now work. Nothing to
configure: Yamato works out where the controller is the first time it starts,
and remembers.

Reaching the controller on more ThinkPads

Most ThinkPads answer at the ACPI ports 0x62/0x66. Many keep the controller
at 0x1600/0x1604 instead, which is not a quirk of one model but the
machine's own interface, mapped to LPC channel 3 of the Renesas H8S the ECs are
built on. Linux's tp_smapi has driven exactly those ports for twenty years.
Yamato could not reach them at all.

It reaches both now, through two PawnIO modules that ship together. At the
first start it probes each one, checks it can actually control the fan rather
than merely read it, writes down which layout this machine uses, and never asks
the hardware again. Later starts load the module the settings name and go
straight to work.

If detection ever gets it wrong, Settings has a Controller mode row at the
bottom with Standard and Compatibility. And when the controller cannot be
reached, the tray now says which mode to try instead of leaving you to find it.

Also

• PawnIO 2.2.0 or later is required. Older versions can blue-screen Windows
  10 1809, 19H1 and 19H2 while reaching the controller, and 1809 is a version
  Yamato supports. The installer checks, and so does the program.
• A TPFanControl curve using the disengaged setting (0x40) now imports as
  the firmware step rather than level 7. Level 7 is a manual level, and a
  manual level switches the firmware's own thermal management off at the
  hottest point of the curve. The firmware step keeps it on.
• A byte order mark in config.json no longer costs you every setting.
  Some editors add one to UTF-8 files unasked; the parse failed and the machine
  quietly ran on defaults while the real settings sat on disk.

Notes

The standard layout is confirmed on hardware. The 0x1600 layout has been
measured reaching a real controller and driving a real fan, on a machine that
does not need it, so a report from a machine that does is welcome. The
application event log records which layout was chosen and why.

0x40 is still refused everywhere a level can enter. That is a considered
difference from TPFanControl, not a gap; if you need it, TPFanControl and its
forks are still there and still good.

Comes with absolutely no warranty. See LICENSE. Not affiliated with, endorsed
by, or supported by Lenovo.