LineageOS, Current status : 16.0 Test Builds

[JooJooBee666 84]

2 hours ago, tdm said:

You should see the options in the system section when you select "advanced".

Working well here.  Thanks again.👌

[JooJooBee666 84]

@tdm fyi, the a2dp commit also fixed the crackling audio problem.  Makes sense as one of the things I noted when the issues was occurring was an error stating "AUDIO_FORMAT_PCM_16_BIT" was an invalid format.

Bad-ass.😎

Edited February 29, 2020 by JooJooBee666

[EskeRahn 5,471]

7 minutes ago, tdm said:

I believe there is supposed to be code to add those settings into the search results.  But I just copy-pasted it from an example and I do not understand it at all.  I can investigate.

I see, not a big deal in any way, only an initial issue looking for it. 🙂

8 minutes ago, tdm said:

That is for the keyboard polling. 

Thanks for the explanation. If it is power consuming, perhaps it would be beneficial to slow it down to say 100ms when the keyboard backlight times out, so it only consumes when needed.

10 minutes ago, tdm said:

You need not restart, the change should be immediate.  If it is not, there is a bug.

It did not work when I initially changed it from zero. But after the restart I can change it and even set it to zero and up again. Could it be an initialization issue?

[tdm 2,322]

10 minutes ago, EskeRahn said:

I see, not a big deal in any way, only an initial issue looking for it. 🙂

Thanks for the explanation. If it is power consuming, perhaps it would be beneficial to slow it down to say 100ms when the keyboard backlight times out, so it only consumes when needed.

It did not work when I initially changed it from zero. But after the restart I can change it and even set it to zero and up again. Could it be an initialization issue?

The keyboard driver only polls when at least one key is pressed. When no keys are pressed, it uses interrupts. So there should be little concern for the CPU usage. I could even get rid of the option and always use 20ms. I just preferred the longer delay because I could not detect any keyboard lag at all with 40ms.

 

Also note that there is still one more optimization that I would like to make for the keyboard, which is a hybrid interrupt/poll mode. In this mode, the driver would only poll on the rows that have keys pressed (it is currently all-or-nothing). This would reduce the work done in the polling code by a factor of 8, approximately, and alleviate any concerns about CPU usage even when polling fast.

 

I have no explanation for the margin failing to set on first try.

 

[EskeRahn 5,471]

BTW it would be great if the two edge margins were handled independent.

The Keyboard-edge can take a lot more margin than the opposite without affecting functionality.

And it is the side that is most prone to accidental touches both opening by pushing, and for entering numbers.

[tdm 2,322]

2 minutes ago, EskeRahn said:

BTW it would be great if the two edge margins were handled independent.

The Keyboard-edge can take a lot more margin than the opposite without affecting functionality.

And it is the side that are most prone to accidental touches both opening by pushing, and for entering numbers.

Okay I'll put that on my todo-list.

 

[EskeRahn 5,471]

11 minutes ago, tdm said:

I have no explanation for the margin failing to set on first try.

Oddly only ONE of the two units had this ??? The "Final Sample". The old "Pre-Production" did NOT. And anyway it was only initially, so at most a very low priority thing.

You got a Pre Production too for the testing, right? So it just MIGHT be that they changed something - or that it was merely a strange coincidence.

Let us not dwell on it, we will see if any other see the same. 😊

[tdm 2,322]

8 minutes ago, EskeRahn said:

Oddly only ONE of the two units had this ??? The "Final Sample". The old "Pre-Production" did NOT. And anyway it was only initially, so at most a very low priority thing.

You got a Pre Production too for the testing, right? So it just MIGHT be that they changed something - or that it was merely a strange coincidence.

Let us not dwell on it, we will see if any other see the same. 😊

I have a very early prototype that has reduced edge sensitivity... a built-in margin. 🙂 It also has zeros for IMEIs which makes it unsuitable for testing radio things. So I was provided a near-production prototype that has valid IMEIs and also better edge sensitivity. I use the earlier one for stock and the later one for lineage.

 

[EskeRahn 5,471]

8 minutes ago, tdm said:

I have a very early prototype that has reduced edge sensitivity... a built-in margin. 🙂 It also has zeros for IMEIs which makes it unsuitable for testing radio things. So I was provided a near-production prototype that has valid IMEIs and also better edge sensitivity. I use the earlier one for stock and the later one for lineage.

Seems like we got quite similar units 🙂

[tdm 2,322]

1 hour ago, EskeRahn said:

BTW it would be great if the two edge margins were handled independent.

The Keyboard-edge can take a lot more margin than the opposite without affecting functionality.

And it is the side that is most prone to accidental touches both opening by pushing, and for entering numbers.

Actually I think increasing the left margin when the slider is out might be a better solution. I'm just wondering if it should be a multiple of the user margin setting (1.5x? 2.0x?) or a fixed number.

 

Edited February 29, 2020 by tdm

[EskeRahn 5,471]

