LineageOS, Current status : 16.0 Test Builds

[bmccrary 39]

@tdmhttp://www.mytelescan.com/vendor_2020-01-06.img.gz

It was vendor_b, I should have checked the mounts on the OS beforehand.

[spam71 55]

@tdm

Hello

Since you're The Pro1 Developer, do you think it might be possible to add kernel support for "battery idle mode" - I mean the state with charger plugged in, when battery is charged to some level, for example 80%, but is neither charged up further nor starts discharging - phone takes energy from charger, but not from battery. There are apps that can utilize this mode to preserve battery life (i.e. ACC: https://github.com/VR-25/acc/ ACCA: https://github.com/MatteCarra/AccA).

As for now, with these apps, Pro1 stops charging at given threshold, but instead of keeping this level, bypassing battery and using current from charger, it starts discharging until it reaches lower threshold, when it starts charging again, and the loop continues.

It's something similar to what Lenovo does in ThinkPads for decades now, and lowers battery wear significantly.

KT

Edited February 17, 2020 by spam71
corrected messed up links

[EskeRahn 5,471]

The Pro1 got TWO hall probes, one for the slider and one for a lid! See this. So it is prepared for a flip-case.

Can you guys doing the LineageOS patches for the Keyboard slider copy that detection code, and use it to handle screen off from the other probe also? That would be pretty awesome!

Actually I was very surprised that the Hall sensor was there, but it does not seem to do anything.

[tdm 2,322]

5 hours ago, spam71 said:

@tdm

Hello

Since you're The Pro1 Developer, do you think it might be possible to add kernel support for "battery idle mode" - I mean the state with charger plugged in, when battery is charged to some level, for example 80%, but is neither charged up further nor starts discharging - phone takes energy from charger, but not from battery. There are apps that can utilize this mode to preserve battery life (i.e. ACC: https://github.com/VR-25/acc/ ACCA: https://github.com/MatteCarra/AccA).

As for now, with these apps, Pro1 stops charging at given threshold, but instead of keeping this level, bypassing battery and using current from charger, it starts discharging until it reaches lower threshold, when it starts charging again, and the loop continues.

It's something similar to what Lenovo does in ThinkPads for decades now, and lowers battery wear significantly.

KT

I'm not familiar with this, so I would have to check into it.  The device is pretty generic Qualcomm so if there are any generic patches needed, feel free to point me to them.

 

[tdm 2,322]

1 hour ago, EskeRahn said:

The Pro1 got TWO hall probes, one for the slider and one for a lid! See this. So it is prepared for a flip-case.

Can you guys doing the LineageOS patches for the Keyboard slider copy that detection code, and use it to handle screen off from the other probe also? That would be pretty awesome!

Actually I was very surprised that the Hall sensor was there, but it does not seem to do anything.

Yes, there are two hall sensors.  I'm not sure if they are both present and working in hardware though.

 

Supporting both hall sensor may be tricky.  I'll have to dig into it if/when someone makes a flip case.  But I think there is really only support for one "lid" sensor in the Android framework.  And that is used by the keyboard slider.  This is oem_hallb in the DT file, and it generates SW_LID.  The other hall sensor generates key F3 which seems strange.

 

[tdm 2,322]

test5 build is up.  I've added a changelog section to my lineage page so you can see what is new.  Most all the changes from test4 are keyboard related.  Please note that in addition to the listed changes:
 

The vendor blobs are unchanged from test4.  I got the updated vendor image from @bmccrary but haven't had time to pull in the updated files yet.

 

a2dp is still not working.  I looked at it briefly but still can't figure it out.  I don't think it's super high priority right now, so I'm not blocking test releases on it.

 

qwertz keyboard users must still set their keyboard layout manually at each boot.  I'll add support for reading a file in /persist at boot in the next release (tomorrow or the day after).  And of course I'll also be adding a UI for setting qwerty/qwertz at some point soon.

 

For those who build from source: the "common" device tree has been folded into the main pro1 device tree, so there is no more device/idealte/msm8998-common. The common tree was an artifact of starting from the 1+5/5t trees.  I kept it around in case another idealte msm8998 device was discovered.  But none have been found so far and it's highly unlikely they will be supported in the future.

 

[mcdinner 375]

19 minutes ago, tdm said:

a2dp is still not working.  I looked at it briefly but still can't figure it out.  I don't think it's super high priority right now, so I'm not blocking test releases on it.

Thx for the new update!
I agree with you on a2dp, but the "no audio on voice call when display goes off" should be very high priority.
At the moment the ability to use the phone as a phone is 'deminished' since test3.
 

[EskeRahn 5,471]

1 hour ago, tdm said:

Yes, there are two hall sensors.  I'm not sure if they are both present and working in hardware though.

