pro1x I got the Pro¹ X in the mail earlier this week and I need help

[Adamyno 13]

The speaker seems fine to me. However, the mobile data connection fluctuates continuously even where the signal level is stable with other devices.

To solve keyboard problems, I recommend AnySoft Keyboard with its accessory (Hungarian for AnySoft keyboard for me).

The Hungarian keyboard differs from the English one in many places, e.g. not qwerty but qwertz and there are many accented characters. AnySoft keyboard has the option of qwerty-Hun keyboard assignment. Thus, the basic keyboard layout matches the hardware. Accented characters can be entered as, e.g. if I want the letter "á", I press the "a" button 2 times in a row. If I want more similar letters, I have to press it several times. In Hungarian, "a" has only 1 accent, but there are, for example, "u","ú","ü","ű". This is 1, 2, 3 or 4 key presses in rapid succession. This is probably the best solution. That way, I don't have to hold down any special modifier keys (and I'm afraid that the device will fall out of my hands in the meantime), I just press the same button several times.

[JECE 24]

2 hours ago, Adamyno said:

The speaker seems fine to me. However, the mobile data connection fluctuates continuously even where the signal level is stable with other devices.

To solve keyboard problems, I recommend AnySoft Keyboard with its accessory (Hungarian for AnySoft keyboard for me).

The Hungarian keyboard differs from the English one in many places, e.g. not qwerty but qwertz and there are many accented characters. AnySoft keyboard has the option of qwerty-Hun keyboard assignment. Thus, the basic keyboard layout matches the hardware. Accented characters can be entered as, e.g. if I want the letter "á", I press the "a" button 2 times in a row. If I want more similar letters, I have to press it several times. In Hungarian, "a" has only 1 accent, but there are, for example, "u","ú","ü","ű". This is 1, 2, 3 or 4 key presses in rapid succession. This is probably the best solution. That way, I don't have to hold down any special modifier keys (and I'm afraid that the device will fall out of my hands in the meantime), I just press the same button several times.

Thanks for the tip! Is this the keyboard that you're talking about?

https://anysoftkeyboard.github.io/

I haven't tried mobile data yet. Given all the other problems, I wasn't about to pop my SIM card over.

[JECE 24]

5 hours ago, EskeRahn said:

I'm pretty sure that the popping sounds are related to the clipping, so no clipping means no popping I tried it with some talk radio, and gone at max vol, and on the other hand when the level is below about 50% all sounds (including pops) seems completely gone from the right side/bottom speaker

So now at least three of us have this issue . . .

I had to look up clipping. How could that be the cause if it sometimes works more or less OK with the volume up?

I wish that there was a way to just disable the bottom speaker. I've been getting by just fine without stereo on my KEY².

[EskeRahn 5,399]

1 hour ago, JECE said:

So now at least three of us have this issue . . .

I had to look up clipping. How could that be the cause if it sometimes works more or less OK with the volume up?

I wish that there was a way to just disable the bottom speaker. I've been getting by just fine without stereo on my KEY².

First of I can confirm that the bug is not ALWAYS there - I have no idea what triggers it....

Yes I agree, Mono would do just fine for me too. Turning down the volume sort of do that IF the source is Mono. But if the source is Stereo we get only one channel so not a too good workaround.

The big question is what is going on, and how they can fix it....

A wild guess is that it could be related to some circuitry intended to avoid feedback-looping between mic and speaker during calls. Obviously it should not be active during ordinary playback. Just my wild guess though.....
 

[VaZso 1,997]

5 hours ago, Adamyno said:

Accented characters can be entered as, e.g. if I want the letter "á", I press the "a" button 2 times in a row.

Personally it is not convenient for me (and even there are letters like u/ú/ü/ű), so I set up another layout using the slant arrow which is basically functions like an AltGr for me at both sides (of my Pro1).

[Adamyno 13]

20 hours ago, JECE said:

Thanks for the tip! Is this the keyboard that you're talking about?

https://anysoftkeyboard.github.io/

I haven't tried mobile data yet. Given all the other problems, I wasn't about to pop my SIM card over.

