tdm
-
Content Count
801 -
Joined
-
Last visited
-
Days Won
84
Posts posted by tdm
-
-
There are only 7 actual keys in row 0.
-
1
-
-
2 hours ago, EskeRahn said:
Is this a layout given by LineageOS, or something within your control?
If within your control, it would be awesome to extend it to mimic the four top rows of physical keys, and then let the corresponding key pressed when displayed give the symbol.
e.g. Press and release of Sym displays the map, a press on the 1-key, then gives the top left symbol displayed. etc. (preferable with the printed letters faintly printed on the image to ease orientation)
Make it even more awesome: allow Sym used as a modifier to give the same, e.g. Sym+1 ....
And this could be extended to more complex modifier combinations, giving access to and help for even more symbols....
...Just wishing/brain-storming...
I believe the layout of the symbol keyboard is overridable by the device at build time, but not run time. The behavior is most likely not overridable at all.
-
4 hours ago, Slion said:
This is for stock...
I changed those in Lineage.
-
1
-
-
13 minutes ago, Slion said:
This ought to make it to stocck somehow 😃
Unlikely, but we shall see. The change that enables the accent chooser is the same one that enables sticky shift: setting the keyboard type to ALPHA in the kcm file (instead of FULL). I'm not sure if that can be overridden. Perhaps others could investigate.
-
2
-
-
I would not hold my breath on this. Just off the top of my head I can name several show stoppers that any "decent" "enterprise" (*) IT policy would require:
- Secure Boot is disabled.
- Security patch level is out of date.
- WiFi and BT MAC addresses are bogus.
(*) definitions of decent and enterprise may vary, and frequently do.
-
1
-
-
It's a known bug in the keyboard driver. Certain keys are "dead" at reboot until you press any other key. I have not heard whether there are plans for a fix soon. But it's already fixed in Lineage.
-
3
-
-
Sorry that the phone didn't work out for you. Certainly there are different ideas about what hardware looks and functions best. But I must admit the software is currently a weak spot.
I'm going to respond to the software issues. Please keep in mind that I am not employed by FxTec, I'm just a developer who was given a device to get LineageOS running on it. Further, I'm not really a "keyboard phone" type, this is my first keyboard phone (but my wife used to love her Relay 4G, which is why I was the Cyanogen dev for that device for a while). I have gotten to know Chen and a few other devs over the past few months and have learned quite a bit about the history of the device hardware and software.
There really isn't any excuse for releasing a device with such unpolished software. But I can tell you that one of the big reasons it's so unpolished is that FxTec basically does zero software development. The OEM, IdeaLTE, is responsible for building the stock software and incorporating changes requested by FxTec. Being a small Chinese OEM, there are several barriers to communication and they are not exactly the most responsive to work with. This is one reason why Chen is pushing alternative software so much.
I'm currently in the process of getting LineageOS running well on the device. It shouldn't be long before it's better than stock. At that point, I can look into adding some features to compensate for some of the hardware deficiencies. Like, for example, adding an option to ignore touches on the outer few screen pixels.
So if you ever decide to give it another go, or anyone else reading this has similar concerns, just be patient. Software will be able to cover some of these issues. But it's not likely to show up in stock.
-
14
-
-
1 hour ago, Polaris said:
Ok, per your request I will file an issue on the tracker page, but please remember that it would stop working with the stock ROM, and I setup a poll to see if this was a known issue. Very few people responded to the poll, but it appeared as though it was working correctly for most. Thus, I'm not sure if my original problem got pushed into Lineage (with regard to the LED at least. The vibrate option always worked in the stock ROM, so that might be a Lineage thing?). Thanks again for everything!
It's mostly just a reminder for me to look at the code. The current lights code hasn't really been tested or anything, it was just brought along with the initial stuff from 1+5/5t.
-
1
-
-
45 minutes ago, Polaris said:
It's no secret that I was having trouble with the notification LED and the stock ROM, so I decided to switch over to LOS to see its behavior. With LOS, I don't have any notification LED control whatsoever. It still works properly when charging, but that is the only time it lights up. Not a single notification, or 3rd party app which uses the LED, activates it. I have also lost the notification vibrations (unlike stock which worked perfectly) unless I'm using a 3rd party software. I didn't see any of this in the issue tracker, so I'm assuming this is just my device...?
Please file an issue on the tracker and I'll look at it probably Monday. I'm already in the lights code with the keyboard backlight.
-
2
-
-
33 minutes ago, VaZso said:
Restart the phone - it works for me. 😀
Without joke - it forgets all of my fingerprints if I restart the phone.
I had only one time it remained set whe I have rebooted the phone several times to test something.This is one of the "other issues" that I mentioned in my earlier post. The vendor data and framework data get out of sync under certain conditions, for example when you wipe data (aka. factory reset). This is a problem because the vendor data only seems able to hold 5 fingerprints and doesn't seem to ever delete its data.
So once you have registered 5 fingerprints total, any further fingerprints registered will not be saved in the vendor data until the vendor data in /persist is deleted (this is why it works until you reboot). Deleting the vendor data in /persist requires root access. Which means those using stock software are kind of screwed until the OEM fixes this.
-
1
-
1
-
-
There are two places in the code that handle fingerprint data. The vendor code is responsible for storing the actual fingerprint data corresponding to your finger and assigning it an identifier (ID). This particular FP vendor stores its data under /persist which has caused other issues. The vendor code tells the Android framework its list of ID values on request. Android stores the ID values and some other bits of information in another place (under /data).
It is possible (I would say likely) that the issue is in the vendor code. It probably isn't actually deleting your fingerprint data. Unfortunately, I believe the vendor code is all binaries (no source code provided) even at the OEM level. So this would be a difficult issue to investigate and even more difficult to fix without getting IdeaLTE (the phone OEM) and BetterLife (the FP vendor) involved.
-
5
-
-
Been hacking on the lights HAL this morning (shhh, don't tell my wife). I think I've got the logic figured out so that the keyboard backlight always keeps the proper state (which is, on only when both the screen is on and the slider is out).
-
8
-
-
1 hour ago, mcdinner said:
@tdm After I got called today and audio was gone again, the tries after that were broken too.
yesterday my tests were all fine and id did several successful calls with display off and on a few times...
Thanks. So the issue isn't calling specifically but something in the audio stack that calling uses.
-
1
-
-
2 minutes ago, JooJooBee666 said:
@tdm ok, thanks. I'm really not sure what to do with the backtrace here as there is so little information. I can't use addr2line to trace it back to anything as it abruptly ends on <unknown>. The only thing I was planning on attempting was just replacing all the audio libraries from the last known working vendor.img I have and seeing if that helped, unless you can confirm these have NOT changed since McCreary's manually created vendor imgs?
I cannot confirm nor deny any audio changes, as I'm not at a PC. Look at the proprietary files lists to see what is copied from stock. The rest is built.
Edit: also look at the vendor audio props.
-
@JooJooBee666 yes I'm aware that audio still has issues. I plan to make that top priority for next week. But feel free to poke at it before then. :)
The issue with stock vendor is the fstab -- stock uses FDE and lineage uses FBE. You need to do some shenanigans to overlay the lineage fstab to let it boot with stock vendor.
-
2
-
-
FYI .. I'm heading out of town shortly and won't be back until Monday. No new builds until then. I'll leave you with a Lineage splash that I made just for fun:
Flash this to the "splash" partition with fastboot. Here's the original in case you want to go back:
-
3
-
-
21 minutes ago, mcdinner said:
I checked gsm call and it seems to work now with test6. 😄 I'll check again tomorrow.
Something seems to be off with the clock.
I rebooted at ~19:40 and before putting in my sim pin my 7:20 morning alarm activated. Weird...
Also the last full charge from battery is 22 hours ago which is wrong because I started charging when i got to bed and it should not be more than 18 hours.
I can give you the logs if it helps.Hmm, that is odd. When is the last time you checked GSM calling? The vendor update did not change much:
$ git show --name-only HEAD | grep "^pro1" | egrep -v "(jar|apk)$" | egrep -v "(chromatix|camera)"
pro1/proprietary/vendor/etc/sensors/sensor_def_qcomdev.conf
pro1/proprietary/vendor/firmware/ipa_fws.b01
pro1/proprietary/vendor/firmware/ipa_fws.elf
pro1/proprietary/vendor/firmware/ipa_fws.mdtCan someone else verify that GSM calling works?
As for the clock, I haven't changed anything there. Qualcomm devices don't keep time between reboots, so time is fetched from the cell network or NTP at boot. But if the device was on the entire time, it should have kept time properly. I've had no issues with my device. Anyone else?
-
I've done a bit of testing with SIP this morning because I haven't gotten voice working with my cell provider. Both inbound and outbound SIP calls seem to work fine. So any calling issues must be with the actual cell radio.
-
4
-
-
26 minutes ago, EskeRahn said:
(I just waned to make sure that the bug from the current stock has not been copied over to Lineage. With stock you can try to close on say a toothpick, and see you can activate keys even if the slider is closed, this means that squeezing the device in say a pocket can press a key)
This issue should still be in the current kernel. Please file an issue on github so I will remember to fix it.
-
1
-
-
13 minutes ago, bmccrary said:
I'd be happy to send you a working SIM card you could use if you would ever want to play around with it.
Thanks, I may take you up on this at some point.
-
14 minutes ago, EskeRahn said:
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.
I believe it is turned off when the device is sleeping (not necessarily just when the screen is off or when the slider is closed). At least that is what the code says. My plan was to detect when the screen is off and send KEY_WAKEUP instead of the pressed key (eg. eat the keypress).
-
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?
-
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?
-
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.
-
4
-
LineageOS, Current status : 16.0 Test Builds
in Support
Posted
I found some missing libs yesterday. I almost pushed a new build but decided to wait until I investigated a2dp a bit more. Should have a new build in a few hours either way.