Action Item #687
|Status:||Closed||Start date:||04 Feb 2019|
|Category:||00 - Basic Build Issues|
|Target version:||1.1.0 - Upgrades|
|Severity:||01 - Critical|
This issue will be used when I'm refreshing the build to make sure all URLs and meta builds are working properly.
RM #687: Build refresh: Add ubsan.c patch to allow gcc 7.x or higher to build linaro toolchain for rpi1 build.
RM #687: Add support for building either from master.zip or a specific git commit. This became necessary when use of V4L2_EVENT_SOURCE_CHANGE was added to the master branch. I suspect support for this #define will show up with a kernel bump, but until then we can build using USEGIT=1 to use the last known commit that builds.
RM #687: Remove devmem2 from buildroot. It's not being used and the upstream is not reachable.
RM #687: Bump back up to master branch to pick up fixes for use with glibc > 2.7 (PiBox is bumped to 2.9).
RM #687: Refresh PiBox core development components: xcc 1.24.0, Buildroot 2019.05.01. Drop xcc 1.15.2 and 1.18.0, and custom kernel 4.19.y config (use defconfig instead).
#7 Updated by Hammel over 1 year ago
- Verifying commands are being sent to the FIFO via the video player.
- 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.
#8 Updated by Hammel over 1 year ago
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.
#9 Updated by Hammel over 1 year ago
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.
#10 Updated by Hammel over 1 year ago
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.
#11 Updated by Hammel over 1 year ago
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.
#12 Updated by Hammel over 1 year ago
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.
#13 Updated by Hammel over 1 year ago
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.
#14 Updated by Hammel over 1 year ago
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.
#15 Updated by Hammel over 1 year ago
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.
#16 Updated by Hammel over 1 year ago
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.
#17 Updated by Hammel over 1 year ago
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.
#18 Updated by Hammel over 1 year ago
- Status changed from In Progress to Closed
- % Done changed from 80 to 100
Ironman is effectively working except I found some bugs in both libpnc and imwww. I can't test this any further till those are fixed but I think it's proof enough that the bits required of the build refresh are there and are not causing these problems.
Xeon also comes up but has multiple problems. None of these are related to the build refresh. Xeon is still in early development and bugs are being tracked separately.
This issue can therefore be closed.