yashsingh1/xdaforums huggingface dataset:
[Sony Cross-Device General] aquaboy11:
The Z3 and Z3+ use a slightly different sensor to fit the Z3's slim design right? As far as I know the Z1 and Z2 use the imx220 and the Z3 the imx220s (which I guess stands for small :p).

I was looking for devices also using the imx220 sensor to see if any of them had source code available. After some time of searching I found this. It is source code for the Meizu mx4 kernel, including the imx220 kernel drivers, or well, they look like drivers to me.

Proprietary BLOBS are essentially drivers too, but closed source, right? On that Github there are 2 imx220 drivers, one uses an eprom from Sharp, and the other from Liteon. Do we know which one Sony's sensor uses? It should be possible to build/port this driver for Qualcomm devices right?
[Sony Cross-Device General] jerpelea:
no that is not possible

you have a leaked chromatix that you can use as inspiration and write a hexeditor
[Sony Cross-Device General] gregbradley:
Thread temporarily closed

I suggest everyone takes a break and a deep breath.

This will be looked into....

Greg

EDIT

[MENTION=535343]all[/MENTION]...

A moderator has already stepped into this thread. Now I am having to do the same within a few days.

This is a dev thread. Let me remind you that RDs and RCs are held to a higher standard of conduct.

THERE WILL BE NO MORE ARGUING IN THIS THREAD.

Take any issues you have to PM and stop doing this in an open thread.

Finally, this thread is open to anyone, as long as the post is dev related anyone can post here.

I will be monitoring this thread and if people do not live up to the rules and the standards set by XDA then we can go further....

Greg
[Sony Cross-Device General] munjeni:
I don't have leaked source, I just found one time an old source (if I am not wrong from arm6) on google search, thats all. Anyway your idea is realy good but hard for implementing because we can ques only on that array structure which nobody know what each one have usage for
[Sony Cross-Device General] jerpelea:
i am sorry but this is Qualcom proprietary code and i can not help you with this "hard to implement"

as far as i googled there is already an editor fot the libs and you just need to adapt it
[Sony Cross-Device General] drakonizer:
https://github.com/remittor/chromatix2c

This appears to be a chromatix editor, but meant for old versions of the binary. We could possibly adapt this.

There is a russian website with a bunch of leaked proprietary code. It contains stuff for msm8974 as well, obviously not armv6. But it's based on the 3.4 kernel and Android Jellybean. I don't know what you can do with it, but it may help. I will not post the link here, you are free to google it.
[Sony Cross-Device General] munjeni:
No prob I understand. I compared v5 and v6 and saw that you didn't modified chormatix, is that mean camera darknes is not related to chromatix? Or you have plan to do something in v7 ?
[Sony Cross-Device General] nailyk:
camera d6603

Yesterday I made some tries:

It seems the preview doesn't work when preview size is different from full sensors resolution. Is it the same on other devices?

From the camera log the apps requesting a 1440*1080 preview:

and some lines after the binary can't handle this resolution:

then the log is spammed of failures. (full camera log in attachment).

This correspond to my experiments: only apps with full sensors size preview display the live preview. However one of my app, with black preview, is still able to focus and take pictures.

About darkness this picture is not that bad but iso is really high: exif (don't look at disorder on my desk :)). I didn't look further at this problem but can it be a enum problem? Eg: the app request ISO_3200 = 5 and somewhere 5 is now ISO_100 ? I mean the taken picture at 3200 doesn't look like overexposed or noisy because a high iso value.

I still didn't understand what happens to the front camera preview so will experiment before. The rear sensors report a max of 2Mpx and is 90° flipped but picture looks not that bad too.

Can someone confirm this or am I looking into the wrong direction?

From my (old) readings of the sources, some important files are common/cam_types.h and common/cam_intf.h. Those headers should be the same than the binaries to avoid unexpected results (like struct upgraded into one an not the other, etc...). I know you can't release sources, but maybe there is a way to compare the open source vs proprietary headers and upgrade if needed?

Btw is QCamera_Intf.h still needed? Some of structs into are no more up-to-date and can't find #include of this file:

nailyk :) % rgrep "QCamera_Intf" ~/cyanogen/14.1/hardware/sony/camera
nailyk 1 :( % ~/cyanogen/14.1/hardware/sony/camera

Thanks for reading and please don't be too rude I'm pretty new to this :)
[Sony Cross-Device General] SuperLamic:
seems same on my device... it works as long as it doesn't need to crop it. It says those crop error messages even if you request full size, but it works.

