When testing if function exists command type returned error message if
the function did not exist:

/usr/libexec/rainbow/compat.sh: line 61: type: get_brightness_raw: not found

It is used just for condition, so it is fine to get rid of the message.

Michal Vasilek authored 2 years ago and Richard Muzik committed 1 year ago

rainbow get intensity from compat.sh is supposed to return intensity
in a the same range as what sysfs provides which is specific to each router

Button-sync checked whether value saved in UCI corresponds to the value
in MCU and whenever they differed, it overwritten UCI value with value
from MCU. But the latest change could easily be change in UCI that was
yet not applied. So instead of comparing MCU value against UCI value,
compare last seen value with current one and overwrite only on change.

Consider situation when you manually change the value of brightness in
UCI config file, save it and if it takes you more then two seconds to
call apply it, button-sync overwrites it back to the original value.

Marek Behun authored 1 year ago and Michal Hrusecky committed 1 year ago

Upstream kernel did not yet apply the patch that sets the max_brightness
sysfs property of Omnia LEDs to 1 (from 255).

Because of this, when using upstream kernel we need to set brightness
to 255. Otherwise the LEDs are very dim, because although we set
multi_intensity to "255 255 255", this is then recomputed to "1 1 1"
before kernel sends it to hardware, since brightness is set to 1/255.

The global brightness on Omnia in sysfs (and in hardware) is represented
by percents (range [0,100], let's call this the P value), but the
rainbow.all.brightness UCI setting uses range [0,255] (let's call this
the B value).

The get_brightness() and preapply() functions in Omnia's backend use the
formulas:
  PtoB(B) = B * 100 // 255
  BtoP(P) = P * 255 // 100

These formulas convert between ranges [0,100] and [0,255], and after the
conversion they floor the result. This is wrong, because then the
function BtoP is not an inverse of PtoB.
For example
  BtoP(PtoB(1)) = 0, or
  BtoP(PtoB(99)) = 98.

This is bad for example in the following situation:
- The button_sync.sh script periodically reads the P value from sysfs,
  converts it via PtoB and updates the rainbow.all.brightness UCI value.
  Let's say the user uses the front button to configure brightness to
  P=1 (out of 100). The button_sync.sh script uses the PtoB formula and
  sets rainbow.all.brightness = PtoB(1) = 2.

- The user then uses the following command:
    rainbow wan green
  to change the color of the WAN LED to green.
  The preapply() function is called, which uses the BtoP formula and
  configures sysfs value of brightness to
    BtoP(rainbow.all.brightness) = BtoP(2) = 0.
  This disables all LEDs.

  So by setting the WAN LED to green color, we have managed to disable
  all LEDs.

Fix this issue by changing the formulas to round the value after the
range conversion, instead of flooring it. This is done by setting
  PtoB(B) = (B * 100 + 127) // 255
  BtoP(P) = (P * 255 + 50) // 100

otherwise it's considered to be an octal number

led_defaults is sometimes used even on mox which results in not found
errors

fixes reader_loop: bad jump: 8388608 error

This reverts commit 96500e1b.

Unless button-sync is executable, it is not possible to run it from init
file and thus brightness settings doesn't work.

button-sync need to include uci to be able to store and restore the
brightness settings.

Josef Schlehofer authored 2 years ago and Michal Vasilek committed 2 years ago

    root@turris:~# rainbow intensity 5
    /usr/libexec/rainbow/backend.sh: line 147: compat_intensity: command not found

color.sh sourced by rainbow uses many bash specific features

Michal Hrusecky authored 2 years ago and Michal Vasilek committed 2 years ago

UCI doesn't support dash inside of section name. So when fetching LEDs
settings, replace dash with underscore.

Previously mode_args was missing from apply_args, so when using the auto
mode, rainbow ran apply_activity activity and failed because of a
missing argument:

	%: /etc/init.d/rainbow start
	/usr/bin/rainbow: Internal error: Unsupported activity arguments:

Michal Hrusecky authored 2 years ago and Michal Vasilek committed 2 years ago

Animator - specifically animator.py - is run from init script so it
should be executable.

Michal Hrusecky authored 2 years ago and Michal Vasilek committed 2 years ago

Without this, restarting rainbow could fail with the following error:

/usr/bin/rainbow: line 97: apply_activity: not found

After some investigation, it turns out that apply_activity is defined in
led_activity.sh which is not necessarily loaded soon enough.

Michal Hrusecky authored 2 years ago and Michal Vasilek committed 2 years ago

Let's not scare users with changing all colors, especially not in
confusing way. Green for power should be Ok, but wouldn't use blue for
LAN ports.

Michal Hrusecky authored 2 years ago and Michal Vasilek committed 2 years ago

Always show full help - otherwise it is hard to guess how to get to it.
Apart from that include a way how to get a list of additional
operations.

Michal Hrusecky authored 2 years ago and Michal Vasilek committed 2 years ago

Animator is a nice feature, but as it pulls in Python, it is quite
expensive function to be used for example in rescue system. It is better
not to depend on it and just integrate with it when it is available.

these scripts were supposed to be in packages, not in this repository

* move button-sync and animator to separate directories
* move readme to the root of the project
* add build instructions

doesn't work properly yet