tdm
-
Content Count
801 -
Joined
-
Last visited
-
Days Won
84
Posts posted by tdm
-
-
Lineage should support ext4 for sdcards. I expect I'll add exFAT support at some point now that Microsoft has opened up the patents.
Unfortunately, I doubt you'll see exFAT on stock anytime soon. The most likely path is for Qualcomm to add exFAT support as a standard driver in their Q kernel. But I haven't looked to see if they did that, and I have no idea if IdeaLTE is even working on Q for the Pro1.
-
4
-
-
On 6/11/2020 at 5:24 PM, VaZso said:
I think that is "just" a delay between fingerprint reads and not a modification of maximum attempts.
So it should not affect security requirements.Yes, this.
-
1
-
-
@EskeRahn is correct, the A/B system is for updates. Android (either stock, or Lineage when it's official) will install OTA updates to the non-active slot, then tell the boot loader to switch active slots, and then prompt you to reboot. So no, by default, you cannot use A/B for a dual-boot system.
Additionally, there is only one data partition. So any dual boot scheme would require some way to separate data A from data B.
And lastly, you would probably want some sort of a boot manager to select the slot at boot time.
So in theory, it would be possible to make the phone dual boot. But it would take quite a lot of work and each OS would need to be customized to make it compatible with the scheme. I'm not sure that would be the best use of time right now. Maybe later, after everything else is working reasonably well.
-
3
-
1
-
-
Catching up on a couple days here...
Yes, I'm working with @Digital_Toxin to resolve the locked boot loader.
@acrux @schmittlauch I've never installed SailfishOS, so I'm not sure how that would affect the phone. But I can tell you that Lineage uses a different format for userdata (FBE instead of FDE) and modifies boot, vendor, and system partitions. I also suspect that AVB may have something to do with this. Are either of you currently stuck in a place where you are not able to use your preferred OS?
@SchattengestaIt the kernel keymap location has been mentioned here many times, eg. here .. use the line from @acrux a few posts up: "47:0026:802b". I will put this change in test14.
@schmittlauch nwwn.com is my domain. I don't bother with a http->https redirect because there is nothing that could be considered private there. But https does work and you can certainly use it.
Lastly, is anyone unable to boot test12 or test13 who has not installed SailfishOS? I want to try to figure out what's going on, but SailfishOS is an unknown variable to me. The big difference (really, the only difference) between test11 and test12 is integrating the latest security patches. That would have changed the security patch date, which in turn may make AVB unhappy...? After I get that sorted out, I can start looking into why SailfishOS and LineageOS are not compatible (with the exception of userdata, which must always be wiped when changing to a different OS anyway).
-
1
-
5
-
-
1 hour ago, Hook said:
Okay, this may have just hit the too annoying stage. It just did it again, third day in a row. But I learned something new this time because it did it while I was using it. The phone isn't turning off. The first thing that happened was the screen froze (wouldn't respond). Then the screen turned off. Clicking the power button did nothing. But plugging in a USB cable got me the musical note that told me it connected to my computer and the green light came on showing it was charging. So it seems that it's the case that the screen is turning off and refusing to come on so the only thing I can do is reboot with the power button (I probably could issue an adb command from my computer as well, but didn't try that.
I do not remember this happening with stock, but I doubt it has anything to do with Lineage. My question is what is going wrong here. A loose ribbon cable-- I'd expect it to be more common. A faulty sensor, maybe the one the clacks out the phony when you make a phone call.
Sadly, I think I need to return to stock to see whether it is happening there or not-- I expect it will, but I need to test. If it happens on stock,
Then I will be faced with a harder question-- will I need to send it for repair. 😞 Contemplating that may cause me to try to live with it. 😄
I have not completely backed out the double-tap-to-wake (dt2w) changes from stock. That could be what you are seeing. I'll try to get that done for the next build.
-
4
-
-
11 hours ago, EskeRahn said:
Well @Hook is not experiencing reboots but shutdowns where it stays 'Off' until he turns it back On manually.That is why my guess was overheat protection. And unless the phone really is overheating (And he did not report that) that led me to guess at a sensor issue. Hence I was looking for where such an event might be logged.
Well, depending on the device configuration, a reboot may put the device into "ramdump" mode. This is a variation of EDL mode and can easily be mistaken for being off.
-
1
-
-
1 hour ago, EskeRahn said:
How odd. A GUESS could be that an 'overheat' condition could turn it off? So if some temperature sensor is faulty, that might cause this behaviour. If that is the case, I'm sure it will log it somewhere before turning the device off. I Guess @tdm might help in telling where to look for the logs on Lineage?
All Qualcomm phones have thermal protection built-in. I have never heard of a faulty thermal sensor, but I guess it is possible. The thermal daemon does copious logging to logcat, so it would be easy to see that.
The most common reboot reasons for a production Qualcomm device are a cell modem fault and a kernel panic. The cell modem is completely closed source and cannot be touched, so if that is faulty, the OEM needs to fix it. Kernel panics are possible to fix, in theory, but first the issue needs to be identified with a kernel log. That can be tricky -- the best way is to do the adb method that I mentioned somewhere a few days ago. Connect the device to a PC and run "adb shell cat /proc/kmsg" and then reproduce the problem. The kernel will hopefully log the panic message before reboot.
-
1
-
1
-
-
2 hours ago, Wheeljack said:
The L key hasn´t changed since the qwertz-test2.img has it?
Still getting the áccént ´instead of '
No, it has not changed since test2. Can you figure out how to fix it? I am not familiar with the accents vs. apostrophe keys.
-
4 hours ago, EskeRahn said:
Would it be possible to make access to this folder available without root, or to fetch it from a different user-available location?
C:\util\ADB>adb shell ls -R /persist/data/keyboard/ ls: /persist/data/keyboard/: Permission deniedI would prefer not to do that, as it could introduce a security risk. Simply run "adb root" and then make your change. Afterward, you can "adb unroot" or reboot the device.
4 hours ago, EskeRahn said:Would deselect of "Custom layout" under keyboards not work just as well as removing any added file, for the test purpose?
I don't think Android lets you deselect the qwerty/qwertz setting. But yes, the setting is directly tied to that file.
Note: In an ideal world, the factory would provide some sort of way to find out the physical keyboard layout. The only difference I can see between a QWERTY stock image and a QWERTZ stock image is in the Android keylayout files in /system. These get over-written with the Lineage system. So there is no way to determine the physical keyboard layout -- I had to make my own solution. But it is a one-time thing -- set it once and it will remain set for the life of the device (unless you destroy /persist).
4 hours ago, EskeRahn said:IDEA:
A bit similar to switching languages with Ctrl-Space it COULD be handy with some master key-combo that turned off the usage of any custom layout, if people have messed it up completely. I would suggest a combo hard to do (so unlikely to conflict with anything sensible), say something like Ctrl+Sh+Fn+Alt+Sym+ESCInteresting idea. But you most likely used adb to set the keymap, and it is trivially easy to delete the custom keymap file using adb. So I don't see much need for this.
-
1
-
-
5 hours ago, EskeRahn said:
Thanks.
It took me a while to guess how to find the qwertY/qwertZ setting. I browsed through the Settings-tree unable to guess where it is.Gave up and tried searching for "qwerty" or "qwertz" that did not find it either.
BUT if I do a search for "keyboard" or "layout" it do pop up on the search-list. 🙂
Would be nice if it had some natural entry in the settings-tree, preferably under
- Settings ► Language & Input ► Physical keyboard
Or perhaps in a special top level setting group for all the customizations settings that are device specific. e.g. "Pro¹" or "Pro¹ specific"
Yes, it would be nice to have the Pro1 specific settings sprinkled throughout the settings menus, eg. keyboard settings under keyboard, display settings under display. But doing that requires modifying the code in the settings app, which is not allowed in official Lineage builds. The way I've added the Pro1 settings is the "official" way to add device-specific settings. That said, I could possibly rename and rearrange the Pro1 settings. Perhaps Settings->System->Pro1 could be a separate screen with the keyboard and touchscreen settings.
5 hours ago, EskeRahn said:Both the qwertY and qwertZ seem to work just fine for German and Danish. (haven't looked for a lot of details, just checked the obvious)
Choosing Danish, it works really well for qwertZ. I'm a little confused on the functionality triggered by FN+Æ (that is the L key on shifted qwertY). I get a special cursor and has "Sticky FN" . By the Print I expected a Backslash. The similar goes for Fn+Z (that is the ] key on shifted qwertY), where the print indicates vertical bar), and a couple of others.
I believe that is key #31, which is KEY_SEMICOLON when pressed alone. The FN mapping for this key is AltGr+KEY_MINUS, because this is how to generate backslash on a German keyboard. But on a Danish keyboard, AltGr+KEY_MINUS does not seem to be labelled at all. Backslash is generated by AltGr+KEY_GRAVE (eg. the "<>" key).
I would suggest leaving the keyboard as German unless you want to play with the keymaps. The reason is that when you select Danish, you are telling Android that you have a Danish keyboard. But clearly the QWERTZ keyboard is printed as German, and I have programmed it by referring to a German keyboard image.
-
4 hours ago, Derecho said:
The boot image would be the recovery one, yes? I didn't think the keyboard driver could would be in there, I'm actually still running the recovery image from build 2 I think yet I do have the updated keyboard behaviour. Maybe I upgraded and forgot?
The Pro1 has a combined boot/recovery partition. This is why my Lineage install page instructs you to download and flash the boot image and then boot into Lineage recovery.
4 hours ago, Derecho said:I have built Android before, LineageOS specifically even, but this was way back on the Photon Q. My Android and Java (and build tools) experience is very minimal, but I am quite familiar with other embedded sytems.
Great, so you should be able to build your own ROM. Once you can do that, let me know and we can talk about stuff to fix. 🙂
-
test13 is up. Changes:
* Updated QWERTZ keymap.
* Addressed some SELinux denials.
If you have a QWERTY device, there is pretty much no reason to upgrade from test12.
If you have a QWERTZ device, please test and provide feedback. Please remember to remove any custom keymap before testing.
-
6
-
-
2 hours ago, Derecho said:
Ooh, am I reading this correctly? Is it now possible to make custom keymappings using the slanted arrow key to get special characters that require AltGr and thus far needed the Sym key to be pressed? This would be a lifechanger for me!Yes, with the qwertz test2 boot image you may specify AltGr as a modifier. It seems this is very close to the final desired mappings, so I will incorporate it into test13.
2 hours ago, Derecho said:I do wonder about one combination though, the L key for example; This has a question mark printed on it and currently the slanted arrow is used to type it. I'd remap the slanted arrow to produce altgr with L in order to get Ł. How would I go about typing a question mark? Ideally I'd do this by pressing Sym+L, but as I understand that still sends a AltGr+L code so that would also result in Ł instead of a question mark.
Because the '?' symbol is generated with shift, you would probably need to choose another key to map for use with the yellow-arrow. Perhaps the "O" key, for example:
44:0018:8035
And, now that you mention it, the SYM key does also generate KEY_RIGHTALT, aka. AltGr. So I am wondering if that is still desirable...?
2 hours ago, Derecho said:And one other issue/bug with the build 11 that is quite noticable is the headphone volume. At first I thought the slider for in-call volume didn't work at all, but after more testing I found out that it does. It's just that the minimum possible volume, is already too loud for most of my earphones.
Thanks for the report. Please file an issue on github. I should be able to fix it.
2 hours ago, Derecho said:My apologies for welcoming you back by burying you with more requests/issues, I do really appreciate all the work you've done for us into making LOS a thing for this phone and it's amazing how it's generally better than the stock rom. If I can help out someway into polishing the LOS rom into something perfect, do tell and I'll give it a try.
Thank you. 🙂 I'm not sure how you can help... that depends on your experience. If you have never built Android, that would be a good start... build your own ROM.
-
1
-
1
-
-
7 hours ago, Wheeljack said:
Okay, I did a logcat with the pro1 connecting to my car (BT name is "Audi A1").
From what I can tell the call starts at 06-04 13:52:06.897
I did cut several hours of stuff from this morning - still very verbose. Hope this helps for now. I'll see if I can set up a proper strategy for doing a full backup and restore, so I can test with stock.
This looks interesting:
06-04 13:52:08.223 731 1420 D voice : voice_start_usecase: enter usecase:voicemmode1-call
06-04 13:52:08.224 731 1420 D audio_hw_primary: select_devices for use case (voicemmode1-call)
06-04 13:52:08.224 731 1420 D audio_hw_extn: audio_extn_should_use_handset_anc: AANC enabled in the property
06-04 13:52:08.224 731 1420 D audio_hw_extn: audio_extn_should_use_handset_anc: AANC enabled in the property
06-04 13:52:08.224 731 1420 D audio_hw_primary: select_devices: out_snd_device(15: voice-handset) in_snd_device(72: handset-mic)I wonder if you can provide a log from a call with your BT headset... perhaps comparing them would make the issue stand out.
-
1
-
-
Alright qwertz folks, here's another test boot image. Please try and let me know how the keyboard works. Most keys should be correct, but I may have made a mistake or two...
http://files.nwwn.com/android/pro1/boot-qwertz-test2.img
Note that I have added a flag for AltGr = 0x1000. So we have:
0x8000 = shift (left shift)
0x4000 = ctrl (left ctrl)
0x2000 = alt (left alt)
0x1000 = altgr (right alt)
Note there is only space for one more flag. If more flags are needed, I will probably expand the codes from 16 bits to 32 bits.
-
7
-
-
Okay I see what's going on with QWERTZ now. All of the incorrect keys (except possibly apostrophe) are accessed via AltGr. So I'll add that as a modifier in my driver and redo the layout for these keys. I should have a new boot image later today.
-
7
-
-
56 minutes ago, Wheeljack said:
'I have some bluetooth issues with the handsfree system of both an Audi A1 and a VW Golf 7. Not entirely sure if this is related to this thread: https://community.fxtec.com/topic/2899-bluetooth-issues/
On both test11 and test12 my pro1 can connect properly to both cars. I can start and receive a call with the car's controls. The audio however remains with the pro1 earpiece and microphone. When I look at the pro1 display, audio is set to bluetooth. Setting it to phone and back doesn't make a difference. I can set it to speakerphone though.
I tried setting BT audio codec to SBC only.
I also have a Sena 10uPad for my bike helmet and a Sennheiser BT headset. Both work fine as handsfree devices with the pro1.
Audio issues in cars can be difficult, both because it is more challenging to get logs (most folks don't carry their laptops with them in the car) and because each car manufacturer seems to have their own unique BT implementation.
First question, how does stock behave?
Second question, are you able to get a logcat of this happening?
EDIT: Also, please file an issue on github. Issues get lost easily on the forum.
-
2
-
-
7 hours ago, acrux said:
I tried hard to find the codes (mostly as trial&error procedure) for still missing Fn+ keys, but failed. It seems that the symbols missing are currently tied to the Sym key acting as Altgr key for keys corresponding to pc105 keyboard german qwertz layout not for Pro1 german qwertz layout?
If somebody guides me to the usable keycode table then I'll continue.
It was very easy in SailfishOS to get the keyboard layout you like, but that is Linux... 😉
The original output.txt was missing some corrections. I provided the corrected one in my original post and also here.
I am not very familiar with international keyboards. It is only through this project that I even learned the basics about how non-US keyboards worked. But I'm learning. 🙂Unfortunately, keyboards are hard. There are multiple layers of translation involved from the physical key press to what you see on the screen. The kernel keymap is the lowest level, which makes it difficult to choose the correct values that generate the symbol you wish to see.
I've downloaded your attached file and each line has three symbols on the left and a comment on the right. I presume these three symbols represent what you see from the keypress for (1) no modifiers, (2) shift, and (3) yellow-arrow. Is that correct? If so, then the first two columns seem fine for all keys and there are eleven keys which need the yellow-arrow symbol adjusted. Was this done with my modified qwertz boot image, or with the standard test11/test12 boot image?
I will try to share my thought process for finding the codes for the keymap, in hopes that it will help:
1. Select a key and symbol that you wish to map. Let's choose Q since it is the first key in your text file that needs adjusted. This should be key 46 (you can use drivers/input/keyboard/qx1000.c in my kernel source to look this up, see qwertz_keyz[] around line 304..329). The yellow symbol is @.
2. Note the normal unshifted key value in Linux kernel file "include/uapi/linux/input-event-codes.h". In this case, KEY_Q has value 16. In hex, this is 0x0010.
3. Look up the desired yellow symbol on a standard German or other US-INTL keyboard and see how it is generated. This is the part that is difficult for me, as I do not have a QWERTZ Pro1 and I have never used a US-INTL keyboard -- I have only images to work with for both. It seems @ is generated by shift+2.
4. Look up the key code for the base key in Linux kernel file "include/uapi/linux/input-event-codes.h". in this case, KEY_2 has value 3.
5. Note any modifiers needed. In this case, a normal shift. My keymap file uses 0x8000 for this.
6. Combining the above, we get 0x8000 + 3, or 0x8003 for our desired yellow-shift value.
7. Our keymap line should be "46:0010:8003".
Does that make sense? Can you test and see if it works?
Note that some symbols may be generated with AltGr. I am not sure what physical keycode AltGr generates. I am guessing KEY_RIGHTALT? We will need to investigate that.
PS: Both Sailfish and Android are Linux, technically. I think it would be more accurate to say that Sailfish was easy because it is X11 based and that is easier to work with because it's a known system with much more documentation.
-
2
-
-
9 minutes ago, acrux said:
boot-qwertz-test1.img just gives some more correctly assigned keys for german qwertz keyboard variant for test11&test12. I guess the changes will be incorporated into the lineageos boot image inside the lineage zip - eg in test13...
Yes, this.
I was addressing the comment from people that they had installed the ROM but not installed the boot image provided with it. I was just making it clear that the ROM has a boot image. So you cannot eg. install test12 but still have the boot image for test11.
-
2
-
-
Thanks for the reports.
Please note that the separate boot image is provided only for booting into Lineage recovery when switching from stock to Lineage. The main Lineage zip file has its own (identical) copy of the boot image that is flashed along with the rest of the system.
-
32 minutes ago, acoppens said:
@tdm I ran the commands you asked me to, (on test11, bc test12 would'nt boot but that's for the other thread).
If I understood the output from dumpsys media.camera correctly it's basically only reporting on the front facing camera - finding only 1 camera device.
Then had a look at the dmesg output. not quite sure what's going on here but simply doing a search for 'camera' gives a bunch of related fails and errors....and a naming collision for the flash (could this be why the flashlight doesn't work in LOS, but does work in stock?).
Fun detail - flash doesn't work again in LOS.
I humbly await wisdom and enlightenmentdmesg.txt 256.09 kB · 0 downloads dumpsys_media.camera.txt 29.56 kB · 0 downloads
I believe this is your issue:
[ 21.543915] msm_sensor_fill_eeprom_subdevid_by_name:222 Eeprom userspace probe for sunny_bl24sa64cs_imx363
[ 21.545076] msm_camera_request_gpio_table:774 gpio 29:CAM_VANA request fails...
[ 21.700128] imx363 power up failed
The imx363 device (that is, the camera) is failing to power up -- it's dead, Jim.
-
3
-
-
6 minutes ago, acoppens said:
I'm also getting stuck not booting with test12. Recovery helpfully explains Android system can't be loaded and offers a factory reset (doesn't help). Will go back to test 11 to get dmesg for my camera issue. Afterwards I can get diagnostics on the boot issue if given proper instructions....
Hmm, interesting. It installed and booted fine for me. Is anyone else having trouble with test12?
-
15 minutes ago, acrux said:
Yes, all keys I noted in issue worked properly except Fn+l.
I'll attach here a file output.txt with the keys output and comments.
Thanks for your work!
Thanks. Unfortunately, your output.txt does not really help me, as I don't have a qwertz model. If you can just send the changes to the keymap as you did in the github issue report, that would speed up this process greatly.
-
3 hours ago, acoppens said:
@Slion that would seem to be a common thread.
I just don't understand why the issue would persist after completely reverting to stock using the fastboot method posted by @Waxberry.
To my mind that should undo pretty much all changes that LOS might make given that most if not all partitions were overwritten include what looks to be device config, system and vendor partitions.Yes, Lineage only writes to a couple of partitions. Mainly boot, vendor, and system. You can return to stock by writing these three partitions from the stock firmware and doing a factory reset.
3 hours ago, acoppens said:I tried the factory restore tool by @tdm, but unfortunately got unspecified errors.
EDL can be very picky about both hardware and timing. I'd stick with the fastboot method to restore.
3 hours ago, acoppens said:No, this is not the fault of Lineage. The camera stack is completely closed source blobs from stock except for the kernel driver, and I have not touched the kernel driver at all.
3 hours ago, acoppens said:I'm willing to get some logcats or something if someone can tell me what to do - this might also be useful for the support ticket I've opened. I've been wondering myself whether the camera is just completely dead/unresponsive or perhaps gives some sort of invalid response. But I don't know of any way to check the status of the camera at the hardware level from android.
You can start by getting a dmesg from a fresh boot ("adb reboot", "adb root", "adb shell dmesg") and then "adb shell dumpsys media.camera".
-
1
-
SD cards not being recognised
in Pro1 - Thoughts & questions
Posted
It seems f2fs is also supported. And NTFS, if you hate yourself. 😆
https://github.com/LineageOS/android_system_vold/tree/lineage-16.0/fs