Bumps [arduino/arduino-lint-action](https://github.com/arduino/arduino-lint-action) from 1 to 2.
- [Release notes](https://github.com/arduino/arduino-lint-action/releases)
- [Commits](arduino/arduino-lint-action@v1...v2)

---
updated-dependencies:
- dependency-name: arduino/arduino-lint-action
  dependency-type: direct:production
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <support@github.com>

…ns/arduino/arduino-lint-action-2

Bump arduino/arduino-lint-action from 1 to 2

Previously, the calculation for the distance of leftward and upward scrolling resulted in the text bitmap not being
scrolled completely off the display.

For leftward scrolling, this would be noticeable in the case where the bitmap of the last character in the string had
populated pixels on the rightmost column. For upward scrolling, this would be noticeable in the case where the bitmap of
any character in the string had populated pixels on the bottom row.

…nd up directions

The `endText` function has the capability to scroll the printed text. In order to ensure artifacts are not left behind
on the display while scrolling, the library must clear the pixels at the previous location of the text after each frame
of the scrolling animation.

Previously, the code to handle this clearing incorrectly calculated the clearing coordinates for the leftwards
(`SCROLL_LEFT`) and upwards (`SCROLL_UP`) scroll directions, having two separate problems:

* The offset was subtracted rather than added.
* An offset of 1 was used, which did not consider the width/height of the text.

This bug might not be immediately apparent to the user because many character bitmaps do not populate any pixels on the
rightmost column or bottom row of the grid, and thus those characters provide incidental self scroll trail clearing.
However, this is not the case for all characters and those would cause a trail of artifacts to be left behind on the
display when scrolled.

The clearing coordinates calculation code is hereby corrected.

NOTE: The coordinates calculation will still be incorrect for multi-line strings. However, this is not a regression
because it was also incorrect before this change. The scroll trail clearing code has never had any provisions for
handling multi-line strings so addition of such support is out of scope for this commit. In addition, the text scrolling
code (not the scroll trail clearing code) has never correctly handled horizontal scrolling of multi-line strings, so
until that is fixed it is only the lack of correct scroll trail clearing for vertical scrolling that is impactful to
users.

The `endText` function has the capability to scroll the printed text. In order to ensure artifacts are not left behind
on the display while scrolling, the library must clear the pixels at the previous location of the text after each frame
of the scrolling animation.

Previously, the code to handle this clearing for vertical scrolling only cleared a single character's width. This meant
that scroll trail clearing was only done for the first character in the string.

This bug might not be immediately apparent to the user because many character bitmaps do not populate any pixels on the
top or bottom row of the grid, and thus those characters provide incidental self scroll trail clearing. However, this is
not the case for all characters and those would cause a trail of artifacts to be left behind on the display when
scrolled.

The vertical scroll trail clearing code is hereby corrected to cover the full width of the string.

Previously the `ArduinoGraphics::bitmap` function was used by the clearing code. That approach was reasonable for
clearing the scroll trail of a single character, but due to the function's eight pixel width limitation, it is not
suitable to use with strings. In this application where a line of arbitrary length, but only one pixel thick is needed,
the `ArduinoGraphics::line` function is the suitable tool. So the code is ported to using `ArduinoGraphics::line`.

NOTE: The calculations of the length of the clearing line will still be incorrect for multi-line strings. However, this
is not a regression because it was also incorrect before this change. The scroll trail clearing code has never had any
provisions for handling multi-line strings so adding such support is out of scope for this commit. In addition, the text
scrolling code (not the scroll trail clearing code) has never correctly handled horizontal scrolling of multi-line
strings, so until that is fixed it is only the lack of correct scroll trail clearing for vertical scrolling that is
impactful to users.

Declare compatibility with renesas_uno architecture

Correct scroll length for left and up directions

Fix scroll trail clearing bugs

* update license to MPL-2.0

* Update README.md