23 minutes ago, tdm said:

Actually I think increasing the left margin when the slider is out might be a better solution. I'm just wondering if it should be a multiple of the user margin setting (1.5x? 2.0x?) or a fixed number.

I think it is much a user-dependant thing. When opened I'm yet to experience accidental touches clicking the numbers.

But it requires more care opening.

Personally I ONLY have problems with the edges when it is closed. Not when opened.

Others have huge problems clicking the numbers. I would say the thumb-width is what matters.

So I would prefer a setting. But when you got one slider, would it be much work to copy and paste to four? Giving the user complete control of the two edges, opened and closed.

You MIGHT even add a tick-box (default set) "Same margin", that links the four sliders (a bit like Paint's Keep aspect ratio)

 

ADD: OH! Please draw some lines or something when the slider is pulled, so we can see where the limits we select are. Just let them be cleared when the slider is released.

[tdm 2,322]

11 minutes ago, EskeRahn said:

I think it is much a user-dependant thing. When opened I'm yet to experience accidental touches clicking the numbers.

But it requires more care opening.

Personally I ONLY have problems with the edges when it is closed. Not when opened.

Others have huge problems clicking the numbers. I would say the thumb-width is what matters.

So I would prefer a setting. But when you got one slider, would it be much work to copy and paste to four? Giving the user complete control of the two edges, opened and closed.

 

It's not so much a matter of the work involved.  It would be very quick and easy to provide four sliders.  But I think that makes the UI way too complicated.

 

My criteria for options is not just implementing something that somebody wants or even needs.  It is more like:

(1) is this needed and/or reasonable? if no, reject.

(2) is this something that everyone needs or is benign if always set?  if so, just do it without an option.

(3) make an option in the simplest, clearest way possible.

 

11 minutes ago, EskeRahn said:

ADD: OH! Please draw some lines or something when the slider is pulled, so we can see where the limits we select are. Just let them be cleared when the slider is released.

 

I'll look into adding a visual indicator in the settings widgets.  It's not necessarily easy to do because of the way Android measures UI elements.

 

[EskeRahn 5,471]

9 minutes ago, tdm said:

It's not so much a matter of the work involved.  It would be very quick and easy to provide four sliders.  But I think that makes the UI way too complicated.

The thing I hate about al the providers offering equals slabs, is the idea that different people all fits in the same box. That is what I love about the Pro1 offering something not like that.

In this edge-case it is matter of finger size, usage pattern and perhaps even motor skills. We are so far from all equal so why should one set of settings fit all?

[Polaris 423]

7 hours ago, FlyingAntero said:

My previous QWERTY device Droid 4 (aka Maserati) still has 237 downloads.

- 596. maserati 237

I still use it as a daily driver!  If Verizon wasn't dropping their CDMA service I would keep using it for God knows how long.

 

6 hours ago, tdm said:

The 1+5/5t has a Lineage specific change (actually written by a former Cyanogen co-worker) in the LED blinking code.  I have not applied this yet, which is why the blinking does not work.  I'll have to look at the vibration system but it's probably equally trivial.

This is interesting, and I hope that mine will work once the code is applied because mine didn't work with the stock ROM where most of the other users said it did.  Will be interesting.  Also, as for the vibrations, I didn't have them with test8 either, but, like before, once I loaded a 3rd party messaging app it came to life.  However, this time, when I removed the app the vibrations continued to work!  There were no settings changes in between other than to allow notification access to the 3rd party app.  Very odd, but at the moment, the vibration system is working for incoming calls and messages.

 

4 hours ago, EskeRahn said:

It did not work when I initially changed it from zero. But after the restart I can change it and even set it to zero and up again. Could it be an initialization issue?

Just FYI, mine worked fine w/o a reboot on the first try, as well as, with each successive use.

 

2 hours ago, EskeRahn said:

I think it is much a user-dependant thing. When opened I'm yet to experience accidental touches clicking the numbers.

But it requires more care opening.

Personally I ONLY have problems with the edges when it is closed. Not when opened.

I'm right there with you, I have yet to experience accidental touches with clicking the numbers, and don't have problems when it's opened, only when closed.  I don't even really have a problem with opening it (screen on), more with just handling it.

 

1 hour ago, EskeRahn said:

The thing I hate about al the providers offering equals slabs, is the idea that different people all fits in the same box. That is what I love about the Pro1 offering something not like that.

Hear, hear!!  However, this kind of ultra modding should be done by a developer on the payroll! @tdm not such a person, but, IMO, Fxtec should hire him (even if as an outside consultant) because has done, and is doing, so much to make the device usable as a daily driver!  He has already far surpassed IdeaLTE's ability to react to customer's problems, let alone their/our wishes.

 

Edited February 29, 2020 by Polaris

[VaZso 1,998]

1 hour ago, Polaris said:

@tdm is not such a person, but, IMO, Fxtec should hire him (even if as an outside consultant)because has done, and is doing, so much to make the device usable as a daily driver!  He has already far surpassed IdeaLTE's ability to react to customer's problems, let alone their/our wishes.

I am abslutely agree with you.

He alone made a lot of progress for Pro1 to also have a perfect software.
He is also active on this forum so we can see what happening and also can check his work - while we don't even have information about progress of stock firmware (if there is any progress at all currently).

So, @tdm, thank you your work.

[EskeRahn 5,471]

3 hours ago, Polaris said:

Hear, hear!!  However, this kind of ultra modding should be done by a developer on the payroll! @tdm not such a person, but, IMO, Fxtec should hire him (even if as an outside consultant) because has done, and is doing, so much to make the device usable as a daily driver!  He has already far surpassed IdeaLTE's ability to react to customer's problems, let alone their/our wishes.

I certainly agree that @tdm is doing a great job here, others have contributed, but he caries a huge load here, And I too hope some of it finds it way back to stock.

[JooJooBee666 84]

6 hours ago, JooJooBee666 said:

@tdm fyi, the a2dp commit also fixed the crackling audio problem.  Makes sense as one of the things I noted when the issues was occurring was an error stating "AUDIO_FORMAT_PCM_16_BIT" was an invalid format.

Bad-ass.😎

Spoke too soon....somehow it came back later in the day and even back after a reboot.  How was it gone earlier?

[tdm 2,322]

43 minutes ago, JooJooBee666 said:

Spoke too soon....somehow it came back later in the day and even back after a reboot.  How was it gone earlier?

Try playing with the audio buffer sizes, and maybe diff 1+5 settings.

[Craig 1,435]

On 2/28/2020 at 3:31 PM, D1ggs said:

Can SELinux validation be faked with Magisk? 

 

I have a few apps that require certification 😕 

I've passed safetynet by using the magisk module 'safetypatch'.  Dunno if that is helpful for your situation.

Edited March 1, 2020 by Craig

[JooJooBee666 84]

14 hours ago, tdm said:

Try playing with the audio buffer sizes, and maybe diff 1+5 settings.

@tdm here's more filtered log errors when audio is crackling

E ACDB-LOADER: Error: ACDB get asm topology returned = -8
E ACDB-LOADER: Error: ACDB_CMD_GET_AUDPROC_COMMON_TABLE_SIZE Returned = -19
E ACDB-LOADER: Error: ACDB audproc returned = -19
E qcbassboost:     [vendor/qcom/proprietary/mm-audio-noship/audio-effects/safx/android-adapter/qcbassboost/qcbassboost.c:536] Assertion fail: pConfig->inputCfg.format == AUDIO_FORMAT_PCM_16_BIT

Same error I saw before...but they're  back.  I'll try to find some time to play around with the buffers today and let you know if I find anything.

Edited March 1, 2020 by JooJooBee666

[D1ggs 141]

@tdm , I just installed test8 and I am BLOWN away with how much progress you've done with it. 

And everyone else:

Has anyone noticed some oddities with the front facing camera in Google Duo? I get a lime green appearance to my face. This also appears in other apps, but not in the default camera app.

[EskeRahn 5,471]

17 minutes ago, D1ggs said:

I get a lime green appearance to my face. This also appears in other apps

...Stop eating whatever you are eating immediately... 🤣

[D1ggs 141]

3 minutes ago, EskeRahn said:

...Stop eating whatever you are eating immediately... 🤣

I was going to take a screencap of it, but it's all fixed now. 

Typical. ALso weirdly enough, I can't get Magisk Manager to open without crashing. Have to figured that one out now. 

Edited March 2, 2020 by D1ggs

[EskeRahn 5,471]

2 minutes ago, D1ggs said:

I was going to take a screencap of it, but it's all fixed now. 

Typical. ALso weirdly enough, I can't get Magisk Manager to open without crashing. Have to figured that one out now. 

Those mushrooms clearly did not do you any good... 🤢

But on a more serious note, I tried to take an extreme HDR-image with both LOS and stock, and in stock I got the below (well here a cropped and reduced version of it). Note the lime-green halo on the flames.

 

[EskeRahn 5,471]

26 minutes ago, EskeRahn said:

But on a more serious note, I tried to take an extreme HDR-image with both LOS and stock, and in stock I got the below (well here a cropped and reduced version of it). Note the lime-green halo on the flames.

Note this is open camera, and I see similar on both Stock and LOS. I'm pretty sure there is BUG in the camera API, so when OC tries to stitch things together we get weird Halo's. HDR with OC works just fine on other phones, so I'm pretty sure it is a parameter issue on one (or both) the images that are to be stitched. My GUESS is that something is handled as linear that ought to be handled logaritmic or vice versa.... e.g what should be 10% longer exposure is handled as 2^10%=7%

The snapdragon-camera-app does NOT have this on HDR. So it either access the camera directly, and not through the Camera2 API, OR the program has a bug matching that in the driver...