Do anyone have any idea why the preview is limited to 15 fps?

11-20 20:15:44.142 446 9818 E mm-camera: sensor_set_resolution:2052set_fps=30.000000 > max_fps=15.000000, capping to max
[Sony Cross-Device General] jerpelea:
yes i am working on it
[Sony Cross-Device General] jerpelea:
headers are what they should be

you are comparing 2 different camera frameworks implemented on 2 different kernels
[Sony Cross-Device General] munjeni:
Default parameters is picked up from sensor and blobs and I think we can do nothing about that, only we can do is to fixup parameters (make static) in hal or to wait new blobs. The best idea is to provide devs more information so dev can look for posible fix in next blobs..
[Sony Cross-Device General] munjeni:
Probably an dlopen to extract all that arrays from chromatix would be a good start point (comparation first)...
[Sony Cross-Device General] nailyk:
That is exactly what I have in mind: do some tests about preview size, collect relevant logs and open a sort of bug report.

For now all my experiments are really fresh as the first usable rom I was able to produce is 3 days old. And since all the '-caf' branches where deleted from SonyCM I will not be able to build another one for a while. Maybe I will reupload the caf dependencies to another git for the transition time.

About deep sleep I have some clues too (at least for d6603): it seems to be related to USB & ril. If you enable airplane, then reboot the device without USB/charger attached, the 'Awake line' is fine and on this screen shot device announce 3 days left.

As I said all those experiments are fresh and I didn't really analyse the /sys/kernel/debug/wakeup_sources file for now, but USB seems to produce a constant wake_lock as soon as a plug had been detected. Otherwise the ril can be switched without rebooting and the wake_lock is removed. (seems to be the same without sim card).

Hope this help anyway.
[Sony Cross-Device General] munjeni:
Did you tried usb patch which I provided some pages back? Don't forget to enable config sony usb extensions in defconfig. Usb is ok for me.

About ril, there is realy something, for example swith 2g-3g-etc not doing what is expected, instead I must enable airplane and disable ariplane to get swith working. Somebody also reported no internet (in most times)...

Anybody tried stock rom ril + radio firmware + extract sony framework ril class and add to the AOSP?
[Sony Cross-Device General] SuperLamic:
I guess you can't really make it that easy... in the times of cm12.1 there was a wrapper to stock blobs and I guess google probably again changed ril api in nougat/marshmallow...

More than that... there is no wakelock on CM built on sonyxperiadev sources... so blobs probably are not to blame
[Sony Cross-Device General] MIcHiJK:
Deleted. Sorry wrong thread.
[Sony Cross-Device General] munjeni:
Thats great, but is mobile net working good? No problems with ril things?
[Sony Cross-Device General] SuperLamic:
yep, no problems.
[Sony Cross-Device General] munjeni:
If I not forget... Cm source for sony used SonyRil.java as a part of the telephony class, is that present now?
[Sony Cross-Device General] davidteri91:
https://youtu.be/QRjVBPW-kHQ

Inviato dal mio F8131 utilizzando Tapatalk
[Sony Cross-Device General] SuperLamic:
it's not using any external classes nor any wrappers. https://github.com/SonyCM
[Sony Cross-Device General] munjeni:
Thats interesting. I will compare framework and ril source to get what is a diferencie...
[Sony Cross-Device General] nailyk:
I didn't try your patch for now, but iirc someone push it into the kernel I will check all of this next week-end. sony_usb_extensions is enabled.

[MENTION=6063329]malacha[/MENTION] also report ril as working on D6603, data and calls.

First impression for z3 is nfc, deep sleep, screen flickering, and obviously camera, need to be improved/fixed. Everything else is fine. Need to test further nevertheless.
[Sony Cross-Device General] munjeni:
Uh, a ton of diferencie in frameworks/opt/telephony -> http://pastebin.com/Fhctzw8L

and hardware/ril -> http://pastebin.com/0beTbWpn
[Sony Cross-Device General] mcgi5sr2:
Could be a lot of CAF fixes got merged into CMs repos. Also I know CM have been porting forward a lot of fixes from previous versions of android...
[Sony Cross-Device General] munjeni:
Yes, I saw small diferencie in ril but I saw a ton of diferencies in framework part, a ton new cases and definitions, telephony-ext which is from codeaurora is also used on cm... etc. One question trought, is more stable cm now in comparation to aosp?
[Sony Cross-Device General] :
CM13 has to be built only with the 6.0.1 binaries? Can it be built with 7.1 ones?
[Sony Cross-Device General] drakonizer:
Technically there are no 7.1 binaries. All the binaries till now are meant for 6.0.1. They just work on 7.1. So you could use the latest binaries from XperiaDev for MM and N.
[Sony Cross-Device General] munjeni:
Small diff between cm and aosp says everything about aosp 7.1.0 outdated telephony, aosp contain 8 years old telephony source code which I think... nothing to think other than I definitelly stoped playing aosp :)

