I haven't actually made such testing, but i assume no. It processes dips that changed in same interrupt in a for-loop, and processes are started as detached.
https://github.com/kimmoli/diptoh-da.../dips.cpp#L172

I think there is still contact issues. I had to reset it twice (just liftng that one corner few mm), specially if i have phone in my pocket.

You make my ancestors proud...

You're right, I just checked after having carried the Jolla in my jean's pocket today, and the switches had stopped working again. Lifting up the bottom corner solved it.

I noticed that the switches had moved from "off" to "on" or the opposite while in my pocket, though I did not pick the Jolla from my pocket very often today (it was just sitting there in my pocket). That could be an issue to solve for future revisions of the diptoh (but future versions would need larger buttons or larger space between them anyway, to be more useable for people like me who have short nails). These pockets can be a bit tight though, that should be OK in almost every other pants I have.

Speaking of that, I'd appreciate any built-in system to help removing OHs for people who have no nails. I have to find a tool and slightly scratch my Jolla every time I must remove an OH (and I really have to, there is no way I can remove a custom OH with no tool; don't laugh at me). A small notch in future 3D prints, or small lever, or anything, I don't know.

I'm glad I made your ancestors proud! Now finish and ship some toheinks and you'll be the greatest offspring ever. :]

First of all:
Thanks kimmoli and dirk for both hard- and software developing for the DIPTOH - really great!!!!

I'm doing some experiments with different calls at the moment and came to one point:


Is it possible to check the position of a switch?

If I don't miss anything we do it the other way round: using a switch calls a script.

Can we also read out the positions of all switches?

asys3

Yes, toggling the switch causes interrupt, which tells daemon to read switch states from gpio expander over i2c.
Daemon them compares read states to previous states, and executes a specified script of state which really changed.

Not at the moment, but I can add e.g. dbus interface to check the current state? or write them to a file e.g. /tmp/dipswitchstate when ever they change.

To prevent the whole diptoh to die after single connection break, i think i will add timer to periodically check and re-init gpio expander if needed.

Eh, and what's about the button? Where is the area, how should it be pressed and whether there'll be capability to run a script on this interrupt as well?

It is located below DIP-switch, you can see the void in bottom copper of PCB, about there.

Not yet implemented in the daemon though. Update coming, ETA 12 hours

tomorrow the last shells arrive, then the last ones go on the mail!

OBSOLETE

Update 0.4-1

Download RPM here: https://app.younited.com/?shareObjec...9-7726d2d559f0

Update will not overwrite your dip*.sh scripts (but make a back e.g. tar czvf diptoh.tgz /home/nemo/diptoh/ just to be sure)

• Adds two scripts,. buttondown.sh and buttonup.sh these will be run when the secret button is pressed and released.
• Checks every 30 sec has diptoh been disconnected. In case this is detected, chip will be reinitialized.
• It also improves the interrupt and gpio handling - there was few issues in case of switch-bouncing etc.

Interesting, after installing this and rebooting the phone - there's something wrong with it. Gui can't connect - frequent green flashes with screen blank after the initial boot sequence. Guess will factory reset from recovery and try again - as I don't think I have patience/time to troubleshoot in shell not really understanding what could go wrong.
Or does someone have a better idea?

argh. that doesn't sound nice at all. I make quick reboot and test it myself. iirc i did reboot-test it atleast once.

This shouldn't happen if diptoh is not attached to phone, as it is not started in that case.

-------

Ok, seems that during reboot, it gives sporadic interrupt, at first reboot it did execute dip1on and dip1off, and on 2nd boot only dip1on.

I raise an issue to me about this, and try to fix it asap (ETA 5 hours)