VaZso

Right - connection speed is good but it only uses one core out of eight; okay, virtual eight. 🙂

You are right but although it is not practical, it doesn't bother anybody. 🙂 Hehe, I was thinking of I have used it before... err, yes, there is a dedicated alt key there. 😄 Anyway, it takes a while for the repository in docker image to synch / come up.

It looks good while both can be defined in .kcm file. However, that would be a bit deeper modification than what I thought to be necessary to at least keep the same functionality what worked in stock OS. Anyway, it can also be done following the scheme what @tdm has done. ...but would you use the separation of fn keys for anything?

It may happen also ctrl buttons are wired together, but it isn't a huge problem compared to loosing all of the FN functionality. ...and that is a hardware limitation which can not be improved like software limitation. 🙂 Edit: Anyway, there are reserved locations in keyboard driver (I mean in the buttons representation), I don't know what they are exactly - it would be good to have the hardware wiring to find it out easily or to see why they are in the row.

Seriously it worked really well for me under stock OS - I took the project what @Anssi Hannula has created (finqwerty), removed all the layouts from it and only installed two custom layouts for me, but only one of them was in use on my Pro1. That was a custom build renamed to not conflict with original software which was also installed. Anyway, these kinds of custom layouts do not consume power resources like a special application would, these layouts are reachable in the same way like original layouts - absolutely a perfect solution which does not need root access but exactly works lik

I didn't say it is a bug. Anyway, I have tried to get QWERTZ variant to work with QWERTY keymap where I can also reach characters which is often used in my language and slant arrow was a perfect key to reach them as it exists on both sides. If it is an intended work of it, then it is a regression. It would be perfect and -ex variants should has the raw layout, without any remappings at driver level. However, the name of QWERTY can be a bit misleading if F(x)tec will publish non-shifted physical layout together with Pro1-X. Basically it is all about SHIFTED and NON-SHIFTED la

It works like this (in .kcm file): key W { label: 'W' base: 'w' shift, capslock: 'W' ralt: 'm' meta: 'p' alt: '\u0302' fn: '|' fn+shift, ctrl+fn, fn+capslock: '\u00c5' } You may define what key combinations should do what in a similar combinations like above (the above is just an example and not more). I was mentioning the keyboard if it would no

Do not expect much of waterproof rating. It has holes near speakers, I think also water can go in USB-C connector and also in headphone jack connector, maybe even near hinge mechanism. It does not support 5G network but it is 4G capable. Also, it may be hard to get it working because of service provider restrictions in the USA but some of the members could do it on some networks there.

Yes, there is a "bug" in QWERTZ variant as one value was mistyped and some of them exist twice in a row. Another problem is the missing AltGr flag on these keys (it also applies on QWERTY variant) and that is why these keys are basically non-remappable. My basic problem is I used a custom-made keyboard mapping on my Pro1 under stock OS and I have recently moved to LineageOS and realized I have no chance to setup the very same layout I used since I have my Pro1 as it has the problems above. On top of that, there is some kind of hardcoding which is another problem but also affects re

It seems only QWERTZ variant has mistakes (I have looked into it basically because I use that one) but QWERTY variant also does not add KF_ALTGR flag which makes impossible them to be remapped (not appears as ralt in which could be used in .kcm files). There are also the following keys hardwired in the driver: - For QWERTY: KEY_P --> KEY_SLASH KEY_L --> KEY_SLASH --> I think this one wanted to be a question mark which may be modified in a later revision (I remember it used to be a problem for some users) - For QWERTZ: KEY_W --> KEY_GRAVE KEY_APOS

Okay, so I was speaking about QWERTY layout on QWERTZ variant (so US standard layout as QWERTZ is much closer to it than the shifted QWERTY). So the characters in question are "Ü" and "+" and its normal representation is good, but fn+"Ü" representation will give you fn+"+" representation. It is only one example, there are also other typos, most of them are exists twice after each other in the array. ...like "KEY_0" in the fn-part of "KEY_P", so fn+P will give you what fn+0 should give. I may not found this issue if I was not trying to redefine the keyboard as most of the keys

I am not tried to blame @tdm but I have found the code linked earlier has some typos, basically fn-related arrays are not correct. There are some keys exist at two places and AltGr flag is missing on most of them and that made my custom layout unable to work. This kind of a typo is definitively caused by a tired programmer maybe at a very late hour of programming and definitively not a bad programmer. Also the driver as a whole is well written. Currently I try to do an fn-version of array based on the non-fn version which I think is absolutely correct. One thing what I curr

Okay, currently I am only investigated QWERTZ layout, but its FN section is completely messed up. Only those characters are working which are in appropriate places and OR-ed by KF_ALTGR There are mistakes inside, also KEY9 (for example) character has double places inside, so it should be totally corrected. For characters which use KEY | KF_ALTGR there, I see the correct scancodes and also 100 which is a press of AltGr, so that part is totally fine, only the FN section should be corrected. I think @tdm was really tired when he filled that table in.

