LineageOS, Current status : 16.0 Test Builds

[EskeRahn 5,471]

1 hour ago, SteffenWi said:

Sorry, I don't understand what you mean by 'primarily shifted'? And it doesn't address what I can observe currently. If I press 'W' 'Q' appears on the screen, if I press 'R' 'E' appears on the screen and so on. Numbers are fine. (as in if I press '1' '1' appears).

First: Thanks to @VaZso for explaining it better than I did.

Let us look at it in a mechanical way: If you have no drivers loaded, and you press the third key in the first row you get a "2". If you press the key below it in the second row you get a "Q", no matter what is printed in that key.

That is what I mean by them being electronically identical. The Pro1 does not 'know' if it got the qwertY or the qwertZ print. And by default assumes qwertY

So if we want a "W" matching the qwertZ print, we need something that does this mapping, and that is what selecting "German" on the layout-list will do.

 

(By the " different (primarily shifted)" I meant that tough the most obvious difference between the two layouts is the shifted letter block, there are also other differences, e.g. the Z/Y swap)

[tdm 2,322]

Is this an accurate picture of the qwertz variant?

 

[EskeRahn 5,471]

15 minutes ago, tdm said:

Is this an accurate picture of the qwertz variant?

 

 

Yes.

To see what the layout actually produce selecting stock, @Anssi Hannula has added the stock layout for selecting nothing and selecting German here

Note that the Geman layout (currently, QX1000_EEA_20200106110245) has a few bugs, as it does not exactly match the yellow prints...

[tdm 2,322]

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

 

[Craig 1,435]

I think the keycodes for the two oem keys shouldn't be the same in kernel, that would be a limitation.   For example, I wouldn't mind being able to change just the right one into slash/questionmark, and keeping the left one as a modifier (ideally make it right alt (100), modify the layout files finqwerty for that change, and include them with los, for qwerty and qwertz).

Edited February 5, 2020 by Craig

[netman 1,424]

35 minutes ago, tdm said:

Is this an accurate picture of the qwertz variant?

The F and J key nubs have been corrected in production version though if I am not mistaken.

[EskeRahn 5,471]

2 minutes ago, tdm said:

 

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

 

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?

[EskeRahn 5,471]

1 minute ago, netman said:

The F and J key nubs have been corrected in production version though if I am not mistaken.

Correct, I overlooked that, sorry. looked at the prints only...

[tdm 2,322]

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.

 

[Polaris 423]

23 minutes ago, tdm said:

 

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?

If I'm following this correctly, it would be the same key code that is generated for the hyphen/minus in the QWERTY layout.

[EskeRahn 5,471]

8 minutes ago, Polaris said:

If I'm following this correctly, it would be the same key code that is generated for the hyphen/minus in the QWERTY layout.

Yes.

Actually when German is selected (or Using FinQWERY qwertZ layouts), The key is not mapped to a single key, but as "Alt"+"S". Similar tricks are used for other symbols... (checked with KeyEvent)

[VaZso 1,998]

48 minutes ago, tdm said:

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?

As of hardware key codes, that should use the same code as "-" key in standard layout.
(National layouts have always used the same key codes as standard US layout but included some special characters instead of original function, so like ";", "'" or "=" characters are replaced.)

The strange part of F(x)tec keyboard is for example that ";" character of QWERTY is located at the right side of "P" and it should have been at the right side of "L", however, it generates the same code as being the ";" key.

So on a QWERTZ device, the same key has "Ö" marking but located at the right side of "L" which is the original place of it but in QWERTY layout, that is the "L" key.
Also, on QWERTZ device, "Ä" character is on the appropriate key of "'".

Sorry for the complicated description. 🙂

The most important part is the scan codes of QWERTZ layout basically the same as the appropriate position of international US keyboard.
(Which is currently not true for Pro1 because of the shifted QWERTY as its default keyboard.)

[tdm 2,322]

I'm working on the changes to allow selecting qwertz in the kernel hardware key map. I should have something to test tomorrow.

 

[Polaris 423]

4 hours ago, VaZso said:

(Which is currently not true for Pro1 because of the shifted QWERTY as its default keyboard.)

