tdm

@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

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.

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

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.

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.

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

@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.

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.

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.

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.

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

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 drive

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.

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.

Yes I've had this issue. Try using recovery from the other slot.

No this update was mostly just keyboard. I'll be working on audio next.

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.

Oh didn't I do that? Thought I had...

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 numbe

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 th

I don't recall seeing the aptX files on stock. Which leads me to believe that FxTec did not license aptX.

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 setting

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 d

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 pos

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"?