PiBox

The first one to work on is the touch screen library. It's used by multiple apps. It's also the hardest one because it's a wrapper around another library (tslib) and the other library is doing the read. Currently I've configured the tslib to do non-blocking reads. So this thread is always busy. The library can be set to use blocking read()'s. So the problem is how to interrupt that read and catch it. This is because we need a way to wake the thread before shutting it down otherwise the thread in the blocked I/O will hang the app.

A blocking read can be interrupted in a thread with SIGINT. The read() will fail, which the touch library catches and then loops back around to try again. If we first call a thread function that resets the loop variable (causing it to exit on the next loop) then the SIGINT will cause the next loop to exit the thread.

Actually, we don't currently capture the fail correctly (from the perspective of blocking reads) so that's part of what has to be changed here.

A SIGINT will be propagated to all threads of a process. This isn't so bad as long as all threads handle blocked I/O the same way (non-blocking I/O would be caught with the existing shutdown() calls).

To test this I need to replace libpibox on the target. Apps dynamically link against that so I just need to update it to verify that the change still works.

I also need a way to measure if this change has any affect on an app. That's an interesting problem. I'm not sure the best way to do that yet.

This article discusses the use of SIGINT to break out of blocking reads and verifies that my intended design for the touch library should work. There is a very small time period where we'd have to send multiple SIGINT's to break out of the read() but we could simply do that three times in a row to make sure we weren't getting caught in that time period.

So the changes for the touch processor library (in libpibox):

1. Add a callback that a signal handler can call that sets ts_server=0 to disable the thread loop. This is wrapped in a mutex.
2. Change the thread loop to be while(1) because we want to use the mutex to read the loop variable.
3. Use a mutex to get a copy of the loop variable and test it, breaking out of thread loop if disabled.
4. Change call to ts_setup() to use a blocking read.
5. Add missing ts_close() to end of thread loop.
6. Update, as necessary, the tests of return value from ts_read() in thread loop to deal with possible EINTR.

• queueProcessor: needs pthreads_cond_wait/pthreads_cond_signal
• waiter: needs pthreads_cond_wait/pthreads_cond_signal

• smb: needs pthreads_cond_wait/pthreads_cond_signal to wake up smbProcessor instead of using smbEnable.
• regProcessor: blocks in recvfrom() but has artificial delay on EAGAIN/EWOULDBLOCK that could probably be removed.
• queueProcessor: needs pthreads_cond_wait/pthreads_cond_signal.
• timer: use alarm (like smb) to wake up cleanup processing.

appmgr is now working with mutex/cond updates.

On to piboxd.

• queueProcessor: needs pthreads_cond_wait/pthreads_cond_signal.
• timer: use alarm (like smb) to wake up cleanup processing.

• smb: needs pthreads_cond_wait/pthreads_cond_signal to wake up smbProcessor instead of using smbEnable.
• regProcessor: blocks in recvfrom() but has artificial delay on EAGAIN/EWOULDBLOCK that could probably be removed.

1. Media Center
   1. PiBox Server
   2. PiBox Player
   3. RPi 2 Server
2. Dev Platform
3. Kiosk test platform
4. Autokiosk (on kiosk test platform)

Then I need to test the Ironman project with the updates.
Finally, I can test Xeon with the updates and return to work on that project.

kiosk is not working properly. omxplayer is stuttering through videos. I tried running it manually from xterm and got the same problem. A little googling and I found this solution:
https://retropie.org.uk/forum/topic/17107/bug-solved-omxplayer-on-stretch-based-builds-stutters-on-composite

On the kiosk, where audio is played only out of the audio port (not HDMI) the use of -o both is causing the studdering of playback. Removing the -o both fixes the problem.

Removing the -o both option doesn't affect audio output to the audio port.

So the fix is to create a custom videofe.cfg that addresses the omxplayer command line issue and then pick it up if KIOSK=1 in the opkg/Makefile.am when building the opkg.

That's fixed but it's clear that the changes to the touchscreen library are not working. No touches are processed and I can't exit the app once it's started.
More debug is needed. I'll need to add a network adapter and enable debug on videofe to see if touches are being processed.

I don't think this is a touchscreen problem. Manually running omxplayer with the FIFO input works to start the player but no other commands are accepted via the FIFO after that by the player. Need to check if this is a known bug or if I will need to revert to the previous version in order to use the touchscreen.

A little searching and I found this bug report from Aug 6, 2019 which suggests using something like dbuscontrol.sh to control omxplayer. I'll have to switch to that in videofe, although using the C interface would be even better. I can find no solution to the broken FIFO problem as of yet.

The dbuscontrol.sh script doesn't work. It wants some files in /tmp/ that are created by something other than omxplayer, probably something in Raspbian. But it turns out those aren't really necessary because the files and their contents aren't really used by the commands in the script.

What is necessary is having the display set for X11. dbus apparently doesn't work without it, at least on PiBox. If I set DISPLAY=unix:0.0 and then run the following command, it will kill omxplayer using dbus:

dbus-send --print-reply=literal --session --dest=org.mpris.MediaPlayer2.omxplayer /org/mpris/MediaPlayer2 org.mpris.MediaPlayer2.Player.Action int32:15

So I can export DISPLAY when running the command or possibly set it in the environment before I run the external command (so it's picked up in the child environment). Interestingly, the script has options for a lot of omxplayer features managed via the dbus interface. So I can do things like pause or jump forward, back using the touchscreen regions. But first, just get exit to work with dbus.

Update: I've moved the FIFO problem to RM #714 and will track it's completion there. This issue is now blocked by that one.

This can't be completed until I fix the bugs uncovered with testing ironman: RM #721, RM #722, RM #723.

The problem with ironman is that piboxd's changes for thread management don't work. Instead of using a mutex to notify queueProcessor() I need to use a semaphore (or a mutex that does the same thing). And I should only read one message per notification - aka a 1-to-1 semaphore post to message process. The way I implemented it there was a chance (that actually occurs with Ironman) that an inbound message could cause a notification while the last notification was not completely processed, meaning that a message could be queued for processing but the processor has missed the notification.

This should fix RM #721 once I fix it.