I'm enjoying most aspects of the Pro1, but I really dislike (this is putting it mildly) the shifted keyboard.  Or maybe "shifted keyboard" is the wrong phrase, as I unshifted it (so to speak) via remapping, and then didn't like the extra keys that were on the right.  I'm very spoiled because I have been using a Droid 4 for so many years that it (D4) just makes sense, feels natural, and I can thumb-type full paragraphs (even pages if need be) without looking down at the keyboard.  This is mostly because when I grab it to being typing, without looking, my thumbs just naturally fall right onto the F and J keys.  Then everything else just naturally follows suit.  After weeks of using the Pro1, I still can't pick it up and start typing (with any accuracy) without looking at the keyboard and my thumb's initial positioning.  Even then after I get everything aligned and start whizzing away, my left hand always ends up off the home row keys within a short time period, and everything gets all fouled up to the point that the process (of relooking, and realigning) needs to start all over again.  I guess I never really realized how much I've been rapidly, and accurately, typing without looking at my hands or the keyboard!!

[VaZso 1,998]

4 hours ago, Polaris said:

I'm enjoying most aspects of the Pro1, but I really dislike (this is putting it mildly) the shifted keyboard.  Or maybe "shifted keyboard" is the wrong phrase, as I unshifted it (so to speak) via remapping, and then didn't like the extra keys that were on the right.  I'm very spoiled because I have been using a Droid 4 for so many years that it (D4) just makes sense, feels natural, and I can thumb-type full paragraphs (even pages if need be) without looking down at the keyboard.  This is mostly because when I grab it to being typing, without looking, my thumbs just naturally fall right onto the F and J keys.  Then everything else just naturally follows suit.  After weeks of using the Pro1, I still can't pick it up and start typing (with any accuracy) without looking at the keyboard and my thumb's initial positioning.  Even then after I get everything aligned and start whizzing away, my left hand always ends up off the home row keys within a short time period, and everything gets all fouled up to the point that the process (of relooking, and realigning) needs to start all over again.  I guess I never really realized how much I've been rapidly, and accurately, typing without looking at my hands or the keyboard!!

I am happy with unshifted QWERTZ, however, I don't like CTRL being Strg and I would much happier with unshifted QWERTY (as I don't think my national layout will ever come up as an option).

Otherwise, those extra keys are very good for using international layouts as they may also contain meaningful letters instead of special characters like in intl. US layout.

[david 929]

On 1/25/2020 at 12:31 PM, tdm said:

If the hardware fails to the point that you cannot decrypt using the Android scheme, how do you expect to extract unencrypted data? And don't say backups, because backups can be made in both cases (TWRP will happily decrypt and backup).

Is this forward looking to when we have a TWRP that can decrypt, or is there currently a version of TWRP that can decrypt?

[Polaris 423]

1 hour ago, VaZso said:

I am happy with unshifted QWERTZ, however, I don't like CTRL being Strg and I would much happier with unshifted QWERTY (as I don't think my national layout will ever come up as an option).

Otherwise, those extra keys are very good for using international layouts as they may also contain meaningful letters instead of special characters like in intl. US layout.

You can easily convert Strg to Ctrl if that's your main concern with the QWERTZ layout.

