Jump to content

Sulthekk

Members
  • Content Count

    615
  • Joined

  • Last visited

Everything posted by Sulthekk

  1. http://horstmann.com/articles/cygwin-tips.html Although I have no idea why don't you just use a linux-based live disk or virtual machine, the fact that you installed windows on an official mac hardware makes me assume that you would only use a windows-based solution for this task. Although I don't use cygwin myself, the steps on the linked site seem to be fine.
  2. Yep, with google migrating many apps to the play store (calendar, for example) we could just strip those out, and if one is using it, he can install it to /data from play. I am not sure if by removing these apks we can go below 160, with a 'core' gapps, but it's a first step to less whining.
  3. It's 2013, and it's really time now for that resource hog & vulnerable crap flash to finally die. Seriously. It may were interesting 10 years ago, but we should get over it now.
  4. This is the Blade forum. Chances that anyone got a phone like yours are nearly zero.
  5. Right now I'm not near a computer, but I would check recents commits to SystemUI & Settings ( dunno what's missing in your build, hadn't tried it ) with cd 'path-of-git-repo-for-<package>' && 'git log --oneline'.
  6. Man if google translate couldn't handle these pretty common words like debugger, thanks and yes, I would be quite surprised.
  7. Elnézést, kik "mondják"? Persze, a Google-alkalmazottaknak ez a dolguk. Time-memory tradeoff ismerôs fogalom? Biztos optimalizálgattak itt-ott, de ezeknek a technológiáknak az egyidejû használata számításigényes: KSM: Idôrôl idôre végig kell nézni a memórialapokat. Csak a CPU képes rá. zRam: A tömörítést sem a GPU végzi, hacsak valahonnan nem kerítesz OpenCL-es drivereket adreno200-hoz, armv6-ra fordítva. Dalvik "optimalizáció": Az armv6 hivatalosan már egy ideje NEM kap támogatást a google részérôl, úgy kell visszahegeszteni a 4.X-es androidokra. Még ha kicsit csökken(het) is a memóriahasználat, az új JIT kódot armv7-re írták meg, nekünk marad a régi 2.3-ból átvett JIT kód foltozgatása. Szép a reklám, csak nem a Bladenek szól. :( Others: Sorry for not using english, I am too sleepy to translate that right now. Sum: see my previous post.
  8. There's been a lot of changes under the hood. Even with the lower memory footprint, we have no idea about compatibility, storage requirements, etc. Also, it seems to make use of zram, ksm to achieve that ram usage, which - while really reduces memory footprint - increases CPU usage. While we truly have 512Mb ram, we also have a legacy armv6 processor, which google doesn't even supports, neither within android itself, nor within apps like google now. PS: On the other hand, I recall KonstaT once said he likes a challenge, and he had already surprised us in the past. I wouldn't be surprised if he at least attempted a port, but don't keep your hopes too high - while 4.3 is a true miracle for our phones, every device has it's limits, and we have been on the borders for quite long now - KitKat may already be on the 'other side'.
  9. Fizziebaunz: My tips would be... Size of /system and /data, available free space, have you mounted /data with -o ro? When did it began, by the way?
  10. Although I don't have the code at hand, these errors make me think of removed/changed header files. Have you checked git log and git diff yet?
  11. These roms are made of the same base - but daemond's build is newer. It should have fewer bugs and more optimizations, and even more important: should have received more security updates both from him and the upstream cm repos. Your issue sounds pretty much like a buggy application waking up the device, btw. Have you tried to check for wakelocks first?
  12. Even without opening that link, I can tell by the url that this only the kernel source for their own device (which they MUST supply, thanks to GPL), but none of their MIUI/Android-specific code.
  13. Output and changes I *think* that although by adding an ld parameter I could get it working in case of the first object, the problem itself is very similar in case of notify.o It fails because of that 'undefined reference' in the paste, but usbfs_mutex is declared in usb.h of the very same directory, and is included with #include "usb.h" In case of msm72k_otg.o, the problem was the very same, as it got the same error with two methods declared in include/linux/usb.h, included with #include <linux/usb.h> Although I was able to continue compiling by adding notify.o as an input parameter of ld. But in case of notify.o, I have no idea what could I do to fix it (apart from the ugly copying of the contents of usb.h instead of including it, which in theory does the same). The preprocessor doesn't give a warning, it only fails at linking.
  14. Okay, it seems like the current kernel sources fail to compile with OTG enabled, but it seems to be just a few missing prototypes until now, so nothing too hard. I guess it's a remaining piece of mess from the original zte code release, layed hidden in unused ifdefs. P.S: I have been too optimistic. The first error was indeed a missing a prototype, but now I just can't sort out that 'undefined reference' in a way that doesn't involve ugly things like copy from header and paste into c file. I will try collect some outputs and post it there, because I'm no C jedi, and I ran out of ideas after spending hours googling the issue. I am however, now more interested in it than ever, so I guess I won't be sleeping well unless I sort it out. :(
  15. Okay, then I will try to do the compile with that kernel config enabled, although I'm not sure if any drivers are needed or not for your use case, but since you already got it working with another device I assume you already know how to sort it out.
  16. Just checked out KonstaT's current kernel sources, and there seems to be a config option for USB host/otg mode for quallcomm devices out of the box. I am not sure if it's working and/or it's safe to use, but I think there was a bricked phone at the thread you found, so we should be careful there. I have no proper cable near me to test (all our usb cables are plugged in somewhere), but I could build the kernel image for you, although I won't take any responsibility if you brick your blade with it. I think you also need to modify the Y-shaped cable so on one end only 2 pins are connected, but I can't clearly remember whether it's the data or electricity pins (the info should be somewhere in one of the old OTG topics though). Are you sure that OTG mode is worth the risk? Also please note that OTG haven't been tested on the Blade for quite a while, even if it worked, I have no idea if it has any stability/usability/performance impacts, I can only assume that your phone may become unable to sleep properly.
  17. I checked the source of the app, and it seems to copy ztepack under the /system partition. Could you check how much free space do you have there? Also, you can grab a logcat with 'adb logcat' if you have usb debugging enabled, or type su - logcat > /sdcard/logcat_tpthelper.txt Then post the newly created file somewhere (pastebin?).
  18. What is exactly the error? Can you provide a logcat? I would try myself but I don't really trust my current sdcard anymore.
  19. If you search for 'experiental cm7 kernel', there should be at least one cm7 (gingerbread) kernel that supports it, but it's quite old and is still 2.6.32. I think however, that there was a link to it's dource, maybe with some tinkering the patches could be applied relatively seamlessly to the latest cm7 kernel. I'm not sure if it would any harder with 4.X, because there were a lot of kernel updates, and I'm pretty sure they affected USB, at least because of tethering.
  20. Wow... Now I am surprised. After the silence around the Blade and all the impatient users who seemingly can't or refuse to read, I really didn't think you would keep going with this device. You patience seems to be nearly infinite. /bow
  21. It's disabled in the kernel for power saving as far as I can remember, because it makes the device unable to sleep properly - that was the (stated I haven't tried it myself) difference with johnsmithx's kernel, as was capable of OTG with proper deepsleep support. Btw, for OTG with the Blade you would need a special Y-shaped USB cable and a power supply anyway, because the phone doesn't give enough power to most USB devices.
  22. If it's bootlooping into the recovery it still has an all-zero IMEI. I'm afraid you need method 5 from hedgepigdaniel's thread.
  23. Well there were attempts to reverse engineer the original protocol, but I don't know of any known working implementations of the new protocol ( with a publicly advertised copyright for sniffing, lol )
  24. What about using something other than skype? Ever since microsoft started to modify it's code it became much slower and buggier on ALL platforms, and it lost it's famous encrypted p2p protocol (NSA rocks!!1!!1oneone), which was the only advantage of it.
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.