Jump to content
tdm

LineageOS, Current status : 16.0 Test Builds

Recommended Posts

1 minute ago, mcdinner said:

If it is not too much trouble or you have a link it would be nice to know, don't really need it.
I tried to get boot log working a week ago but failed. When lineage boot animation started, adb told me I'm not authenticated. 
I edited build.prop on the device (via shell 😄) and added 

persist.service.adb.enable=1                                                    
persist.service.debuggable=1
persist.sys.usb.config=mtp,adb

Also added the public key from computer to adb_keys.
Did not work, guess it was completely wrong.

If you want adb logging from boot, you need to edit /system/etc/prop.default and change the value of persist.sys.usb.config from "none" to "adb" (or "mtp,adb" works also).  No other changes should be necessary.

  • Thanks 1

Share this post


Link to post
Share on other sites
30 minutes ago, SteffenWi said:

ah tank you, yes that worked (adb root, then adb shell).

Things wrong with the default when you set qwertz:

  • Cursor keys not working. Arrow down moves the cursor to the right, arrow up moves the cursor to the left. Arrow right moves the cursor up, arrow left moves it down.
  • ö outputs "M-CM-6", Ö outputs M-V^v
  • ä outputs "M-CM-6", Ä outputs M-V^v
  • < outputs ^, shift + < outputs "AM-BM-0" instead of >
  • ß outputs M-C^=
  • Caps lock doesn't do anything aside from turning on the light
  • Yellow keys aren't working either, the modifier key for that is just not respected either
  • shift+3 outputs "M-BM-'"
  • the ` key doesn't do anything.
  • keyboard key lighting doesn't come on.

Thank you for the feedback!

 

The cursor key arrow issue and the key lighting issue are both known.  I will fix them with the next build.

 

I have no idea about caps lock.  If the light turns on, it is definitely sending KEY_CAPSLOCK to the system.

 

Which yellow keys are not working, exactly?  I am aware that the yellow fxtec key does not work, but are there others?

 

What do you mean by the ` (backtick) key?  There is a key to the left of backspace which is labeled with a ' (apostrophe) and ` (backtick).  It should generate KEY_EQUAL normally and shifted KEY_EQUAL when the fn key is held.

 

For the rest of the keys, are you able to modify the keymap to correct them?  It would be much quicker and easier for you to send me your keymap file than doing a whole change/build/post/download/flash/test/feedback cycle.  This is one of the reasons that I made the keymap editable.

 

Edited by tdm

Share this post


Link to post
Share on other sites

@tdm please see the post again, I updated it a few minutes after I initially posted it. Seems like nano is more buggy than I thought 😉

I posted a second list with differences between the rest of the system and the nano thingi. Some things stay the same (backlight, the yellow keys not working for example).

Quote

Which yellow keys are not working, exactly?

all/any of them. I can't get an @ sign for example. I tried both the fx-key and the yellow arrow that points to the upper right corner of the key. Neither of them + Q did anything. Or combined with any other key for that matter.

Edited by SteffenWi

Share this post


Link to post
Share on other sites
24 minutes ago, SteffenWi said:

@tdm please see the post again, I updated it a few minutes after I initially posted it. Seems like nano is more buggy than I thought 😉

I posted a second list with differences between the rest of the system and the nano thingi. Some things stay the same (backlight, the yellow keys not working for example).

all/any of them. I can't get an @ sign for example. I tried both the fx-key and the yellow arrow that points to the upper right corner of the key. Neither of them + Q did anything. Or combined with any other key for that matter.

Okay still, I will let you work out changes to the keymap.  But let's investigate the fn key (yellow arrow) issue.  Can you send me a kernel log with the following actions?

 

* Press Q.

* Release Q.

* Press and hold fn.

* Press Q.

* Release Q.

* Release fn.

 

I don't need the entire log, only the part where you are pressing the buttons as above.

 

If I can't figure out what is happening from the log, I may need to add some logging to the GPIO key section (NB: the shift, ctrl, alt, fn, and fxtec keys are driven by separate GPIOs, not by the aw9523 chip).

 

Share this post


Link to post
Share on other sites
8 minutes ago, nardholio said:

@tdm: Why not just use AsantiKeypad for the key mappings like here? https://github.com/ubports-on-fxtec-pro1/android_device_fxtec_pro1

*just got my device and am syncing up the code now 😄

Because FxTec gave us a nice fully functional keyboard (with a couple compromises for size, to be sure) and I think it should act like a full size keyboard.

 

  • Like 1

Share this post


Link to post
Share on other sites
4 hours ago, tdm said:

