This device implements the IM120417002 colors shield v1.1 for Arduino
(which relies on the DM163 8x3-channel led driving logic) and features
a simple display of an 8x8 RGB matrix. This color shield can be plugged
on the Arduino board (or the B-L475E-IOT01A board) to drive an 8x8
RGB led matrix. This RGB led matrix takes advantage of retinal persistance
to seemingly display different colors in each row.



I'm stuck on some issues with this implementation :

1. Tests

TLDR: how can I provide a test or an example?

I've tested the display by running custom executables and
comparing to the result on the real board, but I don't
know how to test it using a QTest.

`qtest_init_internal` sets `-display none`
so there's no way to test the display visually.

There's no `visit_type_*` for arrays so accessing the DM163
buffer to check its content is complicated. I could technically
access all the elements in the array (returning a different element
each time in the getter for example), but that seems sketchy.

2. Frame Rate

It'd be convenient to set the QEMU console's refresh rate
in order to ensure that the delay before turning off rows
(4 frames currently) isn't too short. However
`dpy_ui_info_supported(s->console)` returns false.



Changes from v1 :
- moving the DM163 from the SoC to the B-L475E-IOT01A machine
(changing config files and tests accordingly)
- restricting DM163 test to ARM & DM163 availability
- using `object_class_by_name()` to check for DM163 presence at run-time
- exporting SYSCFG inputs to the SoC (and adapting tests accordingly)

Thank you for your review Philippe :)

Based-on: 220240224105417.195674-1-ines.varhol@telecom-paris.fr
([PATCH v6 0/3] Add device STM32L4x5 GPIO)

Signed-off-by: Arnaud Minier <arnaud.minier@telecom-paris.fr>
Signed-off-by: Inès Varhol <ines.varhol@telecom-paris.fr>

Inès Varhol (5):
  hw/display : Add device DM163
  hw/arm : Pass STM32L4x5 SYSCFG gpios to STM32L4x5 SoC
  hw/arm : Create Bl475eMachineState
  hw/arm : Connect DM163 to B-L475E-IOT01A
  tests/qtest : Add testcase for DM163

 docs/system/arm/b-l475e-iot01a.rst  |   3 +-
 include/hw/display/dm163.h          |  57 +++++
 hw/arm/b-l475e-iot01a.c             | 103 ++++++++--
 hw/arm/stm32l4x5_soc.c              |   6 +-
 hw/display/dm163.c                  | 308 ++++++++++++++++++++++++++++
 tests/qtest/dm163-test.c            | 192 +++++++++++++++++
 tests/qtest/stm32l4x5_gpio-test.c   |  12 +-
 tests/qtest/stm32l4x5_syscfg-test.c |  16 +-
 hw/arm/Kconfig                      |   1 +
 hw/display/Kconfig                  |   3 +
 hw/display/meson.build              |   1 +
 hw/display/trace-events             |  13 ++
 tests/qtest/meson.build             |   5 +
 13 files changed, 690 insertions(+), 30 deletions(-)
 create mode 100644 include/hw/display/dm163.h
 create mode 100644 hw/display/dm163.c
 create mode 100644 tests/qtest/dm163-test.c

-- 
2.43.2

On 28/02/2024 12.31, Inès Varhol wrote:
> This device implements the IM120417002 colors shield v1.1 for Arduino
> (which relies on the DM163 8x3-channel led driving logic) and features
> a simple display of an 8x8 RGB matrix. This color shield can be plugged
> on the Arduino board (or the B-L475E-IOT01A board) to drive an 8x8
> RGB led matrix. This RGB led matrix takes advantage of retinal persistance
> to seemingly display different colors in each row.
> 
> 
> 
> I'm stuck on some issues with this implementation :
> 
> 1. Tests
> 
> TLDR: how can I provide a test or an example?
> 
> I've tested the display by running custom executables and
> comparing to the result on the real board, but I don't
> know how to test it using a QTest.
> 
> `qtest_init_internal` sets `-display none`
> so there's no way to test the display visually.
> 
> There's no `visit_type_*` for arrays so accessing the DM163
> buffer to check its content is complicated. I could technically
> access all the elements in the array (returning a different element
> each time in the getter for example), but that seems sketchy.

I'd suggest to try to take a screenshot via QMP or HMP. If you need a third 
party binary to get something on the screen, it's maybe best to write an 
avocado test instead of a qtest. See for example 
tests/avocado/machine_m68k_nextcube.py - it takes a screenshot and then 
converts the console messages from it via Tessaract to text and looks for 
the expected strings there. Alternatively, have a look at 
tests/avocado/machine_s390_ccw_virtio.py - it boots a Linux in the guest 
that writes a string into the /dev/fb0 framebuffer, then takes a screendump 
and then tries to find the string in the file. The latter could maybe also 
be done via a qtest if you know how to set up the framebuffer without a 
guest kernel.

  HTH,
   Thomas

On Wed, 28 Feb 2024 at 12:06, Thomas Huth <thuth@redhat.com> wrote:
>
> On 28/02/2024 12.31, Inès Varhol wrote:
> > TLDR: how can I provide a test or an example?
> >
> > I've tested the display by running custom executables and
> > comparing to the result on the real board, but I don't
> > know how to test it using a QTest.

> I'd suggest to try to take a screenshot via QMP or HMP. If you need a third
> party binary to get something on the screen, it's maybe best to write an
> avocado test instead of a qtest. See for example
> tests/avocado/machine_m68k_nextcube.py - it takes a screenshot and then
> converts the console messages from it via Tessaract to text and looks for
> the expected strings there. Alternatively, have a look at
> tests/avocado/machine_s390_ccw_virtio.py - it boots a Linux in the guest
> that writes a string into the /dev/fb0 framebuffer, then takes a screendump
> and then tries to find the string in the file. The latter could maybe also
> be done via a qtest if you know how to set up the framebuffer without a
> guest kernel.

The other extremely popular approach for testing display devices
is "I looked at the screen while I was doing the development,
and it was fine" :-)

-- PMM

On 01/03/2024 11.21, Peter Maydell wrote:
> On Wed, 28 Feb 2024 at 12:06, Thomas Huth <thuth@redhat.com> wrote:
>>
>> On 28/02/2024 12.31, Inès Varhol wrote:
>>> TLDR: how can I provide a test or an example?
>>>
>>> I've tested the display by running custom executables and
>>> comparing to the result on the real board, but I don't
>>> know how to test it using a QTest.
> 
>> I'd suggest to try to take a screenshot via QMP or HMP. If you need a third
>> party binary to get something on the screen, it's maybe best to write an
>> avocado test instead of a qtest. See for example
>> tests/avocado/machine_m68k_nextcube.py - it takes a screenshot and then
>> converts the console messages from it via Tessaract to text and looks for
>> the expected strings there. Alternatively, have a look at
>> tests/avocado/machine_s390_ccw_virtio.py - it boots a Linux in the guest
>> that writes a string into the /dev/fb0 framebuffer, then takes a screendump
>> and then tries to find the string in the file. The latter could maybe also
>> be done via a qtest if you know how to set up the framebuffer without a
>> guest kernel.
> 
> The other extremely popular approach for testing display devices
> is "I looked at the screen while I was doing the development,
> and it was fine" :-)

Well, but that doesn't help that much against regressions that can occur in 
the course of time...

  Thomas