LineageOS, Current status : 16.0 Test Builds

[bmccrary 39]

43 minutes ago, Hook said:

I wish I could figure out why Verizon is  not working here.  Did you have to change any settings?  I'm thinking of doing a fresh install wiping user data and see if that somehow does the trick.  Will be a pain, even with backups, if all that work ends up not being successful.  The SIM works fine in the mule phone but not at all with test 22 on the Pro1.

I did not change any settings at all.  In fact, I avoided the *#*#4636*#*# menu altogether.  It seems touching anything in there is an immediate death sentence, even if you put it back.  I understand the pain, it's took me several days working on it when I can and I'm still not all set back up yet. I don't think you'll have any luck without flashing back to stock first but I could be wrong.    I took all the updates but the only one that really seems to matter is the 20191111 one.  After that you should be able to make everything work on the stock ROM, then flashing Lineage hopefully will work.

[Hook 3,043]

2 minutes ago, bmccrary said:

I did not change any settings at all.  In fact, I avoided the *#*#4636*#*# menu altogether.  It seems touching anything in there is an immediate death sentence, even if you put it back.  I understand the pain, it's took me several days working on it when I can and I'm still not all set back up yet. I don't think you'll have any luck without flashing back to stock first but I could be wrong.    I took all the updates but the only one that really seems to matter is the 20191111 one.  After that you should be able to make everything work on the stock ROM, then flashing Lineage hopefully will work.

I think I'll give bit a try. I don't need Verizon,    it has just kind of turned into an obsession.  😁

[marmistrz 93]

On 7/16/2020 at 7:44 PM, Craig said:

I'm not sure if either of those are broken.   The first issue is you have to understand what TDM did with slant arrow (fn).  It is not mapped as a key that gets thru to android or the keymap.    But the keymaps works fine, most use Right_Alt as the modifier key, and that is assigned to the key marked as SYM.

What he did with slant arrow he did at the driver level.  And if you modify that map, you're changing what keys get sent to the layout.   I could give examples to try to make it clear, but it takes a little bit to understand what he did with that.    Needless to say, when right slant-arrow can be remapped, you can make it another Right_alt and that will work better with the included international keymaps cuz you'll have Right_Alt on both sides.  And for those of us who primarily use English, we can make it the Slash-QuestionMark key that Pro¹ forgot to include, and only use the left slant arrow for home/end/pgup/pgdn/f1-f12/ins etc.   If you've never checked out my Reddit post, I summarized most of the keyboard stuff, check it out...

  https://www.reddit.com/r/fxtec/comments/fjoj79/lineage_16_on_pro¹_keyboard_shortcuts_features/                       

 

As to alt opening Emoji with Left_Alt, that's a feature of both AOSP and Gboard, so I don't think its wrong....      But not having the physical keyboard settings for present in settings does make it so we cant control stuff.  This is from another thread where I compared our hardware keyboard behavior with various keyboards.... cuz the autocaps I can't disable drives me crazy was looking for solution.  Swiftkey fixes most everything, but loose both the emoji and symbol menus, and when you try to play games its impossible, have to switch back keyboards.

 

https://community.fxtec.com/topic/2959-comparing-keyboard-features-aospgboardswiftkey

 

 

Eh, you can't do inline replies on this forum.

You're right, one can use left alt as a modifier key. I made mistake while modifying the generation script 🙂 and it's why the generated keymap didn't work for me. Expect a Polish layout using alt for diacritics in finqwerty soon^TM 🙂

Your reddit post doesn't really explain the internals, just the implemented features. How exactly is fn handled inside the driver and why isn't it done in the userspace?

If I'd like to prevent alt from opening emoji, is it AOSP keyboard that should be modified? Does it have anything to do with the LOS changes?

[Hook 3,043]

On 7/18/2020 at 4:32 PM, marmistrz said:

I'd expect a decent camera for such a high price (especially that the device aspires to be a premium device)

I've been thinking about what you said here and I think it's a misperception of the Pro1 (although I won't pretend I'm entitled to speak for Chen). I don't think the Pro1 was ever marketed as a "premium" phone and it isn't.  First, notice that their marketing motto is "Function is Key."  The Pro 1 is much more a descendant of the Nexus phones than a Pixel, iPhone or Samsung phone.  It is a very solid midrange phone (with good specs) strapped onto a premium keyboard. My theory is that they really had to do that or we would be looking at a $1200 phone.  They poured everything into the keyboard (you can have lots of arguments about the decisions they made in keyboard layout, but they really designed and executed a fine piece of hardware).  For better or worse, they focused on what you can accomplish with a keyboard.  Things like camera and audio were less important.  They don't even discuss the camera in their sales pitch.