Yes, Lineage recovery requires your host PC's adb key to be packaged into the boot image because it cannot decrypt /data.  If you really want a shell in recovery, I can explain how to do this, or build a new boot image with adb authentication disabled.

 

Please explain, how to disable adb authentication in recovery.

I tried it several times with:

PRODUCT_PROPERTY_OVERRIDES += \
ro.adb.secure=0 

put into device/fxtec/pro1/device.mk
but with no avail.

I can also search for some guide myself, I just need some keywords.

Edited by Loader009

Share this post


Link to post
Share on other sites
50 minutes ago, Loader009 said:

Please explain, how to disable adb authentication in recovery.

I tried it several times with:

PRODUCT_PROPERTY_OVERRIDES += \
ro.adb.secure=0 

put into device/fxtec/pro1/device.mk
but with no avail.

I can also search for some guide myself, I just need some keywords.

The way I find the easiest is to unpack the boot image, edit it, and repack it.  In the ramdisk, you can replace adb_keys with your own host key and/or set ro.adb.secure=0 in prop.default.

 

EDIT:

If you are building, you might want to follow this pattern for ensuring ro.adb.secure is 0:

 

https://github.com/LineageOS/android_build/blob/lineage-16.0/core/Makefile#L1476

 

This is probably much easier than hunting down everywhere that might set or override ro.adb.secure in the build tree.

 

I can also shoot you some patch(es) for adding adb_keys into the build and such.

 

 

Edited by tdm

Share this post


Link to post
Share on other sites

When you say tested in nano, what you do mean?   Is there nano for android terminal now?  Otherwise, you mean termux, and termux uses its own keymap anyway so not good place to test keyboard layouts.  Use android terminal.

Share this post


Link to post
Share on other sites

@Craig I activated the terminal for Lineage/Android in the settings, then opened it and entered 'nano test' and typed around in there.

Edited by SteffenWi
  • Thanks 1

Share this post


Link to post
Share on other sites
13 hours ago, tdm said:

The way I find the easiest is to unpack the boot image, edit it, and repack it.  In the ramdisk, you can replace adb_keys with your own host key and/or set ro.adb.secure=0 in prop.default.

That might be the easiest, but I still have to find out, with which tool I can unpack/repack it.

13 hours ago, tdm said:

If you are building, you might want to follow this pattern for ensuring ro.adb.secure is 0:

https://github.com/LineageOS/android_build/blob/lineage-16.0/core/Makefile#L1476

This is probably much easier than hunting down everywhere that might set or override in the build tree.

This would take quite some time. I used mgrep to find any ro.adb.secure entry, only found:

./build/make/core/main.mk:284:    ADDITIONAL_DEFAULT_PROPERTIES += ro.adb.secure=1
./vendor/lineage/config/common.mk:31:PRODUCT_SYSTEM_DEFAULT_PROPERTIES += ro.adb.secure=0
./vendor/lineage/config/common.mk:34:PRODUCT_SYSTEM_DEFAULT_PROPERTIES += ro.adb.secure=1

The first one is only applied if I do a -user build.
The third one though is only applied if it is not an -eng build. This might be the problem?
(I omitted my own entry in ./device/fxtec/pro1/device.mk)

13 hours ago, tdm said:

I can also shoot you some patch(es) for adding adb_keys into the build and such.

I can follow this guide to add adb_keys, but my intention is to disable adb authentication in -userdebug builds (trying an -eng build now) until recovery can decrypt and read userdata.
https://github.com/LineageOS/android_bootable_recovery#adb-devices-shows-the-device-but-in-unauthorized-state

Edited by Loader009

Share this post


Link to post
Share on other sites

@Loader009: Looking at your discussion with @tdm about enabling shell in recovery I gather that you've also not yet been able to get Nanodroid working. I've been wondering whether things would be easier with the TWRP-build in the SailfishOS thread, but haven't quite gotten around to trying that - probably next weekend.

If you did manage to pull it off I'd be very happy to hear how you did it :).

Share this post


Link to post
Share on other sites

@acoppens, well...
Good news: I did a custom build with the patches which are needed (signature spoofing).
Bad news: I have to use @tdms recovery, in order to flash NanoDroid because I have to remount,rw the /system_root/ folder.
Then NanoDroid can be flashed.

@tdm I could unpack/repack the bootimage and I think I was able to modify the ramdisk/recovery.
Though, it didn't boot, so I must've done something wrong. (Probably with some packing argument.)

Share this post


Link to post
Share on other sites
13 minutes ago, Loader009 said:

