| Age | Commit message (Collapse) | Author |
|---|
|
since we have auto-detection now, we only need to know
that two signals exist, not that they are valid, since
the auto-detection now handles validation and fallback.
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
a continuation of the previous patch. this waits for
currently one second, before defaulting to the hardcoded
value. otherwise, it tries to use whatever timing it
gets automatically.
this way, the program should now reconfigure its own
timing, without intervention by the user, if the timing
differs from sensible defaults.
this is because spkmodem is implementation-defined;
it's just however coreboot and/or GRUB happen to set
it up, and on the hardware in question.
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
current logic is hardcoded, as in the original spkmodem-recv.
with this change, small differences are observed and averaged,
then the detection thresholds are adjusted accordingly.
the existing macros serve as a baseline, but real signals
differ. with this change, we therefore account for possible
drift in timings, which can change in real-time; the old
code could possibly get out of sync beccause of that, which
may have resulted in corrupt characters on the screen. this
change therefore should make the output a bit more stable.
the detection window is continually adjusted, so that the
output timings don't drift.
the tolerances are automatically adjusted based on base
timings (see new define in patch)
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
make the frequencies clearer in printf
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
much cleaner. do it right after zero-init memset.
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
otherwise, it'll be empty/undefined
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
useful timing now displayed
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
instead of when it goes above, do it precisely on the
timeout. otherwise, if by sheer chance the signal
pauses and we reset the byte - sure, ok, but it's a
bit tight and we run the risk of advancing another
frame, depending on the timing.
this is a minor edge case, probably rarely ever
triggered in practise.
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
it's no longer resembling the original util at all,
so a rename seems indicated. yes.
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
