how to make cydia tweak work on iphone 5s and later - jailbreak

i have work on my first tweak and also added 64-bit compatibility but it doesn't work on my iphone 5s but it does work on ipad 4. plzz help me to solve this issue.
here is my makefile
enter image description here

It might be because you included corrupt headers for example in some headers it shows
float functionName();
but in reality its
CGFloat functionName();
so when you compile the project it will run in 32 bit devices but not on 64 bit devices because your code think it will receive float while some times it will receive double on 64 bit devices
because CGFloat is a float on 32 bit devices and double on 64 bit devices. so you have to check the headers you are using and see if they contain float or double inside them because apple use their types a lot and they rarely use plain C types.

Related

Render YUV in JavaFX

I need to render a yuyv422 stream in JavaFX with minimum latency. If I convert it to RGB, I can use an ImageView with a WritableImage with a PixelFormat instance, and it works, but the RGB conversion consumes a lot of CPU, specially with high resolutions. I saw this exact feature request
https://bugs.openjdk.java.net/browse/JDK-8091933
but seems it will not be implemented in Java 9. And if it does, I wonder if it won't introduce latency or demand too much CPU. Is there another way using JavaFX?
In General:
Image processing is always expensive, this is why Vectorization or Hardware Acceleration is used for these tasks. Simple looping through an Image with just one thread is already really slow, especially in java. On top of that people tend to use Color objects for color modifications which is tremendously slow.
Pure Java:
If you want to keep your code in pure Java. You should check which internal format is used for the WriteableImage by calling:
myImage.getPixelWriter().getPixelFormat().getType()
If the internal format isn't RGB adapt your color conversion to the given format to avoid double conversion.
Additionally make sure that your code is optimized as much as possible:
-Don't use any objects except arrays
-Minimize the use of local variables
You can also try to multithread the conversion process via parallel loops.
JNI:
Moving away from Java opens up a lot of possibilities. There are several platform independent libraries for converting YUV to RGB and back:
OpenCV:
Easy to use and coming already with an java API:
byte[] myYuvImage = null; //your image here
byte[] myRgbImage = new byte[width * height * 3]; //the output image
Mat yuvMat = new Mat(height, width, CvType.CV_8UC2); //YUV422 should be 2 channel
Mat rgbMat = new Mat(height, width, CvType.CV_8UC3);
yuvMat.put(0,0, myYuvImage);
Imgproc.cvtColor(yuvMat, rgbMat, Imgproc.COLOR_YUV2RGB_Y422);
rgbMat.get(0, 0, myRgbImage);
Intel IPP:
Only available via JNI. You would use ippiRGBToYUV422_8u_C3C2R see RGBToYUV422 for more information.
SwScale as part of FFmpeg:
Only available via JNI. See this answer and adapt the example.
My personal experience is that IPP offers by far the best performance even on AMD machines. However the license it comes with may be free but it prohibits decompiling which might be an not compatible with LGPL libraries.

Using float or double for own QML classes