Yes, this is.

[aquaz 41]

On 8/12/2022 at 5:27 PM, VaZso said:

Personally it is not convenient for me (and even there are letters like u/ú/ü/ű), so I set up another layout using the slant arrow which is basically functions like an AltGr for me at both sides (of my Pro1).

I'd like to do something similar - how did you do that?

[VaZso 1,997]

1 hour ago, aquaz said:

I'd like to do something similar - how did you do that?

Basically, I have 'modified' finqwerty (added a new layout which is my own keymap).
That makes possible to switch keymaps using system default solution.

I don't know about Pro1X's actual keyboard driver but theoretically it also supports loading specific keymaps.

[aquaz 41]

Heyyy it works. Thanks

[JECE 24]

On 8/12/2022 at 12:11 PM, Adamyno said:

The Hungarian keyboard differs from the English one in many places, e.g. not qwerty but qwertz and there are many accented characters. AnySoft keyboard has the option of qwerty-Hun keyboard assignment. Thus, the basic keyboard layout matches the hardware. Accented characters can be entered as, e.g. if I want the letter "á", I press the "a" button 2 times in a row. If I want more similar letters, I have to press it several times. In Hungarian, "a" has only 1 accent, but there are, for example, "u","ú","ü","ű". This is 1, 2, 3 or 4 key presses in rapid succession. This is probably the best solution. That way, I don't have to hold down any special modifier keys (and I'm afraid that the device will fall out of my hands in the meantime), I just press the same button several times.

I can't figure out how to reproduce this behavior. I haven't tried the Hungarian keyboard, but the Spanish keyboard layouts don't seem to have an effect on the physical keyboard. All I notice is that spellchecking on Spanish became terrible, with almost half of a typical paragraph underlined in red. I did notice a setting buried within the app to disable key repeat. This worked, but it also disabled key repeat for the backspace button. In any case, simply disabling key repeat doesn't make it any easier to type accented characters.

[suicidal_orange 100]

On 8/14/2022 at 3:26 PM, VaZso said:

I don't know about Pro1X's actual keyboard driver but theoretically it also supports loading specific keymaps.

Is the keyboard driver open source, or at least documented?

Given the number of requests for layouts already (which I will probably add to if I get my fingers on my Pro1X and like it) with most devices not even shipped it seems work is required to make customising easier, and putting it in the driver would fix Android, Lineage and Sailfish all at once so seems the way to go.  Completely customisable keyboard firmware exists in the mechanical keyboard world (tmk being the first and least bloated) and it's in C so although written for AVR much of the scanning and mapping code should be reusable.  Just thinking out loud, it's been many years since I touched C and I've no idea how Android kernels work.  Would be a good time to relearn though.

Edit:  Had a look around and found a file list on an old fxtec blobs github and there are no layouts listed in the keyboard section, but

7 hours ago, JECE said:

the Spanish keyboard layouts don't seem to have an effect on the physical keyboard.

makes it sound like the layout isn't handled in software either.  Unless it's using their own app outside the on screen keyboard?  It's a good idea as I may want a different layout if I have to use the touchscreen keyboard.

Edited September 9, 2022 by suicidal_orange

[VaZso 1,997]

1 hour ago, suicidal_orange said:

Is the keyboard driver open source, or at least documented?

The keyboard handler code (kernel module) for Pro1 of LineageOS is open source.
I doubt they have changed anything related in Pro1X anyway (I mean in hardware).

...but that is the low level handling code which has nothing to do with layouts (except it has a feature to export different key codes on pressing yellow arrow for example) but it is also not necessarily the same code used in stock OS of Pro1X.

Otherwise, after having appropriate key codes for key presses, layouts should be handled in OS level (Android part).

[claude0001 1,271]

1 hour ago, suicidal_orange said:

putting it in the driver would fix Android, Lineage and Sailfish all at once so seems the way to go

Afaik, the keyboard is the same than the Pro1's. That one's driver is open-source, and all versions of LineageOS for the Pro1 have a key-remapping interface. I would assume those bits will get ported to the Pro1X's Lineage.