I'm not arguing that you are unreasonable for expecting a better camera.  I just think a lot is explained by taking this perspective into account.

This is, of course, a bit OT for a Lineage thread except to say that Lineage fixes a lot of IdeaLTEs shortcomings, but, no doesn't address the camera. Since I rarely us a smartphone camera except to make note of something, the PocoPhone F1 port, referred to above, and open camera do just fine. Having been a Nexus user for years, I'm used to not quite great cameras.  😄

Edited July 19, 2020 by Hook

[Craig 1,435]

2 hours ago, marmistrz said:

Your reddit post doesn't really explain the internals, just the implemented features. How exactly is fn handled inside the driver and why isn't it done in the userspace?

You'd have to go way back in this thread to find where tdm explained it.

But there is a keymap file we can edit that affects slantarrow combinations.   Just understand that slantarrow combinations are handled in the driver, not in userspace, so the combination generated is what's sent to the keyboard app/layout.

As to why?  He probably explained his reasons.  For me, now that I understand it, the reason I like it is it works ALWAYS.   Some apps ignore the layout or keyboard settings, but they dont ignore the keys coming from the driver.  With QWERTY the way F(x)tec designed the keyboard, there is no slash key (and thus no questionmark).  The only way to get that key on stock is thru a custom layout (like finqwerty) or using external tool like keymapper (or their hack of a solution of using no layout, but then shift doesnt work etc, and of course limits using other layouts).  Now in lineage, its handled in the driver, so there is no app I wont be able to get my slash in.  Plus that makes it work well for things like pgup/pgdn/home/end/etc.        On QWERTZ its even more important, cuz they have even more printed keys that use the slantarrow.        So the idea of his implementation is that you can get every key printed on the keybaord out of the driver.  And then after that layout handles the rest.   Plus, he's now added that extra stuff for us like PgUp/PgDn/Home/End/Ins/F1-F12 that we didnt have already, also at the driver level. 

FinQwerty is not designed for Lineage, its designed for stock.  Stock doesnt even have right-alt key, we do.   The international layouts included with both stock and lineage depend on having right-alt key.    Finqwerty gets around that by using slant arrow and left alt as modifiers as it does have access to those.  But under lineage it doesnt have access to slant arrow.   Have you tried using the included polish layout, instead of finqwerty, with lineage?   Also with that, hopefully soon you will be able to assign right slant arrow to another Right_alt (in addition to sym) so you'll have it on both sides of the keyboard.

 

 

Edited July 19, 2020 by Craig

[marmistrz 93]

6 minutes ago, Craig said:

As to why?  He probably explained his reasons.  For me, now that I understand it, the reason I like it is it works ALWAYS.   Some apps ignore the layout or keyboard settings, but they dont ignore the keys coming from the driver.  With QWERTY the way F(x)tec designed the keyboard, there is no slash key (and thus no questionmark).  The only way to get that key on stock is thru a custom layout (like finqwerty) or using external tool like keymapper (or their hack of a solution of using no layout, but then shift doesnt work etc, and of course limits using other layouts).  Now in lineage, its handled in the driver, so there is no app I wont be able to get my slash in.  Plus that makes it work well for things like pgup/pgdn/home/end/etc.        On QWERTZ its even more important, cuz they have even more printed keys that use the slantarrow.        So the idea of his implementation is that you can get every key printed on the keybaord out of the driver.  And then after that layout handles the rest.   Plus, he's now added that extra stuff for us like PgUp/PgDn/Home/End/Ins/F1-F12 that we didnt have already, also at the driver level. 

FinQwerty is not designed for Lineage, its designed for stock.  Stock doesnt even have right-alt key, we do.   The international layouts included with both stock and lineage depend on having right-alt key.    Finqwerty gets around that by using slant arrow and left alt cuz  as modifiers as it has access to those.  But under lineage it doesnt have access to slant arrow.   Have you tried using the included polish layout, instead of finqwerty, with lineage?   Also with that, hopefully soon you will be able to assign right slant arrow to another Right_alt (in addition to sym) so you'll have it on both sides of the keyboard.

We really should have a wiki describing all the LineageOS modifications compared to stock. The built-in layout indeed works, unlike on stock.