@tdm I could unpack/repack the bootimage and I think I was able to modify the ramdisk/recovery.
Though, it didn't boot, so I must've done something wrong. (Probably with some packing argument.)

I've used this tool with success to modify both stock and lineage boot images: https://github.com/vianney/bootimgtool

bootimgtool -x -v qcom

To extract, and then to repack it, if i recall correctly:

bootimgtool -c -v qcom -p parameters.cfg -k Image.gz-dtb -r ramdisk.img

To replace the kernel I stole the DTB from the kernel in a boot image with https://github.com/PabloCastellano/extract-dtb and just used cat to append only the first one of the extracted DTBs to the new kernel (only that one appears to matter at all).

  • Thanks 1

Share this post


Link to post
Share on other sites

@netman thx, I'll try it tomorrow after work.

I used mkbootimg and unpackbootimg from osm0sis but for the ramdisk I used gzip and cpio. And I have no idea, which algorithm I have to use for packing.

  • Like 1

Share this post


Link to post
Share on other sites
1 minute ago, Loader009 said:

I used mkbootimg and unpackbootimg from osm0sis but for the ramdisk I used gzip and cpio. And I have no idea, which algorithm I have to use for packing.

I think I had tried those and failed, most likely just because of user error rather than them not being capable though xD

Share this post


Link to post
Share on other sites

Using mkbootimg can be confusing and frustrating.  I use a script to repack boot images after modification: repackbootimg

 

It expects the files created by unpackbootimg to be in the current directory.  It also can repack the ramdisk if it is extracted under a directory named initrd.  Something like the following will do this:

mkdir initrd

cd initrd

cat ../boot.img-ramdisk.gz | cpio -id

cd ..

 

  • Like 2
  • Thanks 3

Share this post


Link to post
Share on other sites

Perfect, @tdm, it worked.
I had to modify your script though, it requires a dt file in line 11 and the filenames differ from what I get out of unpackbootimg (compiled from osm0sis' git).

Share this post


Link to post
Share on other sites
9 minutes ago, tdm said:

I'll look at audio soon, thanks for the log.

Thank you! :)
I have microg, Magisk and Xposed installed but at the time the logs were created, i flashed the Lineage SU addon instead of Magisk so Xposed and Magisk Modules should not have been active and interfering. (At least I hope so...) 
If you need any more infos i can give them to you.

Edited by mcdinner

Share this post


Link to post
Share on other sites
On 2/9/2020 at 11:00 PM, tdm said:

Using mkbootimg can be confusing and frustrating.  I use a script to repack boot images after modification: repackbootimg

I created another (bash-)script, modding the specific line in the recovery.
I hope you like it: modbootimg

Custom builds are available over my profile page -> My Profile - "About Me" tab

Edited by Loader009
  • Like 1

Share this post


Link to post
Share on other sites

@tdm

I know you've got some ideas of what keycodes to assign the various modifier type keys, and recently I saw something about you doing some odd things with the slant-arrow keys that might restrict user customization, etc.   I've chatted with mccreary a few times about my thoughts, and thus learned a lot of stuff, and wanted to share what I believe would be the ideal way to map keycodes in kernel that takes advantage of built-in AOSP features, and allows user to fully customize layout afterwards.

Esc --> Esc

Slant Arrows --> Meta (left & right - separate key codes are essential!)

Alt - Left Alt

SYM --> Right Alt

F (Fxtec logo key) --> Fn &/or MISSING KEYS.

Shifts - Left Shift

Controls -->   Left Control

[Changes from stock are in bold above]

This assumes switching to 'alpha' keyboard definition, which gives us sticky shift/alt and longpress letters for accents choices.

And I'll explain why I think this ideal, and looking for feedback if anyone has thoughts or disagrees.  I'd love this to come on stock too, for best out of the box experience for new users and reviewers, even tho I plan to use lineage myself.

Esc --> Esc Its not working as Esc; it should.

Alt This should remain Left-Alt, and default keymaps should not use this key as modifier, leave them for use with dosbox/vnc/etc that use alt.

SYM should be Right-Alt because thats what it was on Photon Q, and that brings up a symbol keyboard in gboard, similar to the emoji keyboard that comes with Left-Alt. It can then be used as the 3rd level modifier key in kcm keyboard layouts, exactly like linux pc.  Alt keys are sticky, so not awkward combinations are required.