[suicidal_orange 100]

5 minutes ago, VaZso said:

The keyboard handler code (kernel module) for Pro1 of LineageOS is open source.

...

that is the low level handling code which has nothing to do with layouts (except it has a feature to export different key codes on pressing yellow arrow for example)

I thought it should be, and I see no reason they'd reinvent the wheel for the X. 

It depends how you define a layout - if I want to put backspace on caps lock (great on a full size keyboard, not so much on a phone) that's not a language-layout which should be handled by the OS but it is a keyboard-layout.  It would be good to change what the yellow arrow does as there are many keys with no second use - holding arrow and having numbers 1-9 in a 3x3 block on the other hand would be nice, for example, and as I understand it this is not possible with the current setup where the yellow arrow is handled at a different level. 

Double/triple/quad tap for all Hungarian "U"s on one key would need to send two different keycodes in standard and shifted states, though the second "U" key should be available using the \| key next to Caps lock looking at the pics of the QWERTY layout on Fxtec's site - though obviously this is going to take some serious reprogramming of muscle memory.

[JECE 24]

12 minutes ago, claude0001 said:

Afaik, the keyboard is the same than the Pro1's. That one's driver is open-source, and all versions of LineageOS for the Pro1 have a key-remapping interface. I would assume those bits will get ported to the Pro1X's Lineage.

Unfortunately, that does not seem to be the case. I don't have a Pro¹, but from messages posted in this thread it seems to have supported sticky shift and from the website it seems to have supported keyboard shortcuts. It's as if I'm using the same keyboard driver on my Pro¹ X as what you might find on a Chromebook (in other words, a driver not designed for thumb typing).

[claude0001 1,271]

Also for the Pro1, the Lineage driver was completely rewritten with respect to Stock. I have always only used Lineage and that one indeed supported sticky shift. As far as I am being told, that is a high level Android feature though, and has nothing to do with the actual device driver ("qx1000.c"). I am pretty confident all those things can be changed once we get a Lineage port ... 

[JECE 24]

1 hour ago, claude0001 said:

I am pretty confident all those things can be changed once we get a Lineage port ... 

Too late for me, though . . .

My BlackBerry KEY² got stuck in a boot loop a couple weeks ago on the same day that I had to go on an international trip, so I had to switch over and use my Pro¹ X as my daily driver

[suicidal_orange 100]

Just now, JECE said:

Too late for me, though . . .

My BlackBerry KEY² got stuck in a boot loop a couple weeks ago on the same day that I had to go on an international trip, so I had to switch over and use my Pro¹ X as my daily driver

If you must let Google track you for a while best do it while you're doing something random - when you come home you can put sailfish on it?

[VaZso 1,997]

2 hours ago, suicidal_orange said:

I thought it should be, and I see no reason they'd reinvent the wheel for the X. 

They haven't reinvented the wheel - kernel module is handling the keyboard matrix through an IO expander IC (aw9523b) and reporting keypresses to kernel.
Most of the keys are handled through that expander while there are a few modifier keys which are handled directly - it is important because matrix arrangement also causes problems decoding multiple keypresses at once.

2 hours ago, suicidal_orange said:

It depends how you define a layout - if I want to put backspace on caps lock (great on a full size keyboard, not so much on a phone) that's not a language-layout which should be handled by the OS but it is a keyboard-layout.

There is a physical layout what kernel module handles (assigning scan codes to keypresses) and a logical layout which assigns scan codes to letters / numbers /etc.

When I have switched to LineageOS, I had some confrontation about what features the kernel module should have, I have even modified kernel module and some Android parts to show what I am thinking of... some of the ideas were programmed but as far as I know, some are still missing, like I wanted the yellow arrow key to also generate a scan code (as similar keys usually do on a regular PC, allowing the higher level OS to handle these functions) but the basic idea was an option for yellow arrow to generate completely different scan codes and handling it similarly as an Fn key was out of scope (also as an option).