Currently one advantage of using (left) alt instead is that it's sticky, unlike sym (right alt).

[EskeRahn 5,471]

11 minutes ago, marmistrz said:

We really should have a wiki describing all the LineageOS modifications compared to stock. The built-in layout indeed works, unlike on stock.

Currently one advantage of using (left) alt instead is that it's sticky, unlike sym (right alt).

I think they already made something like that: https://wiki.lineageos.org/devices/pro1

[Craig 1,435]

15 minutes ago, marmistrz said:

The built-in layout indeed works, unlike on stock.

Most things that are broken on stock have been fixed (or were never broken in the first place) on lineage.... 

Edited July 19, 2020 by Craig

[marmistrz 93]

Ok, I see what's the reason for the unexpected behavior of alt/fn+alt. fn is handled using these arrays: https://github.com/LineageOS/android_kernel_fxtec_msm8998/blob/2120e09d09b3a94c4de9395523a587d9909224d4/drivers/input/keyboard/qx1000.c#L257-L335

It appears that KP_LEFTALT is handled in this part of the file: https://github.com/LineageOS/android_kernel_fxtec_msm8998/blob/2120e09d09b3a94c4de9395523a587d9909224d4/drivers/input/keyboard/qx1000.c#L649-L654 and no check is made for the state of the fn key.

