tdm
-
Content Count
801 -
Joined
-
Last visited
-
Days Won
84
Posts posted by tdm
-
-
I believe the core issue is that Android does not have a separate concept of lid/cover and slider. It only has logic for a "lid". We are using this for the slider but it's not really suitable for our usage.
Eventually, when some of the more major issues are sorted out, I would like to resolve this by separating the logic for these things in the core Android logic. I'm not sure AOSP would take the patches but I'm pretty sure Lineage will.
-
2
-
2
-
-
test5 build is up. I've added a changelog section to my lineage page so you can see what is new. Most all the changes from test4 are keyboard related. Please note that in addition to the listed changes:
The vendor blobs are unchanged from test4. I got the updated vendor image from @bmccrary but haven't had time to pull in the updated files yet.
a2dp is still not working. I looked at it briefly but still can't figure it out. I don't think it's super high priority right now, so I'm not blocking test releases on it.
qwertz keyboard users must still set their keyboard layout manually at each boot. I'll add support for reading a file in /persist at boot in the next release (tomorrow or the day after). And of course I'll also be adding a UI for setting qwerty/qwertz at some point soon.
For those who build from source: the "common" device tree has been folded into the main pro1 device tree, so there is no more device/idealte/msm8998-common. The common tree was an artifact of starting from the 1+5/5t trees. I kept it around in case another idealte msm8998 device was discovered. But none have been found so far and it's highly unlikely they will be supported in the future.
-
2
-
5
-
-
1 hour ago, EskeRahn said:
The Pro1 got TWO hall probes, one for the slider and one for a lid! See this. So it is prepared for a flip-case.
Can you guys doing the LineageOS patches for the Keyboard slider copy that detection code, and use it to handle screen off from the other probe also? That would be pretty awesome!
Actually I was very surprised that the Hall sensor was there, but it does not seem to do anything.
Yes, there are two hall sensors. I'm not sure if they are both present and working in hardware though.
Supporting both hall sensor may be tricky. I'll have to dig into it if/when someone makes a flip case. But I think there is really only support for one "lid" sensor in the Android framework. And that is used by the keyboard slider. This is oem_hallb in the DT file, and it generates SW_LID. The other hall sensor generates key F3 which seems strange.
-
1
-
2
-
-
5 hours ago, spam71 said:
Hello
Since you're The Pro1 Developer, do you think it might be possible to add kernel support for "battery idle mode" - I mean the state with charger plugged in, when battery is charged to some level, for example 80%, but is neither charged up further nor starts discharging - phone takes energy from charger, but not from battery. There are apps that can utilize this mode to preserve battery life (i.e. ACC: https://github.com/VR-25/acc/ ACCA: https://github.com/MatteCarra/AccA).
As for now, with these apps, Pro1 stops charging at given threshold, but instead of keeping this level, bypassing battery and using current from charger, it starts discharging until it reaches lower threshold, when it starts charging again, and the loop continues.
It's something similar to what Lenovo does in ThinkPads for decades now, and lowers battery wear significantly.
KT
I'm not familiar with this, so I would have to check into it. The device is pretty generic Qualcomm so if there are any generic patches needed, feel free to point me to them.
-
1
-
-
6 hours ago, EskeRahn said:
Yeah, Though I sit with one question for @tdm, @Sean McCreary and others helping: Where are your guys donate buttons, so we can send you 'a beer'?
Thank you for your consideration. 🙂 I generally don't accept donations when I've been given a device for development. But I've spent a lot of time on this device. Here's my paypal: https://www.paypal.me/tdmcode
-
6
-
-
12 hours ago, bmccrary said:
@bmccrary many thanks, I downloaded it and it loopback mounts fine. Here's the relevant info from /vendor/build.prop:
ro.vendor.build.date=Tue Dec 10 15:11:44 CST 2019 ro.vendor.build.security_patch=2019-09-05 persist.sys.oeminfo=QX1000_user_20191210151401_bc46cd7
So it's newer than anything I have.
If anyone spots any newer builds, please feel free to post them.
-
15 minutes ago, bmccrary said:
I'm not sure I know exactly what to do but if you mean basically tar up a copy of /system/vendor I can do that. I had to go back to stock for now.
Well vendor is on its own partition. What I usually do is boot into recovery and 'dd' the vendor partition to /tmp:
did if=/dev/block/by-name/vendor_a of=/tmp/vendor.img
Then you can gzip it and adb pull it.
In order to do that you would probably need to use TWRP since lineage recovery won't have your host adb key setup.
-
1
-
-
Oh and referencing my previous post, if anyone wants to help out, can you go back to stock and take the latest ota and then post a copy of the vendor image somewhere? That would save me a couple hours of work.
-
28 minutes ago, Craig said:
Sorry for my ridiculous rant earlier. Dont even remember posting it. But it explains the way I'm feeling today, and why it was so hard to get up this morning. 1.75L bottles are big. Nothing justifies what I said or the way I said it tho.
By my calculations, that's roughly 32 units of alcohol per bottle. Pardon the personal interjection, but I certainly hope you didn't go through the entire thing in one night. I mean, I've drank quite a bit in my day (but haven't in quite some time now) and I think that would have killed me even at my peak of drinking.
-
2
-
1
-
-
I've been actually developing on the Pro¹ today, which is a bit of a strange experience. I'm using ConnectBot to ssh into my build box, enabling adb over network, and connecting back to the device to push files and etc. Then I run "adb reboot" and *poof* the terminal goes away and the device reboots.
Anyway... so I've been pulling in patches from @Sean McCreary
and it looks like he's got the keyboard backlight fixed and the wake on any key fixed. So I'll probably make another build with those changes tomorrow.PS. Please forgive formatting errors, this forum does not seem to play well with FireFox mobile
-
4
-
2
-
-
Regarding the slider causing the device to sleep, this is a build time configuration that, as far as I know, has no run time setting. So I guess whichever people like the most is what should be done. Personally, I find it very frustrating when the device goes to sleep on closing the slider because I frequently open the slider to type some text and then close it to go back to portrait/touch mode.
Regarding wake on keypress, I've got an idea for that and it is both pretty simple and should work for all systems (including sailfish). Just track the screen state in the keyboard driver and if it's off, send KEY_WAKEUP before anything else.
Regarding the keyboard backlight, I believe @Sean McCreary has a fix for that in his tree. I'll probably take that for the next build. Or at least it's a start.
Regarding the crashing issues, I have not changed anything related in the kernel since test2. So whatever is causing this is likely in the vendor image. It could be either the 20191028 blobs that I'm using or it could be the things that are getting built from source. That will have to be narrowed down. By the way, I'm using the 20191028 blobs because the 20191203 build caused the screen on my device to act weird (it blinked off momentarily every few seconds). So I haven't tried to update yet. And those are the only two builds that I currently have because IdeaLTE and FxTec have not shared any later builds, and I haven't bothered to go back to stock to take any OTA updates.
But yeah, none of this is done yet because I'm lazy and Lineage sucks. You should probably have me fired and go find another developer that can do a better job. I never do anything useful or good for this device. 🙄
EDIT: And also, I just spent half an hour explaining why things are the way thay are instead of fixing things. This is why developers don't really like forums. I have half a mind to just stop engaging with this thread entirely until the device is working fully.
-
17
-
-
3 hours ago, mechtec said:
Thanks, that worked perfect. What does this mean for the future? Will slot B eventually fail to work too?
I'm not sure, this is my first experience developing on an AVB device. It could have been that I disabled the vbmeta checking in the earlier builds, but I don't know for sure.
-
1 hour ago, spam71 said:
Hello. Does anyone know how to get r/w permissions for /system? I tried to replace keyboard *.kcm file with one for Polish letters, but I couldn't mount system r/w even though I had root privileges.
You need to do it via adb:
adb root
adb remount
Edit: oh, and for kcm files, I believe you can place your custom files in /data/system.
-
2 hours ago, mechtec said:
So I was going to try out test4. I downloaded, confirmed the MD5 matched and rebooted to recovery and hit apply update and sideload. However when I do a sideload the computer shows 0.0 transfer and the phone displays an error failed to verify package compatibility. Runtime info and framework compatibility matrix are incompatible. bmeta version 0.0 does not match framework matrix 1.0. Any idea's?
I did flash addonsu-16.0, but I think I flashed that after test2 as well and did not end up with this issue. I also tried flashing test3 and I end up with the same error as when I try and flash test4. The addonsu package still flashes fine if I try that one.
I would prefer not to lose all my userdata again, but if I have to I can do another setup of the phone.
Yes I've had this issue. Try using recovery from the other slot.
-
1
-
-
17 minutes ago, mcdinner said:
@tdm thx for the update, did you fix anything except the keyboard mapping? Calls are still broken for me + Audio errors in log. (with bluetooth off)
No this update was mostly just keyboard. I'll be working on audio next.
-
1
-
3
-
-
I just stumbled across this thread. No, you cannot create sysfs files. They are virtual files that are used to exchange information between the kernel and userspace. If there is no kernel code to handle reading and writing, the file cannot exist. This is why you cannot create it even as root.
So if the APK does work, it must be doing something else.
-
6 minutes ago, mcdinner said:
@tdmThx for the new build, I'll install it soon.
Could you update the md5/sha1 susm for the new files ?Oh didn't I do that? Thought I had...
-
1
-
1
-
-
3 minutes ago, Craig said:
Those two commits will be very welcomed by me. That'll get the sym key seen, symbol keyboard, and global keyboard shortcuts.
As to the left control, I'd mentioned that myself in my long post on what I thought modifiers should be and why, so I certainly did notice and like it better that way.
As to detecting the slant arrows. Not important in the supertux case, as I can use other keys now freely without worrying about chording and rollover issues. However my personal goal is to make the right slant arrow behave as slash, something I suspect would never make it into LOS cuz it doesnt match the print. I had previously with stock used keymapper to assing the sym key as slash as a temporary workaround. Keymapper now doesnt see sym or slant arrow keys either so I can't use that.
You said this method makes all keys remappable, so I'm going to read what you and thekit were discussing yesterday to see if I can make sense of it enough to use your method to do it.
Okay so yeah ... right now the gpio keys are not remappable. But I would like to add that in the future. That would let you map the right slant arrow (and the fxtec key) to whatever you like.
The main issue with doing this is that it introduces the possibility that there may be multiple modifier keys, which complicates the keyboard logic. Right now I've just got two bool variables for each modifier -- one to tell if the key is physically down and one to tell if it is logically (forced) down. That would need to change. The physical flag would need to be a counter for the number of keys that are down for each modifier. For example, suppose you map the left slant arrow to a normal left shift. Now you can press either left slant arrow or one of the shift keys to get a shift down indication in userspace. If you press both, you don't want a duplicate indication sent to userspace. And it's important to keep track of the number of shift keys held down for the code that manages the logical (forced) shift state.
Ultimately it's very doable and not a big deal. But it does require some non-trivial work that I would rather pass on for now, because I've already spent way too much time on the keyboard driver and not enough time on other stuff.
-
3
-
-
8 minutes ago, Craig said:
Thanks much! I just installed test4 and going to see how the keyboard works! Haven't done much yet, but right off the bat it seems some keys can't be seen by Supertux that could be seen by stock. I know this isn't the most important app, but its something I'm famliar with and a way to test key chording and assignments, and a way I can see if leght and right slant arrow are now separated. On stock rom, supertux calls the Sym key 'left super' and both slant arrows 'right super'. However, with this version of LOS, it can't see the slant arrows or the sym key at all! just acts like I didnt press a key at all. (Alt still working as left alt, both shifts still left shift, and now both controls are left control!)
Elsewhere, sticky shift and longpress for accented characters works tho, happy about that!
Anyway gunna keep playing with it, just noticed that right away.
In the current keyboard driver, the slant arrows are completely dead modifiers. That is, they never generate any key presses on their own. They only affect behavior of other keys. This ensures that the kernel and userspace never get out of sync with respect to modifier state. Is it important to be able to detect the slant arrows?
I mapped the sym key to KEY_SYM because it looked logical. However, going back and looking more closely, it seems that KEY_SYM was added by the OEM and is not an official Linux key code. So I'll need to change that. I had planned to take at least these changes from @Sean McCreary :
I'm sure you are aware that the pairs of shift, ctrl, alt keys are wired together so both appear as a single key in hardware and they cannot be separated. I did make them all generate left versions of their keys for consistency. I didn't think anyone would care (or even notice).
-
47 minutes ago, d said:
Do you have any idea why aptx does not seem to be working on the stock rom?
Thanks!
I don't recall seeing the aptX files on stock. Which leads me to believe that FxTec did not license aptX.
-
2
-
-
test4 build is up.
This has the shiny new keyboard driver and a kcm file that declares the keyboard type to be ALPHA. I am still working on persisting the keyboard layout, so qwertz users will need to "adb root" and then "echo qwertz > /sys/bus/i2c/drivers/aw9523b/6-0058/layout" after each boot.
It also has the fingerprint reader fix and a few other things that I can't recall at the moment.
I'll try to get new builds out more regularly now that the hard work on the keyboard has been done. Things you are likely to see in test5: persisted keyboard settings, keyboard backlight working, a2dp working.
-
12
-
-
Yes there will be an official lineage build. But first all the major issues must be resolved. And as you have found, there are a few. I think everything you mentioned is a known issue. Look on my lineage page for the git repos and issue tracker link.
I'm working through the issues as I can. I do this in my "spare" time and I'm not paid except for having been given a device for development.
As you may have noticed, I'm working on quite a lot more than just lineage. I've released a factory restore tool that has saved at least a dozen sailfish victims from bricking their devices and released a version of stock without Google apps. Currently I'm rewriting the keyboard driver to make it work better for everyone. That's pretty much done -- I had thought I was done this morning but @netman schooled me on detecting ghosting. So early tomorrow I'll be back to fixing lineage issues.
Upgrades should not require wiping data. If they do, that's a bug. I don't know what the issue was but it shouldn't happen again.
There is currently no data backup solution except "adb backup" and mtp. I'll be building a TWRP that can decrypt data soon. But that will come after the lineage ROM is usable, as lineage is my top priority right now.
PS: sorry this text isn't better organized. I'm writing on my mobile phone while I have a few minutes before the kids' bedtimes. Did I mention that my life is rather busy? 😉
-
1
-
9
-
-
8 hours ago, netman said:
Is the github up to date with this? My version of the driver does anti ghosting properly (hence the extra loop, scanning twice, different re-init sequence and polling), and I've tested this extensively. The issues on boot are due to P1 being initialized incorrectly.
I haven't pushed my code up to github yet, I'm testing some changes. Android seems to be unhappy when you tell it that you can generate all possible keycodes and it rejects the keyboard (amusingly, it says the internal keyboard is not connected while getevent happily reports all the events). So I'm trying to figure out exactly what it's checking.
I fixed ghosting by switching to polling when any key is down and then back to irq when all keys are released. That's not optimal -- I would like to only mask the interrupt and poll for rows where keys are down (and thus ghosting is possible) but I haven't gotten that logic quite correct yet. It's not a huge deal, just a nice touch that I would like to get working correctly.
Yes, I noticed and added the missing P1 init.
-
1
-
-
23 minutes ago, Craig said:
I thought it all thru again, after learning even more. Updated the long post before, so I think its now ideal; I'd love to hear from those who think its not ideal. And I'd love if tdm read it again now that i've updated it based on even better understanding.
https://community.fxtec.com/topic/2509-lineageos-160-test-builds/?do=findComment&comment=44147
I read over your revised text and it's making more sense. I am open to the FxTec key being used as the dead modifier and using the slant arrows as other modifiers. But that still wouldn't get F# because FxTec+# would need to generate the yellow symbols (for consistency). I'm sure there's another way to generate them though.
One thing I'm not clear on is, what do you mean by "'alpha' keyboard definition"?
LineageOS, Current status : 16.0 Test Builds
in Support
Posted
@EskeRahn yes, just sending KEY_WAKEUP and KEY_SLEEP could work for a simple cover. But if there is a window in the cover, the system needs to know when the cover is opened and closed to show the appropriate information through the window (this is done via the FlipFlap package in Lineage). So I guess we'll see what kinds of covers show up, if any.
@mcdinner I'll have to look into the backlight code. It's currently in the lights HAL (this is where @Sean McCreary put it). I don't think the lights HAL will get notified on lid events, so it may need to spawn a thread and listen to the appropriate event node to track the slider state. But the current code is probably okay for now, right @Craig? 😄
And finally, I've uploaded test6. This has updated blobs from 20200106 and it also has the code to set the keyboard layout (and keymap and poll_interval) on boot. There is no UI for the keyboard settings yet, so you need to create the files manually. They are in directory /persist/data/keyboard, named the same as the sysfs nodes. Here's an example of how to set qwertz (these are shell commands, run as root):
mkdir -p /persist/data/keyboard
echo "qwertz" > /persist/data/keyboard/layout
Now the keyboard should be set to qwertz at boot.