logo du siteLe Site du Gnu-Bricoleur

/!\ Un blog plébiscité par Chuck Norris O_o

Pinephone - A simple compas app (Kompass ? :°)

Rédigé par SuperGNU Aucun commentaire

This article is still a Draft, it's just temporarily published for personal convenience

Foreword : This article is a log of the process I followed to develop a simple compass app for Manjaro Plasma Mobile on the Pinephone (the app in itself should be compatible with more systems and devices but this is my primary target and test device incidentally). It should be considered as such and certainly not as a tutorial to develop a new app. Further disclaimer, I am not even a developer, I am just an electrical engineer playing with Linux and software, my knowledge is really lacking and I'm sure several steps are unnecessary and/or plain wrong

Genesis of the project

I was looking for a small project to put me back on track with my Braveheart smartphone since I haven't been playing much with it since the last article. On the plasma-mobile "random project assignor" I got this. The linked problem to solve is this one Seems like a perfect project, simple enough, small so that it doesn't takes up a ton of time, with a useful and concrete result. I'm sold !

Preliminary research

According to this list the Pinephone compas is a ST LIS3MDL sensor. Actually, according to :

STmicroelectronics LIS3MDL ultra-low-power three-axis magnetometer, LGA-12 2.0x2.0x1.0 mm [datasheet] Note: The LIS3MDL is currently unavailable, so it has been replaced in the PinePhone Beta Edition with the Voltafield AF8133L e-Compass, which is unlisted on the Voltafield web site, but the AF8133J is listed. Presumably U1200 will be unpopulated and U1203 will be populated in the Beta Edition, since they appear to be alternatives.

And :

U1203: Asahi Kasei Microdevices (AKM) AK09911 3-axis electronic compass IC with Hall sensor, 8-pin WL-CSP (BGA), 1.2×1.2×0.5 mm or Voltafield Technology Corp. (VTC) AF8133J 3-axis electronic compass with proprietary anisotropic magneto resistive (AMR) technology, 8-pin WLCSP 1.2x1.2x0.5 mm Note: These parts appear to be alternatives to be used if the LIS3MDL is unavailable, so U1203 was probably unpopulated in BraveHeart and the Community Editions, but will be populated in the Beta Edition.

It's a little bit more complicated but given that I have the BraveHeart edition I apparently have a LIS3MDL