I've created some components and helper methods using C++ and Qt to be used in my QML GUI. Some of those methods calculate GUI elements (size, transformations, scene graph items creation). The target is an ARM 32 Bit using OpenGl / Eglfs to render the output.
OpenGl is using float, QML is using real (defined as double).
What should I use in C++ to do not lose any precision?
If you use qreal (double) then you shouldn't lose any precision. If you git grep float in qtbase.git, you can find out a bit more:
dist/changes-5.2.0-****************************************************************************
dist/changes-5.2.0-* Important Behavior Changes *
dist/changes-5.2.0-****************************************************************************
dist/changes-5.2.0-
dist/changes-5.2.0- - Qt is now compiled with qreal typedef'ed to double on all
dist/changes-5.2.0: platforms. qreal was a float on ARM chipsets before. This guarantees more
dist/changes-5.2.0- consistent behavior between all platforms Qt supports, but is binary
dist/changes-5.2.0- incompatible to Qt 5.1 on ARM. The old behavior can be restored by
dist/changes-5.2.0: passing -qreal float to configure.
It's interesting to note that within Qt, there are large pieces of code that have switched to using only float:
commit 51d40d7e9bdfc63c5109aef5b732aa2ba10f985a
Author: Sean Harmer <sean.harmer#kdab.com>
Date: Mon Aug 20 20:55:40 2012 +0100
Make gui/math3d classes use float rather than qreal
This corrects the mismatch between using floats for internal storage
and qreal in the API of QVector*D which leads to lots of implicit
casts between double and float.
This change also stops users from being surprised by the loss of
precision when using these classes on desktop platforms and removes
the need for the private constructors taking a dummy int as the final
argument.
The QMatrix4x4 and QQuaternion classes have been changed to use float
for their internal storage since these are meant to be used in
conjunction with the QVector*D classes. This is to prevent unexpected
loss of precision and to improve performance.
The on-disk format has also been changed from double to float thereby
reducing the storage required when streaming vectors and matrices. This
is potentially a large saving when working with complex 3D meshes etc.
This also has a significant performance improvement when passing
matrices to QOpenGLShaderProgram (and QGLShaderProgram) as we no
longer have to iterate and convert the data to floats. This is
an operation that could easily be needed many times per frame.
This change also opens the door for further optimisations of these
classes to be implemented by using SIMD intrinsics.
As it says, this was to avoid surprise loss of precision as the functions took qreal (double) but stored their data as float. If you use qreal everywhere in your own code, you won't have this problem.
The other reason was performance. I can't comment too much on that, but I'd say that it's more important for Qt to optimise for such things than it is for most users of Qt.

Reserving flash location for EEPROM emulation STM32F4

I want to emulate EEPROM in sectors 2 and 3 to keep erase time low (small 16kb sectors).
My question is how to go about reserving this flash space to prevent compiler from placing program code in these sectors?
Can anyone point me to info on this I haven't found anything that makes sense so far?
Thanks
From Application Note AN3969, the best approach would be, as you have said is to use Sectors 0-3 since they are only 16kB.
My question is how to go about reserving this flash space to prevent compiler from placing program code in these sectors?
In your linker file (*.ld) declare the start of your Flash to be at the beginning of Sector 4 so that the Linker places your code beginning at that address eg.

Radeon HD 4850 and OpenCL: will cl_khr_fp64 work on this videocard?

This videocard (Radeon HD 4850) conforms only with OpenCL 1.0, per AMD Compatibility table. I need some hardware to conduct intensive financial calculations with doubleN types (no floats at all!). According to this cardtable, this card is able to work with double types. Now I have the possibility to buy it at quite an attractive price.
I'd greatly appreciate if an answerer has real experience in working with this card for OpenCL with fp64 extension. Of course, if there are problems with this card, please put two lines here.
Thank you and sorry for my English.
I haven't used this card with DP before, but if the spec says it is supported, then it's worth a try.
In my opinion, you should go with a newer model card though. There are a lot of cheap cards out that will outperform the 4850, and they will support some new features as well.
This card supports double precision but the 4xxx series doesn't include local memory in the chip. As the standard mandates local memory support it is emulated with global memory and very slow. Many algorithms require local memory for obtaining a good speed-up. So, a newer card 5xxx and higher is a lot better.
In addition, some combinations of older cards/older SDK versions only support double precision through the cl_amd_fp64 extension (not the official cl_khr_fp64 extension) because of some small things from the standard that are not supported. For the most part, this doesn't matter much except that you need to change the extension name in your code to make it work with doubles.
As a general tip, I would try to avoid the 4xxx series if you intend to make serious GPGPU development. Keep in mind also, that the newer 7xxx series it is much more optimized for GPU computations than both the 5xxx and 6xxx series closing much of the gap with NVIDIA cards. So, if you can, try to aim for a 7xxx with double precision support.