--- a/telephony/java/android/telephony/TelephonyManager.java
+++ b/telephony/java/android/telephony/TelephonyManager.java
@@ -1,4 +1,7 @@
/*
+ * Copyright (c) 2014, The Linux Foundation. All rights reserved.
+ * Not a Contribution.
+ *
* Copyright (C) 2008 The Android Open Source Project
*
[Sony Cross-Device General] erikcas:
so that copyright update is a result of CM adding privacy guard in this commit. Yeah, that really makes AOSP source outdated.

As this is git, and files are evolving during development, it is imo not right to say this file is outdated based on copyright changes. It is maintained recently as you can see here

I think one should doublecheck in order to provide people here with proper information
[Sony Cross-Device General] munjeni:
p@to no. That mean... I have done full diff between cm <-> aosp framework/base/telephony and framework/opt/telephony, there is not just copyright headers diferencie, there is not just privacy guard changes, there is many more changes which realy makes aosp telephony outdated. That mean I will probably swith repo to cm
[Sony Cross-Device General] erikcas:
Sorry, I have no intention to open fire on anyone. I never had (also not previously in this thread). I am sorry if you take it that way. And, as well as you do, I always say (or better, type) what I think

About the outdated thing. This is the way I look at it. Please note, this is a personal opinion. That does not mean it is a fact and offcourse anyone is free to think otherwise without any disrespect from my side:

Afaik, every custom rom rebases their sources on new AOSP releases, or pull AOSP releases into their sources. Also CM does this, see for example here

Everything customs do, is based on evolving AOSP. Apart from that, extra functional things from caf or self developed are added. But the base will always be AOSP and its (constantly developed) API's and basics.

So, the source of customs will in that context allways follow AOSP in basis. Development from customs that do improve AOSP, will end up in AOSP itslef if accepted there.
[Sony Cross-Device General] nailyk:
About screen flickering we start to hijack the 7.1 z3 thread#164 about it.
[Sony Cross-Device General] gregbradley:
I will deal with this shortly. But it is disappointing that a dev thread has shown such lack of respect to each other.

EDIT

Hello all.

Last warning before further action is taken.

This is a dev discussion thread. As such Devs are expected to discuss issues. All development related posts are welcome and no one can say who can post and who cannot post here except the Moderators.

When developers discuss issues it is to be expected that some have different opinions than others, buts lets be grown up about this and understand that its these differences that make Android so great. Often there can be more than one solution and more than one answer and more than one opinion.

Please let me point this out to you all

Recognized Developer Code of Conduct

Those of you with the RD title are and will be held to a higher standard than normal users, and the rules apply to you as well.

If you have any issues with each other, keep it to yourself or do it in PMs. Open forum arguments will be dealt with in accordance with the rules.

EDIT

Hopefully this will be my last post here on this issue.

I am going to re-open this thread after nearly 2 hours of sorting this out. Do not waste my time again.

Greg
[Sony Cross-Device General] nailyk:
Here is the patch which solve flickering issue on my panel.

I'm currently rebuilding for some of my tester to be sure it fix for everyone before PR.

Any feedback and test are welcome :)

(commit message, content, etc...)

Thanks.
[Sony Cross-Device General] Myself5:
Be sure to mention what you got the updated values from.
[Sony Cross-Device General] erikcas:
are you sure you have to change that amount of lines? I remember we had black lines on a particular amami panel. I started with changing a whole lot of lines of code. In the end I ended up with only some minimal lines changed, see here

I am sorry I cannot test and help with this one, donot have the device. But the point is, check if you can achieve this with minimal changing
[Sony Cross-Device General] nailyk:
Thanks.

Yes less are needed but improve panel at the same time. Should-I split into multiples commits?

My most problematic issue is those value are ~random as I can't get a proper MIPI doc. Rob Clark just mention I do it the best way available but I really hate pushing value I don't understand. From what I understand of those hex value is the init is not the right one after switching to command mode. With one build a get the panel working with the default dtsi, so I steal value from this one. (That is why I didn't mention where they are from).

One of my tester report as fixed anyway.

What are your advice on this?
[Sony Cross-Device General] erikcas:
personally, I would have split the "remove deprecated cont-splash-enabled flag" from this commit. Because you are doing two different things at the same time here, i.e. removing something obsolete and you are fixing something else

Can you check if only changing "somc-dsi-init-command" does the trick?
[Sony Cross-Device General] nailyk:
Thanks a lot. I guess this one is better ;)

And I made the spitted commit (btw I think it should be reported into other dtsi files, maybe sed could help on this).

I need to do more tests to check edge side effect before PR but looks fine now. Btw I really think about reverting the panel back to command mode which is more efficient.

Thanks again!
[Sony Cross-Device General] jerpelea:
please pr the auo commit. now it is clean
[Sony Cross-Device General] mcgi5sr2:
We are still getting echo on the line and a static in call volume issue on the d5803 with latest sources. [MENTION=546141]rancid[/MENTION]frog has provided logs

https://github.com/sonyxperiadev/device-sony-aries/issues/49#issuecomment-263256754

is the issue isolated to the Aries or do Leo users have this issue as well? Similar question to Honami board devices?

update

same issue in CM builds
[Sony Cross-Device General] erikcas:
cool, it was merged :p good job
[Sony Cross-Device General] nailyk:
wake_lock issue

Some help wanted :)

We are experiencing a lot of wake_locks issue on our z3 (see screenshots).

After a bit of debug it seems they are essentially caused by RIL, probably around this error:

BatteryStatsService: modem info is invalid: ModemActivityInfo{ mTimestamp=0 mSleepTimeMs=0 mIdleTimeMs=0 mTxTimeMs[]=[0, 0, 0, 0, 0] mRxTimeMs=0 mEnergyUsed=0}
frameworks/base/services/core/java/com/android/server/am/BatteryStatsService.java:[URL="https://github.com/CyanogenMod/android_frameworks_base/blob/cm-14.1/services/core/java/com/android/server/am/BatteryStatsService.java#L1541"]1541[/URL]: Slog.e(TAG, "modem info is invalid: " + modemInfo);

But didn't check this one at the moment.

The other important one is about usb/charger. To debug easily I made this commit. Then I produce the issue: start the device with usb, unplug it after a few. Here is the result:

% grep WAKE /tmp/dmesg4.log
[ 5.219669] BMS: qpnp_bms_probe: WAKELOCK: exiting with rc -517, check wake_lock was destroyed
[ 6.350353] BMS: qpnp_bms_probe: WAKELOCK: Init low_voltage_lock
[ 6.350358] BMS: qpnp_bms_probe: WAKELOCK: init cv_lock
[ 6.505610] qpnp_charger_probe: WAKELOCK: Init unplug_charger
[ 6.505614] qpnp_charger_probe: WAKELOCK: Init chg_gone
[ 6.506994] register_dock_event: WAKELOCK: init dock_lock
[ 6.507115] qpnp_chg_usb_chg_gone_irq_handler: WAKELOCK: chg_gone set to 600 ms
[ 103.533909] check_unplug_wakelock: WAKELOCK: Set unplug wake_lock to 200
[ 103.571020] qpnp_chg_usb_chg_gone_irq_handler: WAKELOCK: chg_gone set to 600 ms
[ 399.481805] check_unplug_wakelock: WAKELOCK: Set unplug wake_lock to 200
[ 399.519394] qpnp_chg_usb_chg_gone_irq_handler: WAKELOCK: chg_gone set to 600 ms

We see some lock aren't released, like the dock_lock.

I also notice the same append on some IRQ locks but absolutely don't know how they works.

Some of them (312, 314, 299, 323 for example) are never released. I even don't know if this integer is fixed :s

As I never work with wakelocks before and I'm experiencing with a potential dangerous thing (battery) how can I debug more to find where the lock should be released?

Could I try safely to call wake_lock_destroy() on specific exits? Is it more safe to test with preventing wake_lock_init() be called or set a timeout?

Thanks in advance.

P.S.: this PR wasn't included while experimenting.
[Sony Cross-Device General] SuperLamic:
hey,

I had the same feeling about the modem errors... not sure if it's really the issue...

but today there were some wakelock commits commited by David, can you try it now? (since I still do not have my pc)

https://github.com/sonyxperiadev/device-sony-common/commits/master + https://github.com/sonyxperiadev/device-sony-common/pull/158

and of course the kernel commits...

edit: you have a nfc wakelock, have you had nfc disabled? I have radio wakelock
[Sony Cross-Device General] SuperLamic:
haha, love computer networking lessons, so bored that I actually found the modem values settings :D

https://github.com/CyanogenMod/andr...m-14.1/core/res/res/xml/power_profile.xml#L55

but I guess I not the issue... it just needs to write it to device config.

https://github.com/sonyxperiadev/de...rameworks/base/core/res/res/values/config.xml

edit:seems like I confused it for something else...
[Sony Cross-Device General] nailyk:
Looks perfect! And this was introduced by android 7.0. That can explain why you have it too on AOSP. And from the AOSP doc it could explain why we are experiencing those wake_locks on all 'antenna' peripherals.

Now we need to find datasheet for our devices...... Qcom is our soc manufacturer iirc. So every datasheet access will be restricted :s

Edit: I still have no idea on what I can test for the kernel wake_locks.
[Sony Cross-Device General] SuperLamic:
wait... ril wakelock came to us when we switched to 1.3.3 branch... some guy with amami tested that it's present even on MM (1.3.3 branch)
[Sony Cross-Device General] nailyk:
Interesting. In the meantime I figure out the comment is:

and it shouldn't be our case.

Also hammerhead (which is almost the same that z3) doesn't have it.
[Sony Cross-Device General] SuperLamic:
yeah, as I said in edit of previous comment... unfortunately I mistook it for something else...
[Sony Cross-Device General] :
With the help of my friend [MENTION=6979267]nailyk[/MENTION] I managed to get CM14.1 to the aries device, getting a rather stable build.

We know CM builds are not that stable for Sony phones. I got some bugs here, that I can't explain to myself, so I'm wondering if it' a CM bug or if anyone got across them in time.

-Equalizer does nothing when listening to music.

-System sounds are loud and can't be changed.

Thanks!
[Sony Cross-Device General] SuperLamic:
about usb wakelock, try this: https://github.com/rcstar6696/kernel/commit/fc3f0f55cdc165796c0117b89330c88165b5c4f2
[Sony Cross-Device General] nailyk:
It workaround the usb wakelock issue thanks.

I try to find the source of the problem and it seems the call to dwc3_msm_pm_suspend happens at boot time:

and not after:

if the device is booted with cable plugged-in.

This _suspend function seems to be called by a function pointer directly into the module device pointer.

I loose myself here. No way to get how usb_otg.c call/not call this function. It seems to be an event but all event disappears from dwc3 with this commit.

However when reading usb_otg.c suspend functions I notice this FIXME. The description can match our problem, if we assume that our system try to suspend really frequently.

All the usb_otg.c log goes into the debugfs. Need to find a way to read it.

P.S.: function pointer explanation.

P.S.2: add the output quoted.
[Sony Cross-Device General] munjeni:
You can check if platform_device dwc->xhci is allready present. Try to comment all between line 233 and 254 , see what is happen. In most case problem can not be isolated if more debug logs is not enabled, I have done the same while worked on ac charging detection
[Sony Cross-Device General] nailyk:
While managing how to apply what you said I notice this workaround.

Now we know the cause of the usb lock problem. Sadly the comment doesn't explain why the chip will get damaged or how to prevent the damage...

Maybe we can find some datasheet for this one and try to figure out?
[Sony Cross-Device General] munjeni:
Compare dwc3_otg.c with one from newer sony stocks kernels maybe you can see something new
[Sony Cross-Device General] nozz93:
Might be a little off-topic, but can any camera improvements be implemented into CM12.1 (on the Z1C)? It still has the issue that the camera "breaks" at some point and can't be used until the phone is restarted. Otherwise, I'm quite happy with CM12.1.
[Sony Cross-Device General] iXaidyiu:
Please post somewhere else here, this a DEV-ONLY thread.
[Sony Cross-Device General] SuperLamic:
hey guys,

I found the problem that causes us the ProxyController issue. A bit of magic is that shinano doesn't have this issue, probably because it has MM modem blobs.

The problem lies in blobs - they don't support new methods that were added in N/MM. We're having problems with getting capabilities from modem (lte, 3g ...). Google thought that there may be modems that doesn't support this, so they can return REQUEST_NOT_SUPPORTED and some static values are returned. Unfortunately for us, our modem returns something like "v6" and android ril passes the value to ProxyController that ends up in some error state which doesn't release wakelock.

Lineage has a support for ril class override, so we can use this: https://github.com/SuperLamic/andro...mmit/e0789a7d72ef48975b525d33dfaefecc0ea2ed56 but to fix aosp (without modifying the source) we need Alin to modify the blobs (probably).