What kind of key event is emitted on stock for fn+alt? (I can't find the kernel sources for stock)

@tdmis there any reason why alt is handled the same way as fn+alt, is it a bug or a feature?

[tdm 2,322]

49 minutes ago, marmistrz said:

Ok, I see what's the reason for the unexpected behavior of alt/fn+alt. fn is handled using these arrays: https://github.com/LineageOS/android_kernel_fxtec_msm8998/blob/2120e09d09b3a94c4de9395523a587d9909224d4/drivers/input/keyboard/qx1000.c#L257-L335

It appears that KP_LEFTALT is handled in this part of the file: https://github.com/LineageOS/android_kernel_fxtec_msm8998/blob/2120e09d09b3a94c4de9395523a587d9909224d4/drivers/input/keyboard/qx1000.c#L649-L654 and no check is made for the state of the fn key.

What kind of key event is emitted on stock for fn+alt? (I can't find the kernel sources for stock)

@tdmis there any reason why alt is handled the same way as fn+alt, is it a bug or a feature?

 

The OEM/stock kernel sources are here:

https://github.com/tdm/android_kernel_fxtec_msm8998/tree/oem-history

This also exists as history in the Lineage tree, but it is not a separate branch.  You would need to go find that commit manually.

 

As for fn+alt, I don't think I ever considered that combination.

 

[FlyingAntero 871]

It seems that first official Nightly build is available 🙂

- https://www.lineageoslog.com/16.0/pro1

Edit: here also, https://download.lineageos.org/pro1

Edited July 20, 2020 by FlyingAntero
Added link

[EskeRahn 5,471]

1 hour ago, FlyingAntero said:

It seems that first official Nightly build is available 🙂

- https://www.lineageoslog.com/16.0/pro1

Thanks. I get this after flashing trying to run the usual "adb reboot recovery" though:

error: device unauthorized.
This adb server's $ADB_VENDOR_KEYS is not set
Try 'adb kill-server' if that seems wrong.

The suggested kill server does not help. (I can manually reboot to recovery from the menu though)

It then complains about the signature of the gapps-package, but I am allowed to overwrite that.

(Same for adb reboot)

But overall it installed gracefully and preserved my user data. 🙂

[tdm 2,322]

29 minutes ago, EskeRahn said:

Thanks. I get this after flashing trying to run the usual "adb reboot recovery" though:

error: device unauthorized.
This adb server's $ADB_VENDOR_KEYS is not set
Try 'adb kill-server' if that seems wrong.

The suggested kill server does not help. (I can manually reboot to recovery from the menu though)

It then complains about the signature of the gapps-package, but I am allowed to overwrite that.

(Same for adb reboot)

But overall it installed gracefully and preserved my user data. 🙂

This is expected. The official lineage recovery has stricter security. I have a patch in my build that disables adb auth in recovery.

[Wheeljack 212]

Probably stating the obvious here, but the boot.img from the test-builds is not compatible with the official lineage installer. So doing the "fastboot flash boot <recovery_filename>.img" before going to recovery and sideloading lineage is mandatory when switching from test to official 😅

Other than that, everything went fine just as reported by @EskeRahn

[EskeRahn 5,471]

3 hours ago, tdm said:

This is expected. The official lineage recovery has stricter security. I have a patch in my build that disables adb auth in recovery.

Thanks.

Is there an 'officially signed' version of the gapps package we should use, or should we just ignore the warning?

[Maplesteel 97]

If we install a nightly build, are we eligible for OTA updates?

[tdm 2,322]

3 hours ago, EskeRahn said:

Thanks.

Is there an 'officially signed' version of the gapps package we should use, or should we just ignore the warning?

Just ignore the warning.

[tdm 2,322]

1 hour ago, Maplesteel said:

If we install a nightly build, are we eligible for OTA updates?

Yes. Just be prepared for the OTA install to take nearly an hour.

[SteffenWi 139]

I'm sorry but could someone take another look at https://wiki.lineageos.org/devices/pro1/install

The instructions for flashing the recovery image are...weird. Something about temporary flashing? And the command doesn't match what we previously used either.

Before: fastboot flash boot_a lineage.img

According to the install page: fastboot flash lineage.img

And then those confusing notes about wether an A/B device is used? I thought the Pro1 *is* an A/B device?

[Maplesteel 97]

39 minutes ago, tdm said:

Yes. Just be prepared for the OTA install to take nearly an hour.

For clarity, I meant the newly appeared Lineage OS nightly builds located here.

Are those the same builds as your ongoing test builds, @tdm ? Do they connect to your, or LineageOS OTAs?

 

[acrux 56]

52 minutes ago, SteffenWi said:

Something about temporary flashing? And the command doesn't match what we previously used either.

Before: fastboot flash boot_a lineage.img

According to the install page: fastboot flash lineage.img

Temporary because the following updates already include boot.img.

You made an inaccuracy here, according to the install page:

fastboot flash boot <recovery_filename>.img

It does not matter to which slot boot partition it is flashed if it is install and not a update.

 

Edited July 20, 2020 by acrux

[tdm 2,322]

17 minutes ago, Maplesteel said:

For clarity, I meant the newly appeared Lineage OS nightly builds located here.

Are those the same builds as your ongoing test builds, @tdm ? Do they connect to your, or LineageOS OTAs?

 

The LineageOS nighly builds on lineageos.org are the "official" Lineage builds.  I have imported the code for test22 to the Lineage github, so they will be functionally equivalent to that (at least to start, we will continue development there).  There are only a couple differences for official Lineage builds:

• They are signed with a "real" key, not a "test" key.  This is more secure and will make the Trust warning go away.
• I have a couple changes to my code locally.  Nothing you should really notice except for a small anti-spam hosts file.
• Signature checking and adb auth is disabled in my recovery.

And yes, if you install the official Lineage build, you will get official Lineage OTAs.  These should be done weekly, I believe, regardless of whether anything actually changes.  Conversely, if you install my build, you will get my OTAs.  I will only publish an OTA when something changes.

 

Edited July 20, 2020 by tdm

[SteffenWi 139]

9 minutes ago, acrux said:

Temporary because the following updates already include boot.img.

oh, okay.

10 minutes ago, acrux said:

You made an inaccuracy here, according to the install page:

fastboot flash boot <recovery_filename>.img

It does not matter to which slot boot partition it is flashed if it is install and not a update.

 

But you need to know which slot it is to switch back to it to get to recovery and sideload the zip file? Or is the switch back no longer neccessary?

[tdm 2,322]

Guys, I appreciate the critique of the wiki.  But please do note that virtually everything except the device specifications are templates that are linked -- I did not write it.  Here is the actual code for the Pro1 device page:

 

https://github.com/LineageOS/lineage_wiki/blob/master/_data/devices/pro1.yml

Notice it says "install_method: fastboot_nexus".  That means the recovery install instructions come from here:

 

https://github.com/LineageOS/lineage_wiki/blob/master/_includes/templates/recovery_install_fastboot_nexus.md

 

Also note it says "is_ab_device: true", so the wiki will follow that path when generating the page.

 

If you would like to contribute to the Lineage wiki, I'm sure they would appreciate the help.

 

[SteffenWi 139]

@tdm That is the thing: I lack the knowledge to know if things just changed because it is now a lineage image or if the wiki is wrong. There are just a lot of differences between what was on your site and what it says on the lineage site.

Edited July 20, 2020 by SteffenWi