On Thursday, February 19, 2015 at 5:02:45 PM UTC-5, Harvey White wrote: > I noticed that 4.2.2 doesn't even make the windows USB enumerator > beep... the 4.4.4 image I've tried, but several things seem not to > work, i.e. android comes up and says (remembering here: core services > not running and wallpaper not running). The mouse pointer seems to be > quite lagged, but I'm sending the HDMI output directly onto a monitor > right now.
Android uses OpenGL ES for its rendering, but the binary blob driver for the SGX GPU core on the BBB isn't supported under the 3.8 kernel. This means all of the rendering to textures and then scaling the textures is done in software. The larger the screen resolution that you use, the more sluggish the system will act. The TILCDC driver in the kernel will initialize the framebuffer resolution at the highest resolution supported by your display. Your HDMI/DVI display will report an EDID block to the kernel driver via your HDMI cable, and the EDID block contains a list of all modes the display supports. If your display doesn't report EDID information or your cable/converter blocks the EDID block, the resolution will default to 1024x768. You can edit the uEnv.txt file in the boot partition of the microSD card to add a "video=" kernel command line option to limit the size of the resolution. For example, "video=720x480@16" will limit you to 720x480, which will give you performance that is far more snappy than the performance at the higher 720/1080 resolutions. Apparently with android studio, I don't need QT, since the drag and > drop GUI is built in, one of the attractive features of android (also > that I can run the application on a number of other things I have). > Sorry about that. I meant use Qt as the widget framework under Linux or just use Android (as in, the Android API framework and GUI). You would not use Qt under Android. What compiler setup do you use for the Linux development? It seems > that Android Studio is the hands down best choice for the development > of the java code... I use a GCC toolchain natively on the BBB itself, Android SDK via Eclipse on the desktop, and the Android NDK for the native bits. For hardware interfacing, I write a small C program under Linux on the BBB to actually perform ioctl() calls, flip bits in mmap()'s registers, etc. Basically, all of the stuff that must happen on the actual hardware. Once that works well, I make a clean interface to those functions and build it as a library on the BBB under Linux and make sure everything is OK. That code is then moved over to my Windows system and built using the NDK. It is usually little more than a file or two, so the Android.mk for it is trivial to set up. I add the NDK-generated library into my project inside of Eclipse and then add in the appropriate JNI calls to access the native code. For straight Linux development, it is GCC on the BBB and GCC in a Linux VM on my desktop. I do much of the development on my desktop and then move the code to the BBB to shake out the x86/ARM 32/64 bit assumptions and get it working well on the BBB. Then, I move it back to the desktop and see what I broke. Do this a few times and you are in good shape. #ifdef's will assist you in isolating the platform specific stuff so that you can have code that will build and run on both platforms. I try to stick with the integer datatypes specified in <stdint.h> to explicitly specify data type sizes. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