Eventually, I suppose the default Plasma-mobile (let's dream :)) compass application (Kompass obviously :)) will have to support every Pinephone configuration (and every supported smartphone). I'm not sure about how an application is supposed to handle that but I have the feeling that if the magnetometer is correctly managed by the kernel as a device, it should be exposed in a generic way in the user space... I started to poke around a little bit and found this ST driver for ST mems (what about the other brands ??) following a link from this thread. Also this random repo, not sure what it does.

After flashing a fresh Manjaro Plasma-mobile on my Pinephone, i tried :

[sylvain@plasma-mobile /]$ sudo find . -name "*lis3mdl*"
[sudo] password for sylvain: 
find: ‘./proc/28998’: No such file or directory
./sys/firmware/devicetree/base/__symbols__/lis3mdl
[sylvain@plasma-mobile /]$ 

This is great news ! Apparently, the magnetometer is in the device tree !

[sylvain@plasma-mobile /]$cat ./sys/firmware/devicetree/base/__symbols__/lis3mdl
/soc/i2c@1c2b000/magnetometer@1e^@
[sylvain@plasma-mobile /]$ 

And it's connected on an I2C bus ! (From the datasheet it could also have been SPI) This means if I'm not mistaken that the device is mapped in memory at the address 0x1c2b000. So I tried :

[sylvain@plasma-mobile /]$ sudo hexdump -C --skip 0x1c2b000 /dev/mem | head
hexdump: /dev/mem: Bad address
01c2b000

Without success... Same happens for the following addresses. According to this, it's apparently normal :

You should also notice that there is no ranges property in the i2c@1,0 node. The reason for this is that unlike the external bus, devices on the i2c bus are not memory mapped on the CPU's address domain. Instead, the CPU indirectly accesses the rtc@58 device via the i2c@1,0 device. The lack of a ranges property means that a device cannot be directly accessed by any device other than it's parent.

So let's install some tools to play with I2C devices. With

[sylvain@plasma-mobile /]$ pacman -Syu i2c-tools

Now we can scan the s

[sylvain@plasma-mobile /]$ sudo i2cdetect 0 [sudo] password for sylvain: WARNING! This program can confuse your I2C bus, cause data loss and worse! I will probe file /dev/i2c-0. I will probe address range 0x08-0x77. Continue? [Y/n] Y 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: 30 31 32 33 34 35 36 -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: 50 51 52 -- 54 55 -- 57 58 59 5a 5b 5c 5d -- 5f 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- [sylvain@plasma-mobile /]$ sudo i2cdetect 1 WARNING! This program can confuse your I2C bus, cause data loss and worse! I will probe file /dev/i2c-1. I will probe address range 0x08-0x77. Continue? [Y/n] Y 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- UU -- -- -- UU -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- UU -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- --
[sylvain@plasma-mobile /]$ sudo i2cdetect 2 WARNING! This program can confuse your I2C bus, cause data loss and worse! I will probe file /dev/i2c-2. I will probe address range 0x08-0x77. Continue? [Y/n] Y 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- UU -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- UU -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- UU -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- --
[sylvain@plasma-mobile /]$ sudo i2cdetect 3 WARNING! This program can confuse your I2C bus, cause data loss and worse! I will probe file /dev/i2c-3. I will probe address range 0x08-0x77. Continue? [Y/n] Y 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- --
[sylvain@plasma-mobile /]$ sudo i2cdetect 4 WARNING! This program can confuse your I2C bus, cause data loss and worse! I will probe file /dev/i2c-4. I will probe address range 0x08-0x77. Continue? [Y/n] Y 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- UU -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- UU -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- --
[sylvain@plasma-mobile /]$ sudo i2cdetect 5 WARNING! This program can confuse your I2C bus, cause data loss and worse! I will probe file /dev/i2c-5. I will probe address range 0x08-0x77. Continue? [Y/n] Y 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- UU -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- UU -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- UU -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- --

https://linux.die.net/man/8/i2cdetect

"--". The address was probed but no chip answered.
"UU". Probing was skipped, because this address is currently in use by a driver. This strongly suggests that there is a chip at this address.
An address number in hexadecimal, e.g. "2d" or "4e". A chip was found at this address.

[sylvain@plasma-mobile ~]$ lsmod Module Size Used by rfcomm 53248 16 bnep 28672 2 zram 28672 2 zsmalloc 32768 1 zram ov5640 32768 2 crct10dif_ce 20480 1 8723cs 1449984 0 sun50i_codec_analog 32768 1 sun8i_adda_pr_regmap 16384 1 sun50i_codec_analog hci_uart 57344 0 btrtl 24576 1 hci_uart btbcm 24576 1 hci_uart st_magn_spi 16384 0 bluetooth 430080 44 btrtl,hci_uart,btbcm,bnep,rfcomm st_sensors_spi 16384 1 st_magn_spi st_magn_i2c 16384 0 panel_sitronix_st7703 16384 0 st_magn 20480 2 st_magn_i2c,st_magn_spi st_sensors_i2c 16384 1 st_magn_i2c inv_mpu6050_i2c 16384 0 st_sensors 20480 3 st_magn_i2c,st_magn,st_magn_spi inv_mpu6050 32768 2 inv_mpu6050_i2c industrialio_triggered_buffer 16384 2 inv_mpu6050,st_magn stk3310 16384 0 kfifo_buf 16384 1 industrialio_triggered_buffer cfg80211 315392 1 8723cs anx7688 36864 0 ecdh_generic 16384 1 bluetooth ecc 28672 1 ecdh_generic rfkill 28672 11 bluetooth,cfg80211 sun8i_codec 53248 1 sun4i_i2s 24576 2 snd_soc_ec25 16384 1 snd_soc_bt_sco 16384 1 snd_soc_simple_card 20480 2 snd_soc_simple_amplifier 16384 1 snd_soc_simple_card_utils 20480 1 snd_soc_simple_card snd_soc_core 151552 8 sun4i_i2s,snd_soc_bt_sco,sun50i_codec_analog,sun8i_codec,snd_soc_simple_amplifier,snd_soc_simple_card_utils,snd_soc_ec25,snd_soc_simple_card snd_pcm_dmaengine 20480 1 snd_soc_core snd_pcm 102400 4 sun4i_i2s,sun8i_codec,snd_soc_core,snd_pcm_dmaengine snd_timer 40960 1 snd_pcm snd 65536 8 snd_timer,sun8i_codec,snd_soc_core,snd_pcm display_connector 16384 0 soundcore 16384 1 snd leds_sgm3140 16384 0 i2c_gpio 16384 0 sun4i_lradc_keys 16384 0 [sylvain@plasma-mobile ~]$

Plasma mobile app dev guide : https://community.kde.org/Plasma/Mobile/DevGuide

git cmake make extra-cmake-modules g++ qt5-qmake qt5-default qtdeclarative5-dev libqt5svg5-dev qtquickcontrols2-5-dev libkf5config-dev kirigami2-dev qtmultimedia5-dev

gcc qt5

https://www.balena.io/blog/sensors-and-data-logging-with-embedded-linux-the-ultimate-guide-part-1/

https://wiki.analog.com/resources/tools-software/linux-software/libiio/iio_readdev https://stackoverflow.com/questions/18688763/why-is-istream-ostream-slow https://community.nxp.com/t5/i-MX-Processors/Re-how-to-read-info-from-iio-device-iio-device0/m-p/269079 https://sourceforge.net/projects/iioutils/files/iioutils/

[sylvain@plasma-mobile iio:device2]$ sudo su [sudo] password for sylvain: [root@plasma-mobile iio:device2]# echo 80 > sampling_frequency

disgusting code : https://github.com/Gnu-Bricoleur/Kompass

Info generale i2C: https://learn.sparkfun.com/tutorials/raspberry-pi-spi-and-i2c-tutorial/all

Classé dans : Pinephone Mots clés : aucun

Pinephone - 2: A first Application

Rédigé par SuperGNU Aucun commentaire

The Linux ecosystem for smartphone is still a little bit confusing for me at the minute so I decided to start small before trying to make actual contributions to the core system or useful apps by just making a dummy example app.

I've decided to go with kirigami for building the app as it seems to me to be the best compromise at the moment. Kirigami is the KDE solution to make apps work on both desktop and phones. The apps are using Qt widgets and depending on the platform, alternate versions of the widget and layout are used. As it's developed by KDE it should integrate well with Plama on Postmarketos but it should also works on Ubuntu Touch (and even Android, Windows and Mac).

However, kirigami is still a rather new technology and there is few documentation on it. I also had some difficulties on getting all the kde5 dependencies installed on the pinephone using apk because of some issues with the latest mesa driver. This will probably be fixed soon but in the meantime, i used flatpak to get all the required dependencies on both my computer and the Pinephone and i think it actually proved easier and more versatile than building directly into the pmbootstrap chroot.

Here are the websites i relied on for documentation:

Part I : Compiling the hellokirigami example app

The idea is to code the app on the computer, cross-build it with flatpak for the pinephone, send it on the pinephone and install there. First, we need to install flatpak on the development computer, most likely.

 apt install flatpak

Then we need to add those two remotes to flatpak (flathub because it's generally useful for software and kde for the Qt5 libraries)

flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo
flatpak remote-add --if-not-exists kdeapps --from https://distribute.kde.org/kdeapps.flatpakrepo

We can then install the Qt libraries for the computer in order to compile the app for desktop and be able to try it before sending to the phone.

flatpak install flathub org.kde.Platform//5.12 flatpak install flathub org.kde.Sdk//5.12

We also need to install flatpak those same libraries but for the phone architecture. Now, most tutorials for kirigamiu are installing the arm architecture version for mobile plateform but uname -m returns aarch64 on the pinephone so we need the aarch64 version.

apk add flatpak
flatpak install flathub org.kde.Platform/aarch64/5.12
flatpak install flathub org.kde.Sdk/aarch64/5.12

also to be able to cross compile later with flatpak builder, you will need the following packages installed on your system :

sudo apt install qemu binfmt-support qemu-user-static

We can then download the following example project and try to compile it :

git clone https://invent.kde.org/jbbgameich/plasma-mobile-app-template.git

Then, to build :

cd plasma-mobile-app-template
flatpak-builder flatpak-build-desktop --force-clean --ccache *.json

To make the app display as as on a smartphone on the computer

export QT_QUICK_CONTROLS_MOBILE=true QT_QUICK_CONTROLS_STYLE=Plasma

To then run the app on the computer

flatpak-builder --run flatpak-build-desktop *.json hellokirigami

The app should launch in a new window.

We can then compile for the phone arcchitecture :

flatpak-builder flatpak-build-phone --repo=arm-phone --arch=arm --force-clean --ccache *.json
flatpak build-bundle arm-phone hellokirigami.flatpak org.kde.hellokirigami --arch=arm

Send the app to the phone (with postmarketos, the phone is available on the IP 10.15.19.82 as soon as it's connected to the computer via USB.

scp hellokirigami.flatpak phablet@10.15.19.82:/home/phablet/app.flatpak

To test the app on the phone, we need to install it, as for now we just have the package copied to memory.

ssh phablet@10.15.19.82

To install flatpak on the Pinephone:

sudo apk install flatpak
flatpak install flathub org.kde.Platform/aarch64/5.12
flatpak install flathub org.kde.Sdk/aarch64/5.12
flatpak install hellokirigami.flatpak

The application should appear on the launcher. Otherwise, it should be possible to launch it with :

flatpak run org.kde.hellokirigami

Then, to develop, it's just going to be iterations of : Building on the computer for the phone, bundling into a flatpak package, sending to the phone, installing, ... iterate!

On the computer :

flatpak-builder flatpak-build-desktop --repo=aarch64-phone --arch=aarch64 --force-clean --ccache *.json
flatpak build-bundle aarch64-phone hellokirigami.flatpak org.kde.hellokirigami --arch=aarch64
scp hellokirigami.flatpak sylvain@172.16.42.1:/home/sylvain/

On the phone SSH console:

sudo flatpak install hellokirigami.flatpak 
Classé dans : Non classé Mots clés : aucun

Pinephone - 1: The arrival !!

Rédigé par SuperGNU Aucun commentaire

This is, i hope, the first of a serie of Pinephone articles summing up for myself and others what i'm learning on the Pinephone, Linux on a smartphone and contributing to the different OSs in order to turn this phone into the perfect daily driver.

I'll be learning as i write so i don't expect these articles to always represent the best or the most elegant solution but i intend them to help me figure out exactly what was needed in the middle of all i tried and maybe it can help shorten the learning path for others. Right now only 3000 "Braveheart" Pinephones have been selled and i can assume most of them are in far more knowledgeable hand than mine but come April, the software should be in a better place and Pine64 will surely sella new batch to less linux-able people and this guide might just come handy.

Lire la suite de Pinephone - 1: The arrival !!

Interface graphique pour écran Arduino (OpenSmart ou Adafruit)

Rédigé par SuperGNU Aucun commentaire

Introduction

Je suis en ce moment en train de travailler sur un petit projet de régulateur PID universel avec une carte Arduino. Je souhaite pouvoir contrôler mon régulateur via une interface "user-friendly" sur un écran tactile. La carte Arduino n'étant pas vraiment à la base taillé pour l'affichage graphique, il n'existe pas de bibliothèque simple d'utilisation pour ce genre d'usage. J'en ai donc rédigé une. ;-) Elle n'est clairement pas encore terminé mais si j’attends que ce soit parfait pour la mettre en ligne ..., bref, voila le code !

En l'état actuel elle peut déjà rendre des service et elle convient parfaitement à l'usage que j'en ai (ce qui explique que je ne soit pas chaud bouillant pour la perfectionner ;-)).

** /!\ Disclaimer : C'est un travail en cours faut pas espérer que tout marche parfaitement du premier coup. Il y a deux gros points noirs à améliorer :

  • tester la librairie avec un autre type d'interface que celle que j'utilise dans mon programme (3 onglets, un clavier sur le premier et des boutons sur les autres). J'ai écrit la libraire en tentant de généraliser le code de l'interface mais avec comme objectif principal de réaliser d'abord mon interface.
  • uniformiser les appels de fonctions. Cette librairie à été écrite au fil de l'eau au fur et a mesurer que le besoin s'en faisait sentir et l'ordre des paramètres ne suis pas de vrai logique **

Utilisation de la librairie

Je mettrai une doc fonction par fonction sur mon wiki mais voici le principe d'après lequel je suis parti pour la librairie.

  • L'interface est tout d'abord divisé en onglets. Ca marche très bien avec 3 mais ca devrait marcher avec n'importe quel nombre. Chaque onglet possède un titre et une zone cliquable en haut de l'écran.

  • On peut ajouter du texte et des boutons sur chaque onglet. Les boutons renvoient au main leur numéros ce qui permet de savoir quel bouton à été cliqué.

  • On peut associer une fonction aux boutons pour qu'elle soit exécutée lorsque l'ont clique sur le bouton. Il faut fournir un pointeur vers cette fonction au constructeur du bouton. Cela permet de réaliser des claviers.

  • On peut modifier le texte écrit sur les onglet si l'ont a stocké le numéros renvoyé lors de sa création dans une variable.

Code d'exemple et commentaires

Classé dans : Projets Mots clés : aucun

Amiblight avec Arduino et ruban WS2811S

Rédigé par SuperGNU Aucun commentaire

Introduction

J'ai récupéré à mon club robotique un grand morceau de ruban de LED RGB inutilisé. J'ai eu l'idée d'en faire un clone d'ambilight (lumière d'ambiance adaptative au contenu de l'écran) pour mon grand écran de PC. Je pensais qu'avec quelques lignes de Python et une Arduino le problème serai vite réglé. J'ai en fait rencontré deux principaux obstacles, la génération d'une consigne pour le ruban et le pilotage du ruban en lui-même. Je poste donc ici la solution si jamais quelqu'un rencontre le même problème.

Génération de la consigne

Je pensais naïvement que la détermination de la couleur moyenne d'une image se faisait simplement en faisant une moyenne par composante de chaque pixel d'une image. PAS DU TOUT ! ;-)

La couleur obtenue avec cette technique étant désespérément gris~marron, j'ai réfléchi un peu et je me suis rendu compte que le mieux était non pas de faire la moyenne des couleurs mais de chercher la couleur dominante de l'image pour déterminer la couleur de l'ambiance. Là encore, ce n'est pas facile à déterminer, comme l'explique assez bien ce site, la détection de la couleur perçue comme étant la couleur dominante est plus compliqué que de chercher la couleur la plus présente dans l'image. Au passage un autre [site intéressant]( http://charlesleifer.com/blog/using-python-and-k-means-to-find-the-dominant-colors-in-images/) sur la question présentant un algorithme un peu différent et la bibliothèque que j'ai utilisé en python pour faire mes tests.

In fine (on ne dit pas au final ...;-)), j'ai réussi à avoir un programme donnant des résultats satisfaisants pour une capture d'écran et là .... katastroph ! Lorsque je fais boucler le script, pour prendre une capture, analyser, envoyer la couleur au ruban la couleur n'est mise à jour qu'un peu plus d'une fois par seconde et un cœur de mon processeur est monopolisé à 100%. Même en optimisant le code et en repartissant sur plusieurs threads pour améliorer l'utilisation des cœurs, je sentais que mon script resterait lent et consommateur de ressources. Avant d'envisager la réécriture en C, j'ai voulu regarder "ce qui ce faisait ailleurs et comment ça ce faisait" (Note à moi-même : la prochaine fois, COMMENCER par étudier l'état de l'art !).

Je suis tombé (sans me faire mal !) sur le projet Adalight (Opensource !) qui bien que n'étant pas compatible avec mon ruban (évidement, c'est compatible avec leur ruban :-)) correspondait exactement à ce que je souhaitais faire. Avec en plus comme bonus non négligeable la gestion du multi-écran et le traitement de l'image de l'écran de façon à faire correspondre la couleur du morceau de ruban avec la couleur du bout d'écran accolé (pas clair) ce qui correspondait à la deuxième étape (laborieuse) de mon projet. Le script tournant sous processing, il était donc de plus théoriquement compatible Linux (évidement) et Windows ce qui pouvait être sympa pour quand je reboot sous Windows. Lien du dépôt Github avec le code J'ai donc décidé d'utiliser le script d'Adafruit avec quelques modifications.