Yes, I personalized my comment because I use a English US layout.  I can see how if I were using an international version those extra keys would be handy for extra letters and whatnot.  However, they are unnecessary in my case (especially when they didn't take advantage of all the keys anyway, so many wasted ones).

So can you pick up the Pro1 and blindly type (meaning without looking at your fingers/thumbs, or the keyboard) with any accuracy, and for multiple sentences?

Edit: @david No current TWRP version that can do much of anything, let alone decrypt.

Edited February 6, 2020 by Polaris

[SteffenWi 139]

12 hours ago, EskeRahn said:

Yes.

To see what the layout actually produce selecting stock, @Anssi Hannula has added the stock layout for selecting nothing and selecting German here

Note that the Geman layout (currently, QX1000_EEA_20200106110245) has a few bugs, as it does not exactly match the yellow prints...

So the Pro1 keyboard works the same as every other laptop keyboard 'out there'. In which case I'm again stumped as to what makes this not 'just work'.

[VaZso 1,998]

9 minutes ago, Polaris said:

You can easily convert Strg to Ctrl if that's your main concern with the QWERTZ layout.

It is only a cosmetic issue and there are other characters which are different (even Ö, Ü characters are at different places, we have no Ä character but Á, no ß character and so on).

Moreover, I use US layout while I can access national characters by fn modifier key.

14 minutes ago, Polaris said:

So can you pick up the Pro1 and blindly type (meaning without looking at your fingers/thumbs, or the keyboard) with any accuracy, and for multiple sentences?

I haven't really tried to use it that way.
Usually I look at the keyboard but I don't have to look constantly on it...

[VaZso 1,998]

2 minutes ago, SteffenWi said:

So the Pro1 keyboard works the same as every other laptop keyboard 'out there'. In which case I'm again stumped as to what makes this not 'just work'.

I think it "just works" - at least for QWERTY layout if you not select a specific layout.
Specific layouts may also work.

However, yellow-labeled keys should have some configurations because basically they are not necessarily there where they are written.

For QWERTZ layout, keys should be remapped if lower level drivers are unmodified.

[EskeRahn 5,471]

1 hour ago, Polaris said:

You can easily convert Strg to Ctrl if that's your main concern with the QWERTZ layout.

"Strg" is a VISUAL issue, it is printed on the key (Short for "Steuerung" that is the German word for "Control" - related to the word "Steering" in English)

[EskeRahn 5,471]

46 minutes ago, VaZso said:

I think it "just works" - at least for QWERTY layout if you not select a specific layout.
Specific layouts may also work.

However, yellow-labeled keys should have some configurations because basically they are not necessarily there where they are written.

For QWERTZ layout, keys should be remapped if lower level drivers are unmodified.

There are a few oddities as currently only two layouts are really supported. US qwertY selecting NO boxes, and German selecting German.

It would have helped the confusion if they added a new say "Pro1 English (US)" to the list), so it fell back to the stock layout (similar to the "None" by FinQwerty)

Alternatively they could change the .kcm for "English (US)" to doing nothing. Just like they changed the standard German to fit the qwertZ print.

All(?) the other standard Android layout also needs minor adjustments to be really good on the Pro1. But I guess they simply have not gotten round to it yet.

Perhaps they could do something to have the community suggest the .kcm modifications needed. Like Github pull requests...
A very good place to start would be to pull the great work of @Anssi Hannula in FinQwerty!

Perhaps we should move this whole debate into a Keyboard thread, as it is not limited to Lineage, and would preferable be done stock, and then transferred to the Lineage build...

[Polaris 423]

1 hour ago, VaZso said:

It is only a cosmetic issue and there are other characters which are different (even Ö, Ü characters are at different places, we have no Ä character but Á, no ß character and so on).

 

15 minutes ago, EskeRahn said:

"Strg" is a VISUAL issue, it is printed on the key (Short for "Steuerung" that is the German word for "Control" - related to the word "Steering" in English)

Thanks for the clarifications.  Personally, I could care less about what's printed on the actual key (in cases such as this where it would say either Ctrl or Strig) as long as the functionality is the same.  Clearly, if all the symbols were in non-standard locations and were all swapped, then it would be a different story.

 

1 hour ago, VaZso said:

I haven't really tried to use it that way.

Usually I look at the keyboard but I don't have to look constantly on it...

I think this is where we differ.  As I mentioned, I didn't realize that I have been blind typing so much so often (at least not until I started trying to use the Pro1 in the same manner).  I can easily type full paragraphs without looking at my thumbs/fingers or the keyboard; instead, I find that I'm looking at something completely different (while multitasking), or that I'm focused on the screen (such as how I use a computer).  This is by far the biggest issue with the Pro1 for me!  Whereas I find opening it effortless, and even natural, regardless of if it's with one hand or two.

[VaZso 1,998]

34 minutes ago, Polaris said:

I think this is where we differ.  As I mentioned, I didn't realize that I have been blind typing so much so often (at least not until I started trying to use the Pro1 in the same manner).  I can easily type full paragraphs without looking at my thumbs/fingers or the keyboard; instead, I find that I'm looking at something completely different (while multitasking), or that I'm focused on the screen (such as how I use a computer).  This is by far the biggest issue with the Pro1 for me!  Whereas I find opening it effortless, and even natural, regardless of if it's with one hand or two.

Usually when I am working at a PC keyboard, I am not even look at the keyboard itself.

The phone is a bit different story as it is much smaller and not something which I use the whole day but when a PC is not available.
...and I feel Pro1's QWERTZ keyboard is comfortable especially because it has the same layout as a PC.

[tdm 2,322]

5 hours ago, david said:

Is this forward looking to when we have a TWRP that can decrypt, or is there currently a version of TWRP that can decrypt?

Forward looking.