tdm
-
Content Count
801 -
Joined
-
Last visited
-
Days Won
84
Posts posted by tdm
-
-
Certainly it would be nice if someone official created an issue tracker. But until that happens, I think github issue tracker is much nicer than a spreadsheet. If someone could import the spreadsheet into the issue tracker that would be really nice. Heck, I might even make a new stock build with some of the issues fixed... 😄
-
5
-
2
-
-
2 hours ago, NukaNegan said:
Also, where can I get all of the hardware binaries so I can roll my own AOSP?
Similar to pretty much any other Android phone, you do a build by pulling binaries off the device. I don't know if FxTec has provided any "official" kernel sources but this repo has the full OEM history, which is a step above your typical "here's a tarball" that most every other OEM does:
https://github.com/tdm/android_kernel_idealte_msm8998/commits/oem-history
-
1
-
3
-
-
Modem crashes are always fatal, eg. reboot AFAIK. And the modem software is completely closed source. The OEM may have the source, I don't know. If they do, I might be able to build a kernel that crashes to ramdump mode. This would allow you to pull a copy of the device state at the time of the crash and send it to the OEM for analysis.
-
5
-
-
Since both devices are Linux, I need to clarify... you need to be root on the host or on the phone?
If it's on the host, which I assume since there isn't any official way to become root on stock, it is likely because your udev rules are not marking the specific vid:pid used by the pro1 as owned by the correct group.
I can tell you that the pro1 has a very minimal set of changes from the qcom bsp so it's probably using the default qcom USB compositions. Many device vendors customize these.
-
1
-
-
@Khalid I'll refer you to a post that I made a bit over a week ago:
The tldr of it is that yes, FxTec nerfed the software and as a result they don't even really have control over the OTA contents or timing. Big mistake? Absolutely. End of the world? Not even close. Software will improve over time and there are alternative ROMs to choose from. Lineage, in particular, is now quite usable except for the notification light (which will be fixed in short order) and has even started to grow some features to accommodate the issues you raised such as edge touch sensitivity, etc.
Now, if you expected or wanted a nice polished package like you would get from a big company, well, sorry, ain't gonna happen. FxTec is basically a two man show toiling hard to produce a quality piece of hardware that has been missing in the market for years. They simply don't have that kind of resources. So you should probably sell the phone to someone on this forum and find a nice shiny iGalaxyThing to use.
-
12
-
1
-
-
There are a variety of things that can hamper performance. You just need to go through them and find the one causing problems. The most obvious is the CPU cores: they can be disabled or thermal throttled for starters. Then there is performance stalls like for example audio or video timing out due to some problem.
So unfortunately there isn't an easy answer. 😞
-
3
-
1
-
-
43 minutes ago, JooJooBee666 said:
Spoke too soon....somehow it came back later in the day and even back after a reboot. How was it gone earlier?
Try playing with the audio buffer sizes, and maybe diff 1+5 settings.
-
11 minutes ago, EskeRahn said:
I think it is much a user-dependant thing. When opened I'm yet to experience accidental touches clicking the numbers.
But it requires more care opening.
Personally I ONLY have problems with the edges when it is closed. Not when opened.
Others have huge problems clicking the numbers. I would say the thumb-width is what matters.
So I would prefer a setting. But when you got one slider, would it be much work to copy and paste to four? Giving the user complete control of the two edges, opened and closed.
It's not so much a matter of the work involved. It would be very quick and easy to provide four sliders. But I think that makes the UI way too complicated.
My criteria for options is not just implementing something that somebody wants or even needs. It is more like:
(1) is this needed and/or reasonable? if no, reject.
(2) is this something that everyone needs or is benign if always set? if so, just do it without an option.
(3) make an option in the simplest, clearest way possible.
11 minutes ago, EskeRahn said:ADD: OH! Please draw some lines or something when the slider is pulled, so we can see where the limits we select are. Just let them be cleared when the slider is released.
I'll look into adding a visual indicator in the settings widgets. It's not necessarily easy to do because of the way Android measures UI elements.
-
2
-
-
1 hour ago, EskeRahn said:
BTW it would be great if the two edge margins were handled independent.
The Keyboard-edge can take a lot more margin than the opposite without affecting functionality.
And it is the side that is most prone to accidental touches both opening by pushing, and for entering numbers.
Actually I think increasing the left margin when the slider is out might be a better solution. I'm just wondering if it should be a multiple of the user margin setting (1.5x? 2.0x?) or a fixed number.
-
1
-
-
8 minutes ago, EskeRahn said:
Oddly only ONE of the two units had this ??? The "Final Sample". The old "Pre-Production" did NOT. And anyway it was only initially, so at most a very low priority thing.
You got a Pre Production too for the testing, right? So it just MIGHT be that they changed something - or that it was merely a strange coincidence.
Let us not dwell on it, we will see if any other see the same. 😊
I have a very early prototype that has reduced edge sensitivity... a built-in margin. 🙂 It also has zeros for IMEIs which makes it unsuitable for testing radio things. So I was provided a near-production prototype that has valid IMEIs and also better edge sensitivity. I use the earlier one for stock and the later one for lineage.
-
1
-
1
-
-
2 minutes ago, EskeRahn said:
BTW it would be great if the two edge margins were handled independent.
The Keyboard-edge can take a lot more margin than the opposite without affecting functionality.
And it is the side that are most prone to accidental touches both opening by pushing, and for entering numbers.
Okay I'll put that on my todo-list.
-
4
-
-
10 minutes ago, EskeRahn said:
I see, not a big deal in any way, only an initial issue looking for it. 🙂
Thanks for the explanation. If it is power consuming, perhaps it would be beneficial to slow it down to say 100ms when the keyboard backlight times out, so it only consumes when needed.
It did not work when I initially changed it from zero. But after the restart I can change it and even set it to zero and up again. Could it be an initialization issue?
The keyboard driver only polls when at least one key is pressed. When no keys are pressed, it uses interrupts. So there should be little concern for the CPU usage. I could even get rid of the option and always use 20ms. I just preferred the longer delay because I could not detect any keyboard lag at all with 40ms.
Also note that there is still one more optimization that I would like to make for the keyboard, which is a hybrid interrupt/poll mode. In this mode, the driver would only poll on the rows that have keys pressed (it is currently all-or-nothing). This would reduce the work done in the polling code by a factor of 8, approximately, and alleviate any concerns about CPU usage even when polling fast.
I have no explanation for the margin failing to set on first try.
-
2
-
2
-
-
1 minute ago, EskeRahn said:
AH! Thanks! Looked around a bit but did not find it. The setting-search does not list them either, is it limited to the build in Lineage stuff, or does it require manually adding keywords?
I believe there is supposed to be code to add those settings into the search results. But I just copy-pasted it from an example and I do not understand it at all. I can investigate.
1 minute ago, EskeRahn said:Just curious, what does "Fast poll" do?
That is for the keyboard polling. When no keys are down, the keyboard driver relies on interrupts to detect key presses. But due to the way the hardware is designed, this doesn't work for certain key combinations when a key is already pressed. So, in order to detect two keys down at once, it is necessary to poll for changes. The faster you poll, the quicker the response time and the more CPU is used. So there is a balance to be struck. The default is 40ms, but @netman likes 20ms for gaming, so "fast poll" switches to 20ms.
1 minute ago, EskeRahn said:OH, a TINY request: In the new Margin selection screen, A text saying something like "Restart to activate changes".
You need not restart, the change should be immediate. If it is not, there is a bug.
-
I believe I've found the issues with both the WiFi signal strength indicator and the notification lights. Both are broken because there are some Lineage specific changes that need to be applied to the kernel. So I'll try to get those working early next week. Details:
The 1+5/5t (which is what I copied to start the pro1) has the WiFi driver built into the kernel and a couple other minor surrounding changes. The pro1 has the WiFi driver as a module (as the BSP does). The wlan sysfs node is in a different place for built-in vs. module, which is why the signal strength is broken.
The 1+5/5t has a Lineage specific change (actually written by a former Cyanogen co-worker) in the LED blinking code. I have not applied this yet, which is why the blinking does not work. I'll have to look at the vibration system but it's probably equally trivial.
So that will get rid of 2 of the 4 remaining regressions from stock. And probably the only two that anyone really cares about. 🙂
-
7
-
-
21 minutes ago, EskeRahn said:
How do I activate the new touchscreen margin?
I can not find the settings UI for keyboard and touchscreenYou should see the options in the system section when you select "advanced".
-
2
-
-
36 minutes ago, david said:
So, does that mean 98 downloads or can it tell how many unique Pro1 devices are running it?
A unique ID is generated at first boot after a wipe. When you opt-in to stats, it sends the ID and device model every 24 hours. I believe the page counts the last 90 days. So this is the count of active devices that are opt-in, with duplicates for each time you wipe.
-
2
-
-
-
1
-
2
-
-
I took some time today to organize the issue list, add labels, and such. Things are looking pretty decent. For example, here is what remains for parity with stock:
-
4
-
-
9 minutes ago, JooJooBee666 said:
@tdm Just curious about this, but how are you building successfully from your device tree repo with the FMRadio package enabled? I have to remove it to allow the build to complete.
I hacked the FMRadio code locally to build. But I haven't pushed the fixes up to Lineage because it doesn't actually work. After investigating, I found that the QCOM BSP uses an entirely different FMRadio app and libs. Not sure how I'm going to handle that yet, so I've just left it as-is for now. The easiest thing to do is just what you've done -- remove the FMRadio package from the device tree.
-
1
-
-
52 minutes ago, JooJooBee666 said:
@tdm Just a thought on fixing the unwanted finger print read issues. I think most of the issues are due to accidental quick brushes with the sensor. Would it be possible to add a delay so that when it senses a touch, it doesn't send a read to the OS unless the touch remains active for a certain period of time, say 500ms?
I looked at the fingerprint stuff briefly today. Unfortunately most of it is closed source (even in the BSP -- the OEM tossed binaries into the device tree). So I need to come at it from either the kernel side or somehow override/shim the frameworks side.
-
3
-
1
-
-
test8 is up, you know the drill by now.
* a2dp should be working.
* Added touchscreen margin/deadzone.
* Added settings UI for keyboard and touchscreen (Settings -> System -> Advanced).
NOTE: if you use a custom keymap (looking at you @Craig) note the keymap file has moved. The reason is that /persist should only be used for things specific to the device that are invariant, eg. physical properties. So it is now read from "/data/system/keyboard/keymap". The file contents are the same, just "mv" the file over to the new location (creating the directory first, of course). But I think I've implemented the stuff that you use as options anyway, so you may be able to just delete the file.
Also, UI is not my strong suit. If you have any suggestions on improving how it looks, I'm all ears. 🙂
-
8
-
-
13 minutes ago, Gigadoc2 said:
To defend one of my favourite filesystems: I have my daily driver notebook running on btrfs since 2014, fully stable.
Anecdotal evidence is never sufficient for something as critical as a filesystem. And I have another anecdote -- I worked next to Steve Kondik (the "Cyanogen" in CyanogenMod that preceded LineageOS) while Cyanogen, Inc. was a thing. One day he announced that btrfs ate the data on his laptop and vowed never to use it again. On the other hand, I have never experienced a single data loss event in over 20 years of using ext2/3/4 on many different devices (desktops, server, and laptops) that wasn't hardware related.
Sure, if you want to use it and it works for you, go for it. And I have no doubt that it's getting more stable all the time. But negative experiences with filesystems live on for a long, long time.
13 minutes ago, Gigadoc2 said:But… I also wouldn't use it on an SD card. The strict COW nature of btrfs means that at some point you have to defragment (read: fully rewrite) it, and that will kill your SD card, no matter how expensive and high-end it was.
Indeed. Additionally the fancy features (including CoW) slow the performance considerably (search "btrfs vs ext4 benchmark"), and sdcards are already relatively slow.
-
1
-
-
2 minutes ago, Gigadoc2 said:
I am really curious to know what the problem was, if it's not too much work to explain 😇
The BSP uses a feature called "split a2dp" and handles a2dp in the audio HAL. This is proprietary and does not work with the open source audio stack. So Lineage does not use it, a2dp is handled by the AOSP code. In order to make this work, the audio configuration needs to be updated. Because of the way audio works in pro1 vs. 1+5/5t, the audio configuration file is in a different place (/vendor/etc/audio vs. /vendor/etc). I neglected to update the correct file. As soon as I updated the correct file, it started working. There are a couple other related changes but that's the big one.
-
2
-
3
-
-
btrfs is not supported on android, neither stock nor lineage. It wouldn't be terribly hard to add it to lineage but the issue is nobody wants to use it. It's not been very stable in the past and so trust isn't there. Probably won't be for a very long time, if ever. If you want to get away from fat/vfat/exfat, your best option is probably ext4. Lineage has supported ext4 sdcards for just about forever.
-
1
-
LineageOS, Current status : 16.0 Test Builds
in Support
Posted
@auvo.salmi the idea for the Lineage keyboard driver is to emulate a full PC keyboard. @Gigadoc2 had a long and detailed reply on the github issue page, which is very informative and I encourage others to read here. The idea is that you select your physical keyboard as QWERTY or QWERTZ and then let the standard Android keyboard layout stuff do its thing.
I do not have a QWERTZ device. And even if I did, I am a sheltered mono-lingual American so I wouldn't know how it's supposed to behave. The current QWERTZ layout was done with a picture of a QWERTZ pro1 device and a picture of a US-INTL keyboard side-by-side with absolutely no testing at all. So it is not surprising that some things are not exactly correct (indeed, it is somewhat surprising that it is not more broken).
I would greatly appreciate if all you QWERTZ folks could get together and come up with a keymap that fits best. I'll be happy to re-post the instructions for modifying the keymap. Alternatively, if that is not possible, we can discuss making additional layouts (but I don't know what to call them...)