Programming microcontroller to store images and displaying them as a dia-show with an dvi/hdmi output in several resolutions?

I would like to solder a microcontroller, control buttons and an DVI/HDMI output and program this in a way, that I can store images on it and let them display as a dia-show via the outputs.
It doesn't have to have a lot of storage capacity, 128Mb would be enough.
but I don't know how to start, because I haven't done anything like this before.
My aim is to present some important images to friends by just taking this hardware, connecting it to a TV screen and showing these photos. If should be able to switch the photos manually (using a button) or automatically in a dia-show.
It should support several TV resolutions and it should be connectable to my PC (USB prefered), so that I can upload and delete photos.
So where to start and how to do that?
Thank you in advance, Andreas
If your aim is just to show some photos, there are assuredly simpler and more cost effective ways to do so; devices exist which do more or less exactly what you are proposing.
If your aim is to learn about microcontrollers and this is a project your are taking up to further that, I would recommend looking into the Arduino: http://www.arduino.cc/ or a similar kit based micro, and growing your project from that.
Microcontroller + low level language will be a huge pain to work with, particularly if you wish to handle various file formats and screen resolutions. Get a full-blown computer with an OS instead - something like http://en.wikipedia.org/wiki/PC/104
If your goal is purely to be able to display photos then I would recommend using a digital camera with video out capabilities.
If your aim is to learn about electronics and microcontrollers I would start with a good book and an Arduino board. Note that writing microcontroller code to handle file systems, image formats and video output is non-trivial. Simpler projects may be a better starting point as they are more accessible resulting in quicker progress, less frustration and more motivation!
The engineering field is a interesting field. You can start with the web site "www.microchip.com". You will need a high end device consider the PIC32MX795L512, there is a nice starter kit for it, "Ethernet Starter Kit" http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2615&dDocName=en545713. This kit has the on board debugger & programmer to do all the hard work.
You get sample projects with the package, you can program using ansi c programming.
IDE : MPLAB which is free, and the C32 compiler has a student/lite version.
Arduino also has a board with the same device.
I personally like "www.techtoys.com.hk", they have device compatible with Microchip boards like techtoys.com.hk/PIC_boards/PIC32STK%20SSD1963%20EVK/PIC32STK%20SSD1963%20EVK%20R1A.htm, or this techtoys.com.hk/PIC_boards/PIC2432EVK-RD4/PIC2432%20EVK%20RD4.htm where this board you will need a debugger/programmer like the low cost PIC Kit 3 "microchip.com/pickit3".
The trouble is you need to write the HDMI video library yourself, there are some VGA libraries available but they are only black and white and very hard to get color with these analog images. The rest of the libraries are already there, USB MSD(flash drive), SD Card, pictures (jpg) etc.
microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2680&dDocName=en547784
Feel free to contact me if you need some help, I might be able to help with the HDMI library.
It's a lot of fun to play with these toys.
Regards
Lucas
B-Eng Digital Engineering.
imlucanio#yahoo.com (no spamming)
Remember to add the http and www to the web links.
It sounds like you want an iPod. That is a dead simple thing to work with and it does everything you want. Otherwise, very complicated. I'd suggest the BeagleBoard and embedded Linux. Yes, it warrants that level of complexity.
The options for small microcontrollers just aren't there. The Arduino is very popular and yes, you can interface an SD card to it. That'd be your storage. Yes, you can put a digital potentiometer on it, that can be your interface. I've seen some video overlays that do simple text, but never any JPEG display (too much processing required). And certainly no 24 bit color (so that the output would actually look good) - that would take WAY too many pins to do correctly (and the Arduino doesn't have a D/A converter! You'd have to rig something up that would suck). And even then, all of the options for TV out weren't HDMI, but RCA (the old red/white/yellow cables).
So in short, no. Get a computer. That's what can do the job.

Resources