I think everything is working now for both RPi and RPi2 builds. I need to verify this once for each before closing issue.

Builds completed for both RPi 1 and 2 (which includes Xeon).

• RPi 1 needs testing with Xeon.
• RPi 2 needs testing with media system and kiosk.

1. Verifying commands are being sent to the FIFO via the video player.
2. omxplayer release I'm using supports FIFO.

I just checked the PiBox omx git tree used by the build and it's set to a specific commit (and older one to permit proper builds, no doubt). So it should still be supporting the FIFOs.

That means something else is happening where the videofe program is getting the keystrokes or not sending them properly to omxplayer. I can verify this by starting the app from the UI then ssh'ing into the node and manually checking for the FIFO, sending commands through it manually if necessary.

Looks like no key presses are getting to videofe once omxplayer is started. I don't know who is blocking this. Neither the HOME key nor any omxplayer keys (FF, etc.) are being honored. It looks like the xterm is capture the keystrokes maybe? I could try switching to a different VT.

This might be the problem for omxplayer: https://github.com/popcornmix/omxplayer/issues/649
I'll have to patch omxplayer itself to fix this, or bump ahead to a more recent version.

Hmmm. Just noticed that RM #656 pushed omxplayer to master, yet the wrapper build is using commit a3ae908. That was done because of this commit which is related to this response. So I need to test omxplayer using the HEAD of master and the latest firmware. Note that popcornmix's response was in Nov and I ran into the problem in August, so maybe this will "just work" now.

That may get me past why omxplayer is not responding but it may not address why the HOME key is not exiting the player.

I'm now starting to think this isn't a problem with videofe, but solely a problem with omxplayer. I'm testing the refresh with glibc 2.29, which would show the problem having come from 2.25. And the exit from omxplayer is NOT handled by videofe when using the keyboard. It's directly handled by omxplayer.

So I need to rev omxplayer to master and make sure it's working again.

Verified - bumping omxplayer back up to the master branch (commit id f543a0d0e707ab56415f17b0ca6d397394ee8b63) fixed the keyboard problems. Media player is working fine now on Raspberry Pi 2 Model B Rev 1.2.

Since I've bumped all my demos to use either RPi 2 or 3 except for Xeon (which runs on a Pi Zero W, which is equivalent to RPi 1), I can now test the refresh on the Xeon.

Ugh. Picam is not working correctly. It works fine if I run it from the command line. If I launch it from the launcher it doesn't show a picture. Not sure what problem this may be but it's possible that mjpeg-streamer is not starting fast enough for omxplayer.bin to connect to - I noticed in earlier tests that omxplayer seems to start much faster now. I may need to synchronize this better.

Update: Just tested running the picam command manually: xterm -display :0.0 -fullscreen -fg black -bg black -e omxplayer.bin --live --fps 10 -o hdmi -r http://192.168.101.17:9090/?action=stream
That worked. I got the webcam on the monitor. So the problem is (likely) that the http port is not available when omxplayer is started.

I need a sync'ing method. I can either add a message to piboxd to tell me if the port is in use or I can test it manually in picam. The latter seems easier.

Picam's problem were not as bad as I thought. There were two problems. 1: permissions - I had mucked up permissions first on omxplayer.bin and then on picam itself while testing. Those don't require any fixes if we install from the packages. 2: permissions - picam can no longer switch VTs because it's not privileged. I don't know why that is happening now but I have verified it. The fix is to append /usr/bin/picam to /etc/appmgr.priv on package installation, if the entry does not already exist.

After I fix that I need to test the rest of the apps and make sure they are working before moving on to testing Xeon.

All media center apps seem to be working now except pixm, which has a different problem: ttyUSB0 is not found unless the device is connected at boot. So that's not really a build refresh problem and I'll deal with it later.

I'm going to push the updates for pibox and then build a Xeon (rpi1) release to test it.

Xeon is not working because the update includes a change to xf86DisableRandR() - drivers should not be using this anymore but the xfturbo driver is. Fortunately it is only called in one place. So the fix is to remove that call, apparently, or stub in a fake xf86DisableRandR() function that does nothing. Either would work, it seems.

This bug doesn't show up on media servers, kiosks or Ironman because none of them use "option Rotate CCW". Only Xeon has this problem.

I need to fix this with a patch in my PiBox build, then submit it upstream to Buildroot and/or the fbturbo driver repo.

This is fixed in the pibox repo and the commit is pushed upstream.

Another bug was exposed once we got past this one. The shadowUpdateRotatePackedWeak() and shadowUpdatePackedWeak() functions don't work unless you have the following code added to the xorg.conf:

Section "Module" 
        Load    "shadow" 
EndSection

Without this code the driver fails to load. This has been added to the xeoncfg package (committed and pushed). The X interface now comes up but the touch interface is not working because the touch coordinates are wrong. I'll fix that separately from this as xeon was never quite stable anyway.

I still need to test Ironman - I've only managed to bring it back up to where it was before. Now I need to test the updated code on it.

Ironman fails because the 2019.05 release of Buildroot has a bug in the dhcp installation. The version of dhcp was bumped to 4.4.1 but this version requires installing the binary from the src/.libs directory. Buildroot wasn't doing that so I got the libtool script for dhcp instead. The result is that configuration mode doesn't work because dhcpd is not started at boot.

There is already a patch for this so I grabbed it and integrated it into the build. That worked the first time I applied the patch and rebuilt so I now have a proper dhcpd binary under /usr/sbin. I can now continue testing Ironman.