I could not redefine my layout because of the typo above and these arrays should be checked also for other typos. So when I press together slant arrow+"[" character, its scancode changes from 26 to 27 and the above typo is the reason of that (so it behaves like if I was pressing slant arrow+"]" character). It definitively has to be corrected in keyboard driver while I also would like to check for other typos. As part of it, I don't understand why it uses KF_SHIFT and KF_ALTGR flags in "fn"-related array mixed together which I also would like to check if it may be related of the mu

Right, we have QWERTY and QWERTZ profiles which remaps the physical keys according to the actual locations of the QWERTZ and shifted QWERTY layout to have their proper scan codes. If you look at the source of qx100.c which I don't know if it is the latest version, there are qwertz_keys / qwertz_fn_keys array and also their qwerty representation which are seem to be copied into key_array and key_fn_array arrays according to the value set as the physical layout. There is an aw9523b_check_keys() function which then selects appropriate key presses from the arrays above. There is a g_ph

I may have some ideas what to do once I have a development environment set up, currently the more serious question is the test device itself - I have also not replaced stock OS for a reason on my daily driver. I saw that - that was I referred to as "config" above. 🙂 I don't know if (and how) I can do a pull request on it but I have not even looked in what that script really does yet. The pressure is at my side... I have no time for it but need to get my phone working and being nervous something which worked perfectly for me got really bad. It took me the weekend to get m

Thanks. For doing this, I should have some time digging into LineageOS development tools, settings, looking where the actual sources related to Pro1 are (I saw there is a config but codes should be somewhere at GitHub), find a way of doing a pull request if modification works and find another Pro1 to work on, but mostly need time time and time. As I am not in LineageOS developmnet, it is much longer in time to reach even a working environment. 😞

Thank you. I don't know how hard it is to go back to official LineageOS and Android system after that. However, I don't like playing with my daily driver and that is why I have not installed LineageOS earlier although I would have been drop stock OS because of the lot of problems it has, especially when it has started its soft-reboot loops the second time. The only thing made me to remain on stock was a basically working environment and especially the working keyboard. Now I have a working environment but without a properly working keyboard which I feel very uncomfortable.

Thank you, that seems to be a relatively complete description. However, that builds the whole system which can not be tested on a daily driver in any ways. I also don't know the current partition layout and current working principle of loading the OS. There is a bootloader which I hope unrelated to the kernel. There are A and B slots on Pro1 which I think should be the place of the kernel and there is at least a system parition and there should be a data partition. However, if a new kernel is installed on a working LineageOS, I am afraid it won't boot because of other securi

Right. Basically in a way to expose it to the system like it was on stock OS. I don't think it is a dramatic modification but something which would be necessary for practical use of its keyboard. It seems to be a simple difference but its impact is huge. Anyway, do you have knowledge about how this kind of development works on Android? I mean how could I update the kernel of an OS for testing, can I go back to the "stock" solution and what can I do in case of a failed attempt. The another part is the software environment for compiling under Linux and which is the actual sour

Right, @tdm made an awesome work and he worked really hard and could achieve results very quickly. I have tried to follow the thread about the keyboard driver and basically it seemed to be a good thing. I somewhat remember (but had to find it out again) the fn key was modified which I had a bad feeling about, but I could not test if it causes any problems. ...but apparently it prevents me to define my modified layout where slant arrow would be useful to reach an other layer of the keys just like how the blue arrow worked for me on my N900. ...and it worked for me absolutely perfect

I am currently very sad as (for me) it seems to be a bug in the kernel driver which prevents me to use my device in full functionality, so currently its keyboard is only half-working or less for me... 😞 I am sad because it is unlikely for me to repair it being it is my daily driver and I don't know about other parts which may be related of this scancode modification. Maybe replacing "KF_ALTGR" with "KF_FN" in qx1000.c file would solve it but it is only a guess without deeper knowledge or more serious interpretation of that code and as if it would need experimenting on my daily driver,

On stock OS, these keys only produce 25 and 39 (respectively) and slant arrow has a scan code of 464 independently of these keys, there are no strange multi scancode generation...

I ran into some problems with slant arrow when I have tried to redefine my keyboard map. It seems originally it was named as "fn" but it was renamed to "ralt" under LineageOS. So I have tried to do the same keyboard map for me where national accents should go (for example) to keys '[' and ']'. I have used a layout where keyboard was QWERTY and I could reach national letters by slant arrow+key combination. Currently it seems this kind of definition is not possible for all of the keys, but works on others. If I look of the keycodes in "KeyEvent Display" application, I see the

So I think it does an update file by file instead of pulling up like an image or this kind of sideloaded application already lies on a separate partition.