Supporting both hall sensor may be tricky.  I'll have to dig into it if/when someone makes a flip case.  But I think there is really only support for one "lid" sensor in the Android framework.  And that is used by the keyboard slider.  This is oem_hallb in the DT file, and it generates SW_LID.  The other hall sensor generates key F3 which seems strange.

Yes just tested in KeyEvent, we do indeed get an F3 when I put a magnet close and an F4 when removing if. Just as the keyboard send an F5 when closing, and an F6 opening.

So then the big question is if that can be used somehow, but maybe that is really not a lineage thing, but merely a stand alone android app, that should react on these, and could be used on either lineage, or stock.

(Though I would recommend to on Lineage to map all four to some more odd keys, as some might want to use F1-F12 for something.

Some odd candidates:

ADD:

Though F4 replaced with KEYCODE_WAKEUP (E0h) and F3 with KEYCODE_SLEEP (DFh) might work out of the box

[EskeRahn 5,471]

25 minutes ago, EskeRahn said:

Though F4 replaced with KEYCODE_WAKEUP (E0h) and F3 with KEYCODE_SLEEP (DFh) might work out of the box

Tried on stock with

adb shell input keyevent 223
adb shell input keyevent 224

And they work perfect.....

[tdm 2,322]

I believe the core issue is that Android does not have a separate concept of lid/cover and slider. It only has logic for a "lid". We are using this for the slider but it's not really suitable for our usage.

 

Eventually, when some of the more major issues are sorted out, I would like to resolve this by separating the logic for these things in the core Android logic. I'm not sure AOSP would take the patches but I'm pretty sure Lineage will.

 

[silversolver 849]

24 minutes ago, tdm said:

I believe the core issue is that Android does not have a separate concept of lid/cover and slider. It only has logic for a "lid". We are using this for the slider but it's not really suitable for our usage.

 

Eventually, when some of the more major issues are sorted out, I would like to resolve this by separating the logic for these things in the core Android logic. I'm not sure AOSP would take the patches but I'm pretty sure Lineage will.

 

OH MAN are we going to owe you some BEER!

You are the greatest!

[_DW_ 628]

6 hours ago, silversolver said:

OH MAN are we going to owe you some BEER!

You are the greatest!

I already sent him a few 😄

[EskeRahn 5,471]

8 hours ago, tdm said:

I believe the core issue is that Android does not have a separate concept of lid/cover and slider. It only has logic for a "lid". We are using this for the slider but it's not really suitable for our usage.

Eventually, when some of the more major issues are sorted out, I would like to resolve this by separating the logic for these things in the core Android logic. I'm not sure AOSP would take the patches but I'm pretty sure Lineage will.

But it looks like simply replacing sending KEYCODE_F4 (86h) with KEYCODE_WAKEUP (E0h) and KEYCODE_F3 (85h) with KEYCODE_SLEEP (DFh) in current logic will do the trick with no other changes. 😎

[mcdinner 375]

@tdm Backlight comes on now when I open the keyboard, but does not turn off when closed until display goes off.

[_DW_ 628]

14 minutes ago, mcdinner said:

@tdm Backlight comes on now when I open the keyboard, but does not turn off when closed until display goes off.

nearly there but I could live with that 🙂

[mcdinner 375]

6 minutes ago, _DW_ said:

nearly there but I could live with that 🙂

don't want to 😉

[tdm 2,322]

@EskeRahn yes, just sending KEY_WAKEUP and KEY_SLEEP could work for a simple cover.  But if there is a window in the cover, the system needs to know when the cover is opened and closed to show the appropriate information through the window (this is done via the FlipFlap package in Lineage).  So I guess we'll see what kinds of covers show up, if any.

 

@mcdinner I'll have to look into the backlight code.  It's currently in the lights HAL (this is where @Sean McCreary put it).  I don't think the lights HAL will get notified on lid events, so it may need to spawn a thread and listen to the appropriate event node to track the slider state.  But the current code is probably okay for now, right @Craig? 😄

 

And finally, I've uploaded test6.  This has updated blobs from 20200106 and it also has the code to set the keyboard layout (and keymap and poll_interval) on boot.  There is no UI for the keyboard settings yet, so you need to create the files manually.  They are in directory /persist/data/keyboard, named the same as the sysfs nodes.  Here's an example of how to set qwertz (these are shell commands, run as root):

 

mkdir -p /persist/data/keyboard

echo "qwertz" > /persist/data/keyboard/layout

 

Now the keyboard should be set to qwertz at boot.

 

[tdm 2,322]

I've started going through the issues on the github issue tracker.  There are relatively few things left to fix to get a good stable build, shown below in rough order of severity (IMHO anyway):

* General stability.  @Craig reported that test4 was unstable.  Please try test6 and report back.

* Phone call audio issues.

* a2dp does not work.

* Virtual keyboard showing and hiding at appropriate times.

* FM Radio does not work.

* WiFi signal strength does not work.

* selinux is permissive.

 

Other less severe issues that probably shouldn't be considered blockers:

* Ask the user for keyboard layout at setup time if it is not already set in /persist.

* Allow the user to set the keyboard layout in Settings app.

* Turn off keyboard backlight when slider closes.

 

[bmccrary 39]

I had to go back to stock because somehow "VoLTE" got turned off again.  I could not get/make calls or send/receive SMS/MMS when this happened.  I was nowhere near a computer either so it was a major hassle for the day.  FWIW, it never worked under the older stock builds either, so I'm not sure if any of the vendor blob updates would change anything. 

I get the impression this issue will be ongoing for a long time as there is no one to keep up with it, and that's OK, but it does mean anyone in the US using the largest carrier in the country can't use Lineage.  I would think Sprint would have the same problem.  I imagine some work might happen to the core Lineage when CDMA/3G is turned off completely next year, as then no phone of any kind running Lineage on a former CDMA carrier will work anymore, as a phone anyway.

[tdm 2,322]

Hey so quick question ... Sean and I are chatting about the virtual keyboard behavior.  It seems that telling Android the keyboard is not internal causes the device to wake on any key but also is responsible for the virtual keyboard popping up when it shouldn't.  So I think I'm going to revert that change and figure out how to wake the device with the internal keyboard.  There are certain keys that do this -- among them, BACK and WAKEUP.  I can send WAKEUP for any or all keys, so which do you guys prefer?  Only a certain key (like ESC) waking the device or any key?

 

[mcdinner 375]

2 minutes ago, tdm said:

Hey so quick question ... Sean and I are chatting about the virtual keyboard behavior.  It seems that telling Android the keyboard is not internal causes the device to wake on any key but also is responsible for the virtual keyboard popping up when it shouldn't.  So I think I'm going to revert that change and figure out how to wake the device with the internal keyboard.  There are certain keys that do this -- among them, BACK and WAKEUP.  I can send WAKEUP for any or all keys, so which do you guys prefer?  Only a certain key (like ESC) waking the device or any key?

 

If there is no downside of using all keys, why not :)

