tdm
-
Content Count
801 -
Joined
-
Last visited
-
Days Won
84
Posts posted by tdm
-
-
7 minutes ago, skrilax said:
@tdm can you actually compile ABL? Perhaps a good idea would be to enable "fastboot boot" command.
Unfortunately I haven't been able to build abl yet.
I know it's possible, as an fxtec developer said he was able to build it. He was using a different like Linux distro than me, which may be the issue.
One of these days after lineage and the factory restore tool are both humming along without issues I'll try again.
-
1
-
1
-
-
I'm working on the changes to allow selecting qwertz in the kernel hardware key map. I should have something to test tomorrow.
-
3
-
2
-
-
8 minutes ago, EskeRahn said:
But the hardware codes emitted are the same. That is the point. Do you mean what the .kcm should remap it to for German? If so look at his .kcm files.
Do you plan to build two system images that sends different codes for the two prints?
Hmm, okay. If the hardware codes are the same then I should be able to work that out. My plan is to allow the user to select the keyboard variant, qwerty or qwertz. The selection should be saved (eg. in /persist) so it only needs to be done once. User space will write the variant to a kernel sysfs node, which will switch the hardware keymap. The end result is that you should be able to operate the keyboard exactly like a USB keyboard, selecting the built-in German layout.
-
2
-
2
-
-
3 minutes ago, EskeRahn said:
Yes.
Excellent, thank you. So now I need to know what hardware key codes qwertz/German keyboard is supposed to emit. For example, the key to the right of zero is "ß". This, as far as I can tell, has no key defined in the kernel's input-event-codes.h. So what code does it use?
Perhaps it would be useful to connect a Bluetooth qwertz keyboard to discover all the key codes. If anyone wishes to try this, you should be able to run "getevent" in an adb shell to see the keycodes. Note you cannot run "adb shell getevent", you must run "adb shell" and then at the prompt run "getevent". You will see four events for each key press and release: (1) key press, (2) sync, (3) key release, (4) sync. For example, press and release for qwerty "-" shows:
/dev/input/event3: 0001 000c 00000001 <= Key code 000c, key press
/dev/input/event3: 0000 0000 00000000
/dev/input/event3: 0001 000c 00000000 <= Key code 000c, key release
/dev/input/event3: 0000 0000 00000000 -
Is this an accurate picture of the qwertz variant?
-
Okay all, I finally found some time to look at this some more. As it turns out, the xbl partitions are not actually being written by the current package due to a bug in the programming instructions. Or, well, a mismatch between what the programming instructions say and what my program expects it to say.
Anyway, I'll fix this and have a new package up shortly. This should be able to fix the currently bricked devices (I know there are at least two out there at the moment).
-
11
-
-
25 minutes ago, elvissteinjr said:
So if I got that right, the fn key state doesn't have to be hidden for this to work, correct? If no fn mapping is set in the active kcm file, there should be no drawback from having fn be down during the synthesized key press. In theory, at least.
I do have some doubts about switching between standard layouts to be practical at all even with this (physical layout just doesn't match up), but behaving closer to a PC QWERTY keyboard will probably be beneficial indeed.
QWERTZ does have yellow characters on other keys, including letter keys. Having proper fn key state will probably be required to map that correctly.That is probably correct. But if I passed the fn keys through, I would consider hiding them until another key is pressed. If that other key does not have a yellow mark, pass the fn press and then the other key press. In this way, the fn key is never seen as down unintentionally.
-
4 minutes ago, netman said:
Finqwerty just provides a bunch of .kcm files to android via an API. Where I imagine that could become difficult is that currently there are mappings that use fn-key combinations that are not any fn-key combination on the physical print, if the driver absorbs the fn key events there would be no way to remap those combinations in userspace I guess.
A possible solution would be to provide an extra extra physical layout on the driver level as suggested for qwertz, where fn is a normal key and the user can figure out how to use it.
Yes I could certainly add an option to pass the fn key through. Which would basically mean behaving like the stock keyboard. Or pretty much anything else that is desired.
Oh, this reminds me. You probably already know this but others here may not. The two shift keys only generate a single key. That is, the left and right shift key are indistinguishable at the hardware layer. Same with ctrl. But the fn keys are distinct -- you can tell the left from the right. I don't know how this affects alternate keyboard layouts, but I though I'd mention it.
-
1
-
3
-
-
1 hour ago, netman said:
Won't this make handling different physical layouts like the qwertZ version of the phone and having custom mappings such as with finqwerty more difficult?
I have not yet considered how to support qwertz, nor do I know how the OEM has implemented it yet. Ideally the kernel would be able to detect the qwertz hardware and take care of the mappings internally. But if that is not possible, I can implement a setting to change the physical keyboard layout and provide an option under the settings menu.
I've never used finqwerty. But with my new keyboard driver, the keyboard will act exactly like a normal keyboard. So I think finqwerty should behave exactly the same way on the physically attached keyboard as it does on a Bluetooth keyboard. Is that difficult?
-
4 hours ago, SteffenWi said:
Could you test and verify that selecting a different language setting in the Android settings / FxTec physical Keyboard thingi does change what characters appear on screen? Because, as described in my issue report, currently changing that setting doesn't do anything.
I don't think the language setting affects the keyboard. But if I select "German" for the keyboard layout, the characters on the keyboard change. For example, the Y and Z keys are swapped -- pressing the physical "z" key generates "y", and pressing the physical "y" key generates "z".
-
1
-
-
4 hours ago, skrilax said:
So how bad is IMS support on Lineage when it comes to Qualcomm nowadays? I remember (back from a few years back) that Qualcomm BSP wasn't as bad to get VoLTE etc. up unlike on Samsung.
I really don't know about IMS support. All I've ever cared about on my phones was basic GSM service (voice, SMS, MMS, and data). But the proprietary file list (which was stolen from the 1+5/5t) has an entire IMS section, so I would hope it works:
-
1
-
-
Been playing around with the new keyboard driver and it's working quite well. The only issue I've found that makes it behave differently from a regular keyboard is that the shift-key-unshift sequence breaks key repeat. I will look into deferring the unshift until the fn key is released to fix that.
-
2
-
5
-
-
Sorry for the delay the last couple of days. I have been playing around with the keyboard driver because I really hate the way that idealte did the keyboard logic. It is, from my perspective, a gross hack that needs to go away.
Background: the bulk of the keys are handled by the aw9523b keyboard driver. But the shift, ctrl, alt, fn (yellow arrows), and "fancy f" (aka. fxtec key) are wired up as gpio pins separately. The easiest way for the oem to deal with this was to map the yellow fn keys in userspace. It's a bit difficult to explain, so here's an example of how it works: when you press fn+p, userspace doesn't see "/", it sees fn+p. The oem used the Android keyboard mapper to map fn+p to "/". But this apparently only works when using the default keyboard layout, which is why switching away from the default to a typical layout like, say, "English (US)" in my case, breaks that mapping.
Fortunately, the keyboard gpio pins for shift/ctrl/alt/fn/fxtec are handled in the aw9523b driver file, so it's easy to hack on it. I'm changing the logic to the following, more or less:
The fn keys are not reported directly. The state of the fn keys are tracked as a variable. The shift keys are reported and also tracked. When one of the "normal" aw9523b keys are pressed, the fn state is checked:
* If no fn key is pressed, proceed as normal. This means eg. shift+2 generates "@" as expected (currently it does not).
* If a fn key is pressed, consult a different keymap. This keymap has a "force shift" flag. If the force shift flag is set and no shift key is currently pressed, it will synthesize a shift press followed by the key and then a shift release. So pressing fn+2 gets reported as shift, 2, unshift, which is interpreted in userspace correctly as "@". As a bonus, I've also mapped fn+up/down to pageup/pagedown, fn+left/right to home/end.
So the end result is that the keyboard acts like a normal keyboard with no userspace keyboard mapping file. You can select whatever layout you wish and it works normally.
Also, I must credit @netman for his work on the keyboard driver. Without his updated driver, it would have taken me much longer to unravel the keyboard logic.
I'll be testing this as I do other things and it should show up in the next Lineage build.
-
1
-
8
-
-
1 hour ago, silversolver said:
So the million dollar question then becomes what exactly is it that the stock ROM supports that the LOS ROMs universally ignore that causes this behavior? Obviously workarounds exist, but full functionality is better. Perhaps @tdm can comment on this, but honestly this sounds like a low-priority question, let alone project. If the entire LOS community so far has ignored this aspect of the devices, there's either a licensing issue, driver issue, or apathy issue, which is of course possible since most major networks aren't forcing the issue on VoLTE yet, so it's a whatever. However it is, I imagine it will be some time before this is addressed, and it sounds like possibly a much larger undertaking than what's being done here already, for not much reward, at least until carriers start forcing the issue generally.
Well, a full answer to that question would be quite lengthy. The brief overview is that there are different parts of the (cell) radio stack and certain parts are subject to vendor changes while others are not. Generally speaking, Google and Qualcomm rarely agree on things outside basic things in the system and will implement them in different ways. This leads to AOSP hardware support for Qualcomm devices (eg. used in Nexus/Pixel) having one set of code while the Qualcomm BSP code is different. This is most apparent in things like advanced audio (compression, offloading) and the radio stack. VoLTE has pieces in both of these. Lineage tries to support both, but sometimes one implementation must be chosen or preferred over another. Further, VoLTE is mainly used in India and when trying to use a GSM-only phone on a CMDA/LTE network. I don't know any Lineage developers that use it, so it kind of gets neglected. Combine these two and you have a broken and unsupported feature.
-
5
-
-
20 minutes ago, mcdinner said:
I'll wipe again and recheck, just to be sure.
Yeah it seems broken here also. I must have broken it yesterday, possibly with my audio prop change. I'll get that fixed and the fingerprint data fixed for Monday.
-
1
-
4
-
-
1 hour ago, mcdinner said:
Also wiped. But it's a good test what titanium backup is capable of. :)
Is there a wipe needed when it gets official? Signing key changes or something.
BT Audio is still broken for me.
Soft keyboard works as normal.Yes the signing keys change for official but there is a simple way around wiping for that.
I'll check BT audio again, but it's been working for me since I built the vendor image myself.
-
1
-
-
Alright after all the issues, I have flashed the "official" test3 zip on my device and wiped data. It works perfectly fine.
@SteffenWi have you figured out the virtual keyboard issue? It works fine for me, from the very start when asked for a PIN on the lock screen. I just need to press the keyboard icon on the right side of the navbar and select "Show virtual keyboard". (I will try to make this the default in the future).
-
1
-
-
I suspect something with the built vendor image is different than the stock vendor image. @Gigadoc2 mentioned a few posts back that he had to wipe after the switch, and I guess we now have two people that have confirmed it.
I'm sorry for that, wiping data is usually not necessary -- even in the test stage. It should not be necessary again.
-
1
-
1
-
-
-
@skrilax
I've put a userdebug zip in the server. It's not linked, just replace user with userdebug to get it.-
1
-
1
-
-
Can you adb in to recovery? You can edit build.prop and set adb on at boot to see the error in the log.
-
1
-
-
2 minutes ago, bmccrary said:
Is there anything specific to be done to update? I've tried several times but can't get it to boot. The Lineage recovery is saying the OS can't start and to do a factory reset but I have several hundred apps and GB of data already on the phone and would prefer not to if I can somehow get it to work. Reflashing test2 won't boot either at this point. The adb sideload completes without any problem.
No, that is strange. This usually happens when data fails to mount/decrypt. Had you previously been running test2?
Full disclosure: I didn't test this exact zip, I flashed one that I built on another machine. But it should be the same exact code. I can try this one later tonight or tomorrow if others also have problems.
-
2 minutes ago, D1ggs said:
@tdm Hey bud, I noticed you have a typo in your lineage os instructions on your site.
The command fastboot flash boot_a lineage-16.0-pro1-test2-boot.img
Shouldn't have the _ and should look like: fastboot flash boot lineage-16.0-pro1-test2-boot.img
I'm embarrassed to admit it took me way too long to figure out what the heck was going on. Maybe your version is different, but if someone else has this issue, this is what I did and it worked.
Actually boot_a works and I use it to be explicit. But test2 should be test3.
-
9 minutes ago, Gigadoc2 said:
Why is that stored in persist in the first place? Has it something to do with the FDE of stock? Though you'd always unlock before using Fingerprint anyway?
No way to tell. The fingerprint files are just tossed into the bsp as binaries. So only BetterLife (the fingerprint vendor) knows for sure.
Edit: yeah for FDE, data is decrypted long before the FP service starts.
LineageOS, Current status : 16.0 Test Builds
in Support
Posted
Forward looking.