Finally, two interfaces of kernel module were built - one is the scan codes of regular keypresses and the other is the scan codes of key+yellow arrow keypresses.
(These can be loaded to kernel module through this interface in sysfs.)
As far as I remember well, an option for generating scan codes of pressing yellow arrow was never implemented in official LOS driver although that was why I have started modifying kernel driver and my demo had that feature... I have completely gave up working on keyboard module at this point (also I mostly regretted I have even started doing anything inside).

At my side, I have modified Finqwerty for my custom layout in order to use accented characters - that was working well using stock OS of Pro1 but it was not working well using LOS and that was the reason I have started digging into lower level parts...
Now I am using a custom Finqwerty on LineageOS which works well anyway using latest version of kernel module.

3 hours ago, suicidal_orange said:

Double/triple/quad tap for all Hungarian "U"s on one key would need to send two different keycodes in standard and shifted states

Basically pressing a key should send a scan code to OS and OS should find an appropriate key for that code - that is what keyboard layouts do.

For example, a Hungarian keyboard has 0123456789Ö at top row while US keyboard has ~1234567890 but top row of keys are still producing codes of 41,2,3,4,5,6,7,8,9,10,11.
So scan code of 11 produces 'ö' if you are using Hungarian layout but produces '0' if US layout is in use.
If shift (scan code of 54) is also pressed, then it should produce "Ö" sign using Hungarian layout.

Using standard layouts, ü,ű,ú keys are definitively having different scan codes (as these are independent keys of the keyboard).
If someone wants to produce them while pressing Fn+U, FN+I and FN+O, that should be handled at OS level, that is what keyboard layouts do --> it assigns a key (like ű) to a specific scan code... that way any letters (independently of upper/lowercase) may have different scan codes associated.

Instead of this, Pro1's LineageOS driver handles Fn internally, then associates a scan code described in its internal hardware layout and solves the same problem at "hardware level"...

Both solutions have a reason... while the former is the standard behaviour, a program may still handle keypresses using low-level scan codes while this can be eliminated using different hardware layouts in low level (kernel module) - that was the original idea of Pro1's LineageOS driver.
Mostly games or similar software may use low-level key handling while most of user applications are working with the result of software layouts, so also having a scan code for yellow arrow would be more important for custom national software layouts anyway...

Otherwise, I had the very same problem with writing áéíóöőúüű characters and I am using a very non-standard key arrangement. 🙂

3 hours ago, claude0001 said:

As far as I am being told, that is a high level Android feature though, and has nothing to do with the actual device driver ("qx1000.c").

Right, that is an Android feature.

[suicidal_orange 100]

11 minutes ago, VaZso said:

For example, a Hungarian keyboard ... standard layouts, ü,ű,ú keys are definitively having different scan codes

You're right - first thing in the morning I "only" saw two U keys on the Hungarian keyboard when really there are 4!  Looks like two of them are on the wrong side of the Pro1's keyboard but at least they're not hidden behind the yellow arrow (Shift+Arrow+[key] is not thumb type-able)

I'm hoping to use Ubuntu on mine so no idea what the keyboard options will be, your work sounds promising so I may well ask for a copy 🙂

[VaZso 1,997]

6 hours ago, suicidal_orange said:

You're right - first thing in the morning I "only" saw two U keys on the Hungarian keyboard when really there are 4!  Looks like two of them are on the wrong side of the Pro1's keyboard but at least they're not hidden behind the yellow arrow (Shift+Arrow+[key] is not thumb type-able)