[tdm 2,322]

3 minutes ago, bmccrary said:

I had to go back to stock because somehow "VoLTE" got turned off again.  I could not get/make calls or send/receive SMS/MMS when this happened.  I was nowhere near a computer either so it was a major hassle for the day.  FWIW, it never worked under the older stock builds either, so I'm not sure if any of the vendor blob updates would change anything. 

I get the impression this issue will be ongoing for a long time as there is no one to keep up with it, and that's OK, but it does mean anyone in the US using the largest carrier in the country can't use Lineage.  I would think Sprint would have the same problem.  I imagine some work might happen to the core Lineage when CDMA/3G is turned off completely next year, as then no phone of any kind running Lineage on a former CDMA carrier will work anymore, as a phone anyway.

 

I'm using GSM (an AT&T MVNO) so I don't use VoLTE.  Is there any way to test VoLTE in the US without signing up for VZW service?

 

[jannoke 0]

ESC only seems to be stock behaviour. I would prefer that i could wake it up with right hand also, so arrow keys maybe. 

[Hook 3,043]

13 minutes ago, tdm said:

 

I'm using GSM (an AT&T MVNO) so I don't use VoLTE.  Is there any way to test VoLTE in the US without signing up for VZW service?

 

AT&T uses VoLTE,  Probably the MVNO is capable too. However, I have no idea how you know when you are or aren't using it. 

[EskeRahn 5,471]

20 minutes ago, tdm said:

Hey so quick question ... Sean and I are chatting about the virtual keyboard behavior.  It seems that telling Android the keyboard is not internal causes the device to wake on any key but also is responsible for the virtual keyboard popping up when it shouldn't.  So I think I'm going to revert that change and figure out how to wake the device with the internal keyboard.  There are certain keys that do this -- among them, BACK and WAKEUP.  I can send WAKEUP for any or all keys, so which do you guys prefer?  Only a certain key (like ESC) waking the device or any key?

Is the keyboard turned off while closed on Lineage? If not squeezing the device might send a key, and we do not want that to wake in say a pocket.

So if it is NOT turned off closed it should be a single key hard to press by squeezing. If it IS off closed, other things should be considered.
The modifiers would be good, as there is no 'risk' in tapping those, the same way there is in taping a key that could have a function. If say an incoming call arrives just as you press Enter, so 'any' keys might not be optimal.

So safe keys in all scenarios will be the Shift-keys, as neither of the keys are likely to be accessed squeezing, and neither can have unwanted side effects.