F (Fxtec logo key) should be Function (Fn), which can be used as an additional modifier in kcm layouts.  Ideally, it could generate the keys that are currently missing from keyboard without requiring a kcm somehow: SLASH and QUESTION MARK from P&L, F1-F12 keycodes from the number row, PgUp/PgDn/Home/End from the directional arrows, Android Back from Backspace, and Ins from Del.  If possible, by itself it should be Android Home like now, as some people like a dedicated home key - however Android home could still be accessed with Meta+h (if defined that way in the shortcuts).  Oh yeah, its YELLOW too, just like the slash and question mark printed on keyboard, for those that noticed that.

Slant Arrows should be Left Meta and Right Meta..  Firstly this gets us separate key-codes for each key so that user can remap later, something stock did wrong.  Additionally, this gets us access to global keyboard shortcuts (already in AOSP) that Fxtec forgot to implement.  These global shortcuts require both keys to be held simultaneously (they do not work with sticky), so its useful to have it on both sides.

Shift/Control should both be left.  That's typical behavior when only one shift and control key, and we basically only have one shift and one control key even tho they're accessible from both sides.   Its weird to me that stock has one assigned right and one assigned left.  This is not important, and if there's a reason to keep as is, not a problem at all.

This would give us all keys on normal us-keyboard except SysRq, Break, Right-Shift, and Right-Control..    I personally will be remapping the right slant arrow to be slash/questionmark, but wouldn't expect that in LOS, but would love it if it was.  However if both slant arrows end up the same keycode, that's not possible for user to do themselves.  Or if those keys get hidden completely from the user and not generate keycode that would be big limitation to customization by user.

 

edit: learned Meta cant be used in kcm as modifier key so removed that.  learned Fn definitely can, so updated that.  Added details, fixed mistakes.

Edited by Craig
  • Like 4
  • Thanks 1

Share this post


Link to post
Share on other sites
30 minutes ago, Craig said:

@tdm

I know you've got some ideas of what keycodes to assign the various modifier type keys, and recently I saw something about you doing some odd things with the slant-arrow keys that might restrict user customization, etc.   I've chatted with mccreary a few times about my thoughts, and thus learned a lot of stuff, and wanted to share what I believe would be the ideal way to map keys.

Esc --> Esc

Slant Arrows --> Meta left & right

Alt - Left Alt

SYM --> Right Alt

Fxtec logo key - Android Home, F-Keys, home/end/pgup/pgdn in combo.

 

And I'll explain why I think this ideal.  This also assumed switching to 'alpha' keyboard definition, which gives us sticky modifiers and longpress letters for accents choices.

Esc is self evident. 

Alt This should remain left-alt, and default keymaps should not use this key, leave them for use with dosbox/vnc/etc that use alt.

SYM should be Right-Alt because thats what it was on Photon Q, and that brings up a symbol keyboard in gboard, similar to the emoji keyboard that comes with left Alt. It can also be used as the 3rd level modifier key in keyboard layouts, which is needed for slash and question mark on qwerty (and even more on qwertz).

Fx in combination with number row should generate F1-F12 keycodes.  Fx+arrows should PgUp/PgDn/Home/End.  By itself it should be home like now, as some people like a dedicated home key.

Slant Arrows should be meta left and right.  Firstly this gets us separate key-codes for each key so that user can remap later.  But additionally, this gets us access to global keyboard shortcuts (already in AOSP).  These global shortcuts require both keys to be held simultaneously (they do not work with sticky), so its useful to have it on both sides.   Key combinations  not used as shortcuts could be used in keymap if really wanted.

 

 

 

I am going to make the default keymap as close to what one would expect by just looking at the keyboard as possible.  That means:

* The right-slant-arrows (fn-keys) are (dead) modifiers that allow generating the yellow symbols.

* The FxTec key could be anything, really.  Home would be fine, or any other reasonable suggestion.

* Chording the FxTec key (FxTec+number) is sort of asking for two things at once -- you want it to be both a normal key and a modifier key.  That's probably not easily doable.  But I would like a way to generate F# keycodes.  I was thinking maybe fn+ctrl+# or something.

* Sym is an interesting one.  If right-alt brings up a symbol keyboard, that's a definite possibility.

 

Also as long as I'm here, I want to let everyone know that I've fixed a couple issues in the new keyboard driver.  The test driver in the boot image I posted had so-called "ghost key" issues where eg. pressing D and then G (on qwerty) would not register the G.  It also failed to recognize the first column of keys (H, B, 7, ...) at boot.  And the FxTec key didn't do anything.  All of these are fixed now.

 

I'm still not terribly happy with the keyboard driver code, but it does work well enough that I can move on to other things now.  I'll circle back around to it at some point and finish cleaning it up after other higher priority things are done (like audio!)

 

I'll try to push out a new Lineage build tomorrow.

 

  • Like 1

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...

Important Information

Terms