Jump to content

tdm

Members
  • Content Count

    801
  • Joined

  • Last visited

  • Days Won

    84

Posts posted by tdm

  1. 2 minutes ago, SchattengestaIt said:

    So is the official ready to install (without wiping) or should we wait until you know which file is supposed to get deleted?

    When the official build appears, you may download it and attempt to install.  If it fails, it will likely be due to a signature check.  You can avoid this by deleting /data/system/packages.xml.  There should not be any other issues with installing the official Lineage build.

     

    • Thanks 5
  2. 1 minute ago, Wheeljack said:

    Are you going to write a little tutorial for how to switch from test to official without wiping?

    There is only one thing which might be necessary.  There is a system file in /data that may need to be deleted.  And I am not sure even that is required.  But I will let you know.

     

    • Like 1
    • Thanks 4
  3. A bit more explanation on my web server:

     

    I was looking at setting up a Lineage OTA server yesterday because this whole download a zip, sideload lineage, reboot to switch slots, sideload gapps thing is a pain.  Nolen pointed me to the official lineage updater project on github and I was trying to get it working.  It uses a bunch of fancy modern stuff (eg. redis) which I don't particularly like.  Then I observed that the API for the OTA server is extremely simple and I could write my own easily enough.  So I did just that.  Took about 2 hours.

     

    After doing all that I removed the packages which I had installed for the official lineage updater.  And somehow it also removed my letsencrypt package along with all my TLS certs.  But I did not notice.  When the nightly TLS renewal job triggered, it stopped the web server and failed to update the (now missing) certs.  And the web server failed to restart because the certs were missing.  I have restored from a backup and all is well again.

     

    Long story short, I made a mistake.  But future test builds will have OTA capability.

     

    • Like 5
    • Thanks 3
  4. I've never observed any phone get very warm during navigation usage while plugged in.  And I have done it quite a lot.  For a couple years this was the main way my phone got charged every day, during my commute to work and back.  I have never done this with the Pro1, but I cannot imagine it would be any different.  Certainly it should not get warm enough to thermal throttle.

     

  5. 1 hour ago, EskeRahn said:

    Sometimes going back without wipe works. There was a similar issue when attempting going from 9 to 8 (if I recall correctly) but OFTEN it will work if changes were minor, but do not expect it in general unless they explicitly say so. And the changes 20 to 21 as well as 21 to 22 clearly was not minor. So stepping back without wipe is unlikely to work.

     

    Generally speaking it should be the opposite.  You should never need to wipe data when you upgrade to a newer build of the same OS unless something is messed up.  The only time you should need to wipe is when switching OS (eg. stock to lineage).

     

    I did initially install test22 without wiping and it worked fine except for an issue with adb starting late.  However, I did wipe shortly after (for the first time in months!) so that I could test the WiFi during setup wizard.

     

    EDIT: Sorry, I misread.  Yes, you are correct.  Going backward to an older build is not supported and may require a wipe.  But given the stable state of Lineage 16.0, the types of changes which break moving between builds are very rare.

    • Thanks 1
  6. 2 hours ago, JooJooBee666 said:

    @tdm Should I use the kernel and device trees from Lineage repos now?  Want to test everything out again.

    FYI, last build went to shit on me.  Could not keep a phone call working for more than 2 minutes before losing the network.  Rebooted and it never booted again.  With no logcat on boot, I don't even know what happened.  Reflashed same build, same problem.  Reverted local commits to June 11t, rebuilt, flashed and was back up...

     

    Yes, I build test22 with exactly what is in official Lineage repos right now.

     

    I can't imagine what could be wrong with the recent code.  It works for me, and I haven't heard anyone else complain about this sort of issue.  Perhaps you should do a clean rebuild using the Lineage and muppets stuff?  And in any case, can you get a logcat?

    • Like 1
  7. test22 is up.  Changes:

     

    • Fix connectivity issues and power drain (intervigil).
    • Set display density to match stock (npjohnson).
    • Increase statusbar height in landscape (npjohnson).
    • Tweak camera button behavior (npjohnson).
    • Customize fingerprint setup image (npjohnson).
    • Various cleanup (npjohnson).

     

    Note the increased statusbar height was done mainly because Nolen's device is an early prototype and has touch sensitivity issues near the edges.  This does not affect production devices AFAIK.  However, it does also improve readability of the statusbar near the edge of the screen a bit because things are not ever cut off.  So you guys need to vote on whether this is a good change or not.

     

    • Thanks 7
  8. 1 minute ago, Hook said:

    I am seeing it now.  I only notice it if I watch my status bar closely.  It doesn't change from 5Ghz to 2.4 Ghz, but the wifi fan will flicker off and then on... but it is so fast I don't t=really notice any break in connection.  It seems to give my mobile data a little more grief as it keeps shifting it's signal strength, but since I am retired and stay mostly at home on wifi, that isn't noticeable much either.  So looks like something is going on, but in terms of real world use hasn't been as noticable as it seems to be for the others, perhaps because of my circumstances (and lack of technical knowledge 😄 ) than others seem to be saying.

    Oh, okay then.  I guess nevermind.

     

  9. 15 minutes ago, Hook said:

    Awesome, thanks.  You are definitely running a different modem version than I am.

     

    The QCOM baseline for all those versions are the same.  That's expected.  But for some bizarre reason they set the OEM version string to the build box hostname.

     

    There are additional strings.  In particular if you just do a straight strings on the modem partition, you should see a block near the end that looks like JSON and starts with Image_Build_IDs.  Could you locate and paste that?

     

    EDIT: And please include Metabuild_Info and anything else around that which looks interesting.

  10. 1 hour ago, Hook said:

    For what it's worth, I am just not seeing any problems with wifi connectivity and, although I am speaking anecdotally as I don't do much real battery monitoring, I am not noticing any unusual power drain.  I am using Test21. I am in the US with a Qwerty model on the off chance that might make a difference.

     

    Ah, this is very interesting.  Ethan believes that the new power code is causing the modem subsystem to crash when getting the WLAN stats.  But if yours is not crashing, perhaps your modem version is different than the rest of us in some way.

     

    Could you run this command and send me the resulting modemversion.txt?  You will need root permissions, so first run "adb root".  You also need to replace the ## with your boot slot suffix.  You can get your boot slot by "adb shell getprop ro.boot.slot_suffix".

     

    adb shell "strings /dev/block/by-name/modem## | grep VERSION" > modemversion.txt

     

     

  11. FYI ... for better/quicker battery drain info, look at this file:

     

    /sys/devices/soc/800f000.qcom,spmi/spmi-0/spmi0-02/800f000.qcom,spmi:qcom,pmi8998@2:qpnp,fg/power_supply/bms/charge_now_raw

     

    I'm not sure what the units are, but I'm charging my battery to 100% now to get an idea.  It's roughly one million at 52% charge.

     

    You can check that value, do something to test (like leave the phone to sleep) for about 10 to 30 minutes, then check the value again.  Divide by the seconds elapsed and you have a drain rate.  You could even script it.

     

    Edit: the value maxes out at 2499526 on my device. So that's roughly 793 per mAh. Yours may or may not be different.

     

     

    • Like 2
  12. 26 minutes ago, EskeRahn said:

    I saw no substantial differences going from 19 to 20, but did from 20 to 21.

    Good to know, thank you.  That implies that the qcacld updates are fine and it is Ethan's power stuff that is causing problems.  On the other hand, @npjohnson is seeing the WiFi stabilize when he takes test21 and backs out the qcacld updates.  So the culprit is still not entirely clear.  Unless perhaps both are causing issues...?

     

  13. 2 hours ago, tdm said:

    I'm going to go over Ethan's changes today. My first thought is to remove all the power related changes and just take the cleanup changes until we test more thoroughly. I'll post later after I discuss with him.

    Actually, scratch that.  I've got other stuff I need to do today and Nolen just received his Pro1 an hour ago.  So I'll let him have a go at this for a while.  He's already got several things fixed, including fixing the display density, enabling the camera button by default, and fixing the fingerprint location image in the setup wizard.  He should be able to track down the WiFi and power issues also.

     

    • Thanks 2
  14. 4 minutes ago, npjohnson said:

    This screenshot makes me think you have a persistent VPN (blockada or similar?) can you try without that? Recent QCACLD merge may be the issue - I've heard of issues with persistent VPN's after that.

    Please take a look at the kernel history on my github.  There was no rebase between test20 and test21 so the kernel history is linear and both tags appear in a simple log.  The qcacld merge was complete for test20.

     

    • Thanks 1
  15. Every OEM is supposed to "tune" the panel for proper display colors at the factory.  This takes very specialized and expensive equipment.  It is a one-time procedure for a given panel, and the results are encoded into the stock software to make the display look better.  It is possible (I would say likely, even) that IdeaLTE has not done this.  Or perhaps they did it for a previous iteration of the display panel but switched suppliers and didn't do it again for the new one.  There isn't really a way to know without having FxTec contact IdeaLTE and ask.

     

    This is also likely why the display color change slightly when you replace the panel with one intended for the Elephone.  They are most likely slightly different in some way.  Perhaps made in different factories or made to different specifications or something.

     

    • Like 3
    • Thanks 2
  16. 51 minutes ago, Craig said:

    Trying not to be too persistent, but what about the issues you've marked as enhancements?   I've been anxiously waiting, but hope you don't start working on 17.1 before addressing some of them...

    In particular I'm most interested in:

    Launch Camera when locked: https://github.com/tdm/android_device_fxtec_pro1/issues/55

    Missing Keyboard Settings: https://github.com/tdm/android_device_fxtec_pro1/issues/53

    Ability to Remap right slant arrow: https://github.com/tdm/android_device_fxtec_pro1/issues/36

    and second most interested in

    Disable/ignore keyboard when slider closed: https://github.com/tdm/android_device_fxtec_pro1/issues/31

    and wouldn't mind:

    Ability to turn off keyboard backlight without extra app: https://github.com/tdm/android_device_fxtec_pro1/issues/32

     

    I'll be going over the issue list. I think Nolen is going to do 17.1 actually.

     

  17. Okay so I got all the code cleaned up reasonably well and all my tests checked out.  So Nolen is currently importing everything into Lineage as I write this.  It should be done shortly, and then I will add the pro1 to the list of official Lineage 16.0 builds.  I'm not sure exactly which day the first official build will roll out.

     

    After all of that is done, I should probably create a discussion thread for official Lineage 16.0, and of course I'll be immediately starting work on 17.1.  That should hopefully only take a few days, and then I can do a short testing period before switching official builds over.

     

    @JooJooBee666 adb started working at boot after I wiped, so maybe try that?  I didn't investigate further.

     

    • Thanks 4
×
×
  • Create New...

Important Information

Terms