ATTENTION : Ce script ne fonctionne correctement qu'avec Processing 2.X.X Personnellement je n'ai aucun soucis avec Processing 2.2.1, il ne fonctionne par contre plus avec Processing 3.

Pilotage du ruban

Ayant décidé d’utiliser le code d'Adalight, il me fallait du coup coder un script Arduino compatible avec le WS2811, le driver de mon ruban. Le script d'Adalight permettait le controle d'un ruban en SPI tandis que le WS2811 se comporte plutôt comme un shift register. Le code est fortement inspiré du code original d'Adafruit et d'exemples d'utilisation de la librairie FastLed trouvés sur internet (je sais plus ou :-°). Les deux scripts dans le dépôts fonctionnement parfaitement ensemble, si vous cherchez à faire un Adalight, vous ne devriez avoir à modifier que la définition de votre écran dans le script Processing. Lien du dépôt Github avec le code

Conclusion

Une petite vidéo de démonstration (Adalightception) : https://youtu.be/6d2rLEUgs84

Sur mon i5 de 4ème génération, le programme consomme environ 10% de ressources, c'est beaucoup mais ça reste raisonnable et surtout le rafraîchissement est plutôt rapide (comme on peut le voir dans la vidéo).

Classé dans : Projets Mots clés : aucun
Fil RSS des articles