tdm
-
Content Count
801 -
Joined
-
Last visited
-
Days Won
84
Posts posted by tdm
-
-
11 minutes ago, Wikiwide said:
I am wondering how to change the boot-wallpaper. The "Fxtec Pro1 powered by Android" one. I like Fxtec Pro1 logo, yellow looks fairly good on black... But, I don't like the "powered by Android" bit. Even if there is a mini-Android running inside modem (and I am not going to look into that anytime soon), the phone itself is now running Sailfish OS, and I would appreciate a visible reflection of this.
I think the boot-wallpaper shows up when booting into OS itself, so it's probably post-ABL. In fact, I have found bootanimation.zip under /system/media/ - it contains lots of images, from "black" to "black with yellow logo" to "black with yellow logo and white text". Buuut, the white text contains only Pro1, not "powered by Android". So, it doesn't answer the question of where "powered by Android" is hiding! Could somebody please help with this? Best case, there will soon be a new thread, full of open-licence community-contributed boot-images/animations for Fxtec Pro1 😉
Thank you. Best wishes,
~~~~~~~~~~~~~~~~~
Per aspera ad astra...
P.S. Moderators, please, feel free to move this post to a different/new thread, especially if the wallpaper/"powered by Android" is not "hard-coded" inside some part of firmware.
This is in the splash partition. It's a BMP file with a custom header prepended. I don't know the header format off the top of my head though. Feel free to play with it, it's a rather easy customization.
Also please note the "powered by Android" text, including font, size and color, is mandated by Google for play store certification. There is no use requesting that FxTec change it.
-
1
-
1
-
-
2 hours ago, Laska said:
To be honest, I'm very disapointed with this because when I mess something with system partition I can't just flash system.img because /data is encrypted and I cannot restore it any file from it. Also, I cannot mount /vendor rw (to swap speaker channels) so without custom recovery this phone is little crippled up. Which is sad because I really like this device.
You can flash system without affecting data, this is exactly what OTA updates do. But you do need a PC and adb -- you can't store your system image on the data partition.
The OEM should fix the speaker swap issue. Has that been noted by FxTec?
And for others complaining about backups, you need to do it the way that Google intended ("adb backup" and mtp for media) until a decent TWRP appears. Just an inconvenience, really.
-
1
-
-
Basically it's a standard Qualcomm device. Meaning that data is encrypted and this cannot be disabled. The method of encryption varies: stock uses FDE while my lineage ROM uses FBE. There is currently no TWRP that can decrypt data but it's on my todo list.
If you mean a locked boot loader, yes it comes locked by default, and can be unlocked.
However, being a device aimed at hobbyists, FxTec chose to disable Secure Boot. Which basically means that you cannot force your device to only run OEM signed code -- it will always allow you to flash a custom ROM
-
2
-
4
-
-
3 minutes ago, Craig said:
So basically, duplicating the shift key? Seems silly to me. But if you have a reason for it, great, but please make sure they're separate keycodes so user can remap them individually. In stock currently if you change behavior of one, it affects both. If you're not going to make them meta left & meta right, then fx key should be meta.
Sure, it seems silly to me also. But that's the way the keyboard is printed. I would map the fn keys to something else but they are required to generate '/' and '?'.
But the beauty of the new keyboard driver is that you can remap all the keys. The gpio keys aren't remappable yet but I'd like to make them remappable before I finish.
-
4
-
-
30 minutes ago, Craig said:
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.
-
1
-
-
1 hour ago, mcdinner said:
I'm having audio related problem with test3. System gets laggy and the UI restarts from time to time.
Audio output from Spotify and other Apps is working.@tdm I appended some logs, any Idea what could be the problem?
I'll look at audio soon, thanks for the log.
-
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 ..
-
2
-
3
-
-
Unfortunately stock kernel does not have pstore configured. So no can do. 😞
-
1
-
-
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.
-
1 hour ago, Gigadoc2 said:
Ok, so the restore-tool sends the idealte-signed (or is it qualcomm-signed?) firehose programmer to the phone, and then communicates with said programmer over USB to send it the stuff it has to flash (or receive whatever it reads), am I getting this right?
So in theory, if one were to take the signed firehose from your tool it could be used with the Linaro tool or something similar?
And I take it that you don't have the firehose source (and if you had you couldn't sign the resulting binary), but what with the code from cyngn? I suppose you are not at liberty to release the source of it? 😇
Yes, the device boot ROM communicates with a very simple protocol to download firehose, which is an ELF binary. After verification, it simply runs the binary not unlike running a command from a terminal.
I'm not sure if the OEM builds the firehose, but they do sign it. An OEM typically has a separate signing key for each device model.
Yes the firehose can be used with any tool. And of course access to the firehose can be dangerous. This is one reason the qfp file is not a simple zip file.
No I don't have firehose source. But I could look into releasing some of my code on github.
-
1
-
1
-
-
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.
-
1
-
-
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).
-
4 minutes ago, Gigadoc2 said:
Yass!
Oh, that sounds very interesting!
How much is your tool dependent on the NDA stuff F(x)tec gave you? Do you think it is possible to develop something like it as open source, and add reading capabilities to it? I mean, that sounds like a prime way to fully, completely, back up your device 😄
But apart from that, if you can read flash with EDL, doesn't that kind of defeat locked bootloaders? As in, now I can dump the data from the phone before I tamper with it to get the decryption key? Or is that completely mitigated by a part of the encryption key being stored in a secure element which is not dumped via EDL?
The device encryption/signing keys are not kept in flash, they are in a separate non-volatile storage which cannot be read outside of TEE (the walled-off "trusted" environment). So no, it does not defeat locked bootloaders nor does it expose your userdata (because userdata is encrypted with a complicated algorithm that uses both the device encryption key and your passcode). But it does mean that if you aren't encrypting your userdata, it can be trivially exfiltrated. Which is one of the main reasons I won't make a build that uses unencrypted userdata.
I have not signed any NDA with FxTec. They provided the factory package to developers, which contains the programmer (aka. "firehose"). That is all.
The code for the tools was written when I worked at cyngn. It was intended to be used for their factory restore tool. But that never happened because the company died. So I was left with a bunch of nice code and nothing to do with it. This is a perfect opportunity to use it. 🙂
Note that the documents describing the protocols are proprietary to Qualcomm and not publicly released. But since Linaro has released their QDL flashing tool, they cannot realistically be considered secret anymore.
-
3
-
2
-
-
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.
-
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 addedpersist.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.
-
1
-
-
6 minutes ago, mcdinner said:
I had to clarify, i was unable to get shell in recovery
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.
-
6 minutes ago, SteffenWi said:
I get an adb shell. But I'm having trouble obtaining root permission. I activated root via adb in the developer options but when I'm in the adb shell I don't have root permission?
@tdm are you building the lineageOS images without export WITH_SU=true?
The developer option is permission to run adb in root mode. It does not actually restart adb. You must do that separately with "adb root".
-
1
-
-
30 minutes ago, SteffenWi said:
I flashed the keyboard image but now the phone isn't starting anymore. Hangs at the fx logo. Do I need to factory reset again and sideload the zip file again?
That is strange. No you should not need to reset or reflash to make it work.
And you are running lineage test 3? With no modifications like magisk?
-
1 hour ago, Gigadoc2 said:
It looks like QDL mode is EDL mode -- at least when I put my device into EDL mode it is listed as "QDL mode" in `lsusb`.
As it seems the only tool we have for EDL flashing is the one from this thread, you can't really cherry-pick partitions to flash. However, the tool offers the "Base only" option. I have not tried that, but according to tdm's page here, "base only" will keep most of the "high-level" partitions intact, so it might leave SailfishOS mostly untouched.
What you can't do in any case is checking which partitions are "corrupt", as far as I know neither EDL nor fastboot allow you to read data, it will only write it.
Actually EDL can both read and write. And that means you can read the GPTs, parse them, and do all sorts of cool things. But most people only want to get their device running again and in the most foolproof way possible. So all EDL tools I've ever seen only have logic to write everything from the factory package. On the other hand, you rarely see factory packages due to security reasons. My tool is unique in that it allows you to only flash the base data. And that it runs on many different OS's, etc.
-
1
-
3
-
-
Hmm, so it looks like you are using Linux and you are rather anxious to get your device working. I can't blame you. 🙂 Please try this test version of the programmer. It is a CLI version, and it has the fix to flash xbl properly:
http://files.nwwn.com/android/pro1/qfpkg_cli.gz
And a smaller "base" version of the 20191028 package which does not flash system, vendor, userdata, etc.:
http://files.nwwn.com/android/pro1/QX1000_user_20191028_base.qfp
Please report back and let us know how it goes. 🙂
-
5
-
-
@Wikiwide do not worry about the age of your laptop or the charge in your phone battery. EDL programming is not very demanding on speed or current, and the device does not use the battery at all in EDL mode -- it does not operate on battery power nor charge the battery. In fact, if you disassemble the device, you will find that you do not even need to have the battery connected to use EDL mode.
-
3
-
-
3 hours ago, Wikiwide said:
...
@Wikiwide Please read my factory restore page here: http://files.nwwn.com/android/pro1/factory.html
This explains the function of the xbl partition, which in turn explains why you are stuck in EDL mode. Note that EDL and QDL are pretty much interchangeable. The device is failing to start and entering a state that allows you to restore it to a functional state. This is marked by the USB device ID 05c6:9008 which is the definitive indication that EDL mode is active.
Unfortunately, Sailfish seems to be producing a steady stream of bricks and I'm afraid it won't let up until the developers somehow figure out how to disable formatting the internal partitions.
I have been working with two other folks who have also overwritten xbl on their devices under Sailfish. I've updated my code to properly flash all of the partitions (including xbl) and given test copies to them. One has successfully fixed his device and I'm waiting on the other to confirm. I'll update my restore tool over the next day or two with the fix and I'll let you know when it's done.
-
1
-
2
-
-
4 minutes ago, bmccrary said:
For us qwerty peeps, can we use the boot image too? I'd be really happy just to have arrow keys that go in the right direction.
That will be fixed in the next build. But yes you can also play with the keymap.
-
2
-
-
Okay all you qwertz folks, here's a Lineage boot image with my new keyboard driver: files.nwwn.com/android/pro1/boot-newkeyboard.img
To use it, flash it to your boot partition, "fastboot flash boot boot-newkeyboard.img". Upon reboot the keyboard will have version 0002 which will make Android ignore the custom keymap file in the vendor partition. You will find the following files:
/sys/devices/soc/c17a000.i2c/i2c-6/6-0058/layout
This is the layout file. It can contain "qwerty" or "qwertz". So start by setting it to qwertz:
echo "qwertz" > /sys/devices/soc/c17a000.i2c/i2c-6/6-0058/layout
This will load the qwertz keymap into memory. Now go to the keyboard settings and set either "US English international" or "German" or whatever you like based on the international keyboard.
/sys/devices/soc/c17a000.i2c/i2c-6/6-0058/keymap
This is the keymap file. It contains the mapping for each of the 64 physical keys in the form:
keynum:keycode:fn_keycode
Where:
keynum is the physical key number in decimal.
keycode is the Linux keycode in hex (see include/uapi/linux/input-event-codes.h in the kernel).
fn_keycode is the Linux keycode in hex when fn (yellow arrow is pressed), plus modifiers. Modifiers are logically OR'd:
0x8000: shift
0x4000: ctrl
0x2000: alt
For example "3:0008:8008" means key 3 ("7") generates keycode 8 (KEY_7) normally and shifted KEY_7 when fn is pressed.
You can edit individual keys. So to make the 7 key generate an 8 instead, echo "3:0009:8009" > keymap.
Also I've left debugging in the driver for ease of editing the keymap. To watch the messages, run:
cat /dev/kmsg | grep aw9523
You will see the keyboard messages in real-time.
This is obviously a security issue so it is only there until the keymap is finalized.
So... take a spin with the new driver and let me know how badly I messed it up. 🙂
If you want to make changes (and you probably will), get it working correctly and then send me your keymap file. I'll update the driver and send out a new test for verification.
-
4
-
3
-
Factory Restore Tool
in Support
Posted
FYI... for those following this thread:
The Linux and Windows tools have been updated and now flash xbl properly. This has been verified with real bricked devices (no shortage of those recently!) I'll try to update the MacOS version within a day or two.
I asked the Sailfish developers to please remove the option to flash internal storage partitions. They had no idea so many people were doing this, and said they would fix it soon. That's great, but why didn't they know? Did nobody file a bug report or anything after bricking their device?!?