| Message ID | 20240228114555.192175-1-ines.varhol@telecom-paris.fr (mailing list archive) |
|---|---|
| Headers | show |
| Series | Add device DM163 (led driver, matrix colors shield & display) | expand |
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