I would like to know about the case using opengles doesn't work on arm and why it was disabled. Is glshim built and used? Why...
The removal of GLES was a temporary patch to get Wrong moving forward with android chroot mode. He had GLES libs installed, which fooled the OCPN cmake script. I don't plan to push the patch to master. It is not good enough. We need more complex logic in cmake to detect all arm/GL cases correctly.
The only accessible OpenGL in the android chroot environment will probably be swX11, which is worse than no OpenGL, I suspect. I doubt that a standard GLES for gtk can find the Mali hardware in chroot mode, but I would love to be incorrect about that.
I have no native arm/linux/GLES capable hardware, so can't work this one directly. Sean and NahanniV are the best candidates to work this one out.
I am about to push OpenCPN 4.0 on OpenSUSE official repos and I would be interrested to know which plugins have been tested with 4.0?
I do not have the capability to check all of them one by one and having a list of the valid plugins would be of a great help for packagers like me who build the release for many people who will use it in configuration that we do not control what push us to include as many plugins as possible.
Yes, well the two possibilities are using opengles which should always accelerated if supported and opengl which may not be accelerated and usually isn't on arm. Before, by default it would attempt to use opengles on arm platforms if available which is maybe not complex enough logic.
I would like to know about the case using opengles doesn't work on arm and why it was disabled. Is glshim built and used? Why would you want to use software rendering when hardware acceleration is available? What is the problem and how can we fix it? If we can't fix it, how can we detect systems that can't handle hardware acceleration in the cmake file?
I can only guess, but believe your experience is primarily related to arm devices with a kernel installed along with the O.S.. The kernel provides drivers that are compatible with your device hardware and are directly controlled by your linux O.S. Not so when linux is running in a chroot environment on an android device - made possible only because the android kernel is a linux kernel. And here's the rub. A fully Linux compatible and linux controlled video device driver is unavailable largely due to proprietary restrictions. So, the 'normal' approach to achieving hardware accelleration doesn't work.
This doesn't mean there isn't a workaround that doesn't use glshim. The swx11 driver enables OpenGL in the chroot environment without using opengles.
Changes to the CMakeTexts.txt file simply make OpenCPN USABLE IN NON-OPENGL MODE IN A CHROOT ENVIRONMENT. I can't say why since my understanding of OpenGL and opengles is non-existent.
My sense is there should be a few questions posed during the cmake process that once answered can resolve this issue of platform compatibility in regard to OpenGL.
I thought I would post a quick update on the magnetic variation issue from the vYacht router.
Originally Posted by muttnik
...Reviewing Thomas Knauf's doc, seatalk variation is a single *signed* byte with positive values being west, negative east, so 0x01 is 1 degree west, 0xff is one degree east which is (I think) counter intuitive.
Yes, it is counter-intuitive, since the normal convention is the opposite of the way Seatalk does it. The guy who makes and sells the vYacht router wrote back confirming that he had the negative sign backwards, and that it will be an easy fix. He will send an update soon.
I continue to be concerned about potential discrepancies between the variation reported by GPS and compass. While my case was extreme because of an error in the Seatalk translator logic, even after that bug is fixed, there's the potential for the GPS to report 12.5° and the autopilot to report 12° (since it has not decimal place). Or, on a long cruise, the difference could be even larger if you do not re-program the autopilot. I would expect the GPS's reported variation to always be more reliable than the value manually programmed into the autopilot (since I bet a large majority of users don't even know how to change the variation in the autopilot). I think there should be logic built into O that causes it to ignore the autopilot's reported variation if GPS variation is available.
What sort of autopilot is this? Can you program the output sentence type? How about $xxHDM? This has no variation component at all, just the raw output from the flux-gate compass.
The Autopilot is a Raymarine ST4000+. It speaks SeaTalk, not NMEA, and there's no way to suppress the variation information. If you set it to zero it transmits zero variation, not a null reading.
My model of vYacht router has a Seatalk-NMEA converter. This is what generates $GPHDG. Bernd (the guy who sells it) makes the source code available, so if I were a programmer I could modify it to do whatever I want. But the web page to control the router just gives the usual router stuff - customize SSID, WiFi password, IP address, plus a couple options to set baud rate of the NMEA inputs. There is no user-accessible option to change NMEA sentences.
In theory I could ask Bernd to make a custom firmware for me, but I do think that the general scenario of O receiving two conflicting variation inputs (from GPS and autopilot) could be a rather common issue that O should filter out.
You are correct that more fine grained prioritization of message contents would be a good thing. Will need a more complex GUI, require more user smarts, etc.
I personally would not worry about variation differences of a degree or so. On most cruising boats, the heading sensor is not that accurate anyway, since the deviation compensation is not very precise, and its impossible to steer small to 1 degree in any seaway.
I also would suggest, if anybody asked, that the router really should not try to send variation in the HDG message. If it is known by the GPS receiver, then it will be available in the RMC message. In the present implementation, the variation in the HDG message is user programmed, so subject to displacement error. Recommendation: Just send the HDM message, raw compass data, and let the upstream sort it out. My 2 cents...
Bug in OpenCPN 4.0 Mac version
Open Properties window of a waypoint.
Try to write the small chars (no uppercase) a, c, l, m, o, q, s or t in the Description field of the Properties window.
This will trigger the shortcut function only but not write these chars.
For Linux or Windows version this does not happen.