The QWERTY version of Pro1 had a modified keyboard layout where non-alphanumeric keys were arranged differently (like "\", "[", "]", "`", etc), this is why we called it shifted QWERTY.
As I did not like this mixed-up keyboard layout and in Europe, I had an option to order my Pro1 with QWERTZ layout instead, I went to that direction.
So QWERTZ layout of Pro1 is closer to a normal QWERTY keyboard than its shifted QWERTY version itself.

If we are speaking about Pro1X, F(x)tec has dropped this shifted QWERTY solution and went for standard QWERTY instead, so it is much more international having all keys in the right place and there is no need to re-train yourself for shifted QWERTY positions.

So, these characters are no longer in wrong positions, however, as far as I remember well, there was a character which was missing - I think position of "Ű" alias upper-right "\" does not exist while position of "Í" alias lower-left "\" exists - and it also explains why that button was skipped and why shifted QWERTY was a bad idea for multilingual use.
So Ű (scan code of 43) and Í (scan code of 86) looks to be identical using US layout ("\") but still have different scan codes and they were used differently on international keyboards.

6 hours ago, suicidal_orange said:

(Shift+Arrow+[key] is not thumb type-able)

This case I use "Caps Lock", then yellow-arrow + char, then "Caps Lock" again as yellow arrow is not sticky and it cannot be sticky if it remains hidden for OS (however, I don't know how simple is to have a further sticky modifier in case yellow arrow were not hidden).

I rarely have to use this double-caps lock thing as accented starting characters of sentences are statistically lower than not accented starting characters. 🙂

6 hours ago, suicidal_orange said:

I'm hoping to use Ubuntu on mine so no idea what the keyboard options will be, your work sounds promising so I may well ask for a copy 🙂

I am using a modified version of Finqwerty which basically means I have added a custom descriptor file and removed its original layouts, then renamed it slightly but that is a high-level (Android) solution.

Also, I use a US-based layout and reaching accented characters using yellow arrow and their positions are also different than standard layout. 🙂

However, under Ubuntu, you will have a kernel module for keyboard handling (most likely the same module what was written for Pro1) and you may write your own high-level keyboard mapping using Linux tools.
Under Debian (on my notebook), I am also using a bit modified layout with the help of xkbcomp...

Otherwise, modifying the keyboard module to expose yellow arrow would be very easy, simply it does not worth doing it only for yourself and managing to be built every time a new kernel may arrive, that is why I wanted to add that feature in official build (I don't need different hardware layouts of yellow arrow at all but a modifier key would be important).
I didn't think I will not be able to explain its importance to be understood and it will not go through because of the different conception of arrow key, even though they would have been live together as an optional feature.

However, I have not looked into that code since then at all to see if it was implemented so far, but I doubt - I was tired of it.

Edited September 9, 2022 by VaZso

[Sean McCreary 328]

On 9/9/2022 at 8:49 AM, VaZso said:

Otherwise, modifying the keyboard module to expose yellow arrow would be very easy, simply it does not worth doing it only for yourself and managing to be built every time a new kernel may arrive, that is why I wanted to add that feature in official build (I don't need different hardware layouts of yellow arrow at all but a modifier key would be important).

This feature was added to official builds for the pro1 in Nov 2021 with this change:

https://github.com/LineageOS/android_kernel_fxtec_msm8998/commit/a340af4b4e360d11cd53d7ad199950faac344b78

It supports remapping the yellow arrow keys to any Linux key event code, but doing so prevents them from triggering the alternate keymap in the kernel. You can remap them both to AltGr and just ignore the kernel 'keymap shift' feature entirely. In fact, I used this feature to add the layout mod that makes the left yellow arrow key AltGr without requiring a custom keymap:

https://github.com/LineageOS/android_device_fxtec_pro1/commit/ba2cad006b93d1eff2c0c264ef765f369dd554a0

I have also added the key remapping feature to the stock kernel driver, and you are welcome to try any of the keyboard beta test OS images which include this change. Please read the README.md file in that folder for details.

[VaZso 1,997]

4 minutes ago, Sean McCreary said:

It supports remapping the yellow arrow keys to any Linux key event code, but doing so prevents them from triggering the alternate keymap in the kernel. You can remap them both to AltGr and just ignore the kernel 'keymap shift' feature entirely. In fact, I used this feature to add the layout mod that makes the left yellow arrow key AltGr without requiring a custom keymap:

If I remember well, I had a problem of remapping it as FN key like it was in stock Android but I have not checked actual keyboard driver's functionality or source code.
Sorry if I am a bit unclear, I have just arrived home and it is nearly 3AM and left home a bit after 7AM in connection with a project coming deadline.

I hope I will have a bit more time to check it and also some time for Pro1X... a bit later...