Unterstützung von mehr Buttons

Ich bin gerade dabei das Button Handling zu verbessern.
Und wollte mal klären wie viele Buttons max. unterstützt werden sollten.

Da ich gerade versuche die DogBox umzubauen welche schon 8 Button hat
Komm ich mit meiner eigentlich gedachten Struktur welche 7Buttons unterstützen würde nicht hin.

Daher würde ich dann Unterstützung für bis zu 15 Buttons einbauen.
Ist das für irgendwelche Anwendungsbereiche zu wenig?
Zur Auswahl stünden 15, 23, 31, …

Wieviel Buttons sollen unterstützt werden
  • 15
  • 23
  • 31
  • 39
  • 47

0 Teilnehmer

Ich persönlich benötige nicht mehr Tasten. Falls jemand eine Box bauen möchte, wo direkt Ordner abgespielt werden a la Hörbert, dann reicht auch die 15 Tasten Version.

Handelt es sich im einen reinen Input (zB Tasten per wiederstandsmatrix)? Ich möchte beleuchtete Tasten verwenden, da könnte es mit den Output eng werden. Falls du einen Expander verwendest, dann reichen mir 15 LEDs auch locker :sweat_smile:

Es geht nicht um die Anbindung der Buttons, sondern nur um das interne Handling.

Ob die dann über i2c , widerstandsmatrix, oder auch webui :wink: geschaltet werden ist erstmal egal.

Das wichtige wäre welcher Datentyp zum speichern verwendet werden soll.
Da ich aber gerade gelesen habe das der ESP32 auch 32bit Grenzen verwendet (sagt ja schon der name :wink: )
wäre uint = 32bit -1 = max. 31 buttons…

ich speichere die Buttonstates binär in einer Variable das erste bit ist für longpress state.

Dann gibt es ein array in den settings wo ich die Bitmaske angeben kann und was diese Bitmaske für ne aktion hat.

Damit wären dann auch individuelle Longpress und Multibutton Klicks möglich.

sorry, hab ich vercheckt

individuelle Longpress und Multibutton Klicks klingt gut

Aktuell gibt es jetzt bei meinem Fork eine technische Unterstützung von 31 Buttons. Wird sich aber noch auf 30 reduzieren.

Dafür wird es dann noch ein Dauer-Longpress geben, für z.b. Lautstärke.

1 „Gefällt mir“

super cool.

Kennst du die Umsetzung von rockbox?

Da gibt es modifier für BUTTON_REPEAT und BUTTON_REL.

Außerdem wird bei Rockbox je nach Kontext ein eigenes Mapping gespeichert, fürs Hauptmenü etc.
Das brächte man aber nur, wenn man die Buttonbelegung im Admin-Menü unabhängig von der sonstigen Belegung ändern will. Ich sehe da bisher keinen Bedarf.

Dass in dem Button-Mapping immer noch der Wert des vorherigen Buttons mit definiert wird, hat den Grund, dass damit der Code einfacher wurde.
Gerade wenn man viele Multikeys oder Modifier-Keys (wie ALT oder CTRL) definieren will, braucht man dann weniger IFs. Das brauchen wir wohl nicht.

Also zusammengefasst: Echt cool, was du hier machst.
Ich finde nicht, dass wir etwas davon übernehmen sollten, da du schon eine gute Lösung gefunden hast. Es ist aber trotzdem manchmal interessant, wie das Problem schon einmal (2006!!!) gelöst wurde.

https://git.rockbox.org/cgit/rockbox.git/tree/firmware/export/button.h
https://git.rockbox.org/cgit/rockbox.git/tree/apps/keymaps/keymap-fuzeplus.c
https://git.rockbox.org/cgit/rockbox.git/tree/firmware/target/arm/as3525/sansa-fuzev2/button-target.h

1 „Gefällt mir“

Ja das würde dann wirklich für die meisten User zu kompliziert werden :wink:
Aber an eine Menu gedacht hatte ich auch, aber wieder verworfen weil eigentlich unnötig.