VaZso

I suspect it was what broke my build but a lot of row followed it where I could not find errors, but then... LD drivers/staging/built-in.o LD drivers/built-in.o LINK vmlinux LD vmlinux.o MODPOST vmlinux.o GEN .version CHK include/generated/compile.h UPD include/generated/compile.h CC init/version.o LD init/built-in.o KSYM .tmp_kallsyms1.o KSYM .tmp_kallsyms2.o LD vmlinux SORTEX vmlinux SYSMAP System.map OBJCOPY arch/arm64/boot/Image DTC arch/arm64/boot/dts/qcom/msm8998-v2-qrd-skuk-t5.dtb GZIP arc

Okay, it has an inline specifier. Anyway, I don't know why it complains me about AIDL CHECK API / "No API file exist" Maybe it has something to do with my host system. :S

Although the CPU is fast, generally it is better to keep the code simple. By calling a function, it needs stack handling and some amount of user memory handling, so calling a function several times in a row at driver level may not be advised. So by using need_forced_modifier() and modifier_forced() may be readable better, performance-wise it is better as it was - at this level a bit larger code may be better if it runs faster. I don't know if compiler optimizes it out or not however.

You are right, I have read that later on writing my message, sorry.

Interesting... if I also creates /data/system/keyboard/keymap file then it can be enabled in settings but it still does not take effect... still something needs to be checked. It takes effect if I manually pass the whole file to /sys/bus/i2c/drivers/aw9523b/6-0058/keymap

I had this problem also on stock when Android did a soft restart and somehow caps lock was toggled before it (I think in closed state). That was during my software reboot-loop I think when kernel was still counting up but Android has restarted on top. So I don't think even if the keyboard driver is the reason.

On stock keyboard, I can't see á/Á, ő/Ő, ú/Ú, é/É, í/Í, ó/Ó, ű/Ű and sorry, it seems ű/Ű may be the unreachable character and not í/Í - so if I would use only characters written on Pro1's keyboard. Yes, that is an option but it makes use of keyboard very ineffective (at least for me). Also people are tolerant on forums for writing without accents here, however, if I would write a business e-mail without accents, that would be a shame for me... English US complemented by Hungarian. As the driver is the low level, kcm (at higher level) can nothing to do if driver

Not yet but there are feedbacks on this forum about it...

Right, keymap (hardware layout): QWERTZ Software layout: English/US, but I would like to have an option to complement it to easily reach national characters QWERTZ (as hardware layout) was much better as an international keyboard than QWERTY because the latter was shifted, so buttons apart from US alphabet were mixed up. So, basically QWERTZ was the more like standard QWERTY than the one named as QWERTY which had mixed keys, that is why I chose QWERTZ. Shifted QWERTY would not work well for international use as a lot of non alphanumeric buttons are in a very different place th

Do you mean you pass both slant arrows as "nf" to higher levels? ...or you did something related in driver level?

It didn't work for me because I had Engliish layout selected but you are right, it works. Sorry, I didn't see it every time I have tried. However, losing two slant arrows for general purpose when not having any modifiers (like "FN" was on stock)...

In stock, I think they did it the simplest way. FinQwerty was mostly needed because QWERTZ layout did not have their keys in appropriate positions as it was also provide the same keycodes as shifted variant - it did not have separate settings. So it was really bad on QWERTZ units but I think it was good at QWERTY units. Right, but that is not compatible for AltGr functions as it does not generate it and not even generates "FN" function which could be corrected with the help of a solution like Finqwerty. QWERTZ Standard QWERTY (non-shifted naturally) but also supp

Yes, stock OS did not distinguish QWERTY and QWERTZ and I think also the handling of keypresses were worse. ...and it will continue to work anyway even if it would be usable for others. I don't know how specific it is, but the use case: Pro1 has a relatively few amount of keys My language has a lot of keys which adds to English alphabets I can reach all characters instantly by using both slant arrows Current driver does not allow using slant arrows for this purpose but mostly could be added while normal use case does not change It seemed @Slion may a

Anyway, if it remain there, I will move back to stock OS as I wold like to USE my device and I currently CANT! Driver is a low-level thing and it should not prevent doing higher level API to work! Also I am feeling to give up and may even buy another device if it remains unusable. The only reason I have it is the keyboard! Sorry, I feel enough and being nervous being alone.

Right, the following modifiers it handles: KEY_LEFTSHIFT KEY_LEFTCTRL KEY_LEFTALT KEY_RIGHTALT KEY_CAPSLOCK Yes, it can generate logical modifiers and if KF_ALTGR flag is applied in "fn" array, it will send KEY_RIGHTALT which would make possible of higher level layout defining. That is what I need, that is needed for a solution like Finqwerty would work and that is what national layouts may use. Alt+tab is one thing but the inability of redefining the keyboard is a much higher problem I think, as for me, basically the keyboard is UNUSABLE for me this

I don't think so, I could not see it working that way and AltGr is designed to be something else. Basically that is the very same keypress as "right alt" simply they needed a special key on international keyboards (back in standars PC) and as a result, they has renamed right alt to AltGr which became a "special shift" for extra characters the layout not has as standard. For example, if you connect a keyboard to a PC which has Hungarian layout but your OS was set to English/USA, AltGr will be right alt. If you connect a standard (USA) keyboard but OS is set to Hungarian layout, right

Maybe one way it would be a good compromise... if it would also add AltGr (as currently although it practically does not use it) and also meta-left and meta-right, so general AltGr functionality would also work while they could also be defined specifically. ...but I still think we don't really need it, alt+tab may be used on both of them and it would need higher amount of modification.... for practical use, it is unnecessary to do it.

So you mean QWERTY-ex and QWERTZ-ex as you mentioned earlier. That is really easy if you could add -ex layouts above - I didn't have a chance to look at UI side and also testing would not be easy for me currently but at driver side it is easy. I don't feel it is necessary and it would also need some refactoring of the code - it can be done but higher effort for less value. I also don't know if meta is available to use in .kcm file but I suspect it is, however, it would lose AltGr functionality which means international layouts AltGr part would also be skipped that way. S

What do you want to do? Adding -ex versions to the UI and appropriate "fn" section(s)? Do you see how could it be added also to official LineageOS build? I have almost done the "fn"-variant but stopped yet as wanted to compare it with LineageOS current version - however, the pure one is easy to produce of the current one I have. Just asking because it is a particular (what is the appropriate word?) work and not really an interesting part, but it should be correct in order to work well...

Right, systemd does not make it easier, but build environment is there and basically it works apart from the amount of free space an Android build needs.

Yeah, I am currently copying it from a 1TB SSD to a 2TB SSD but they are not recently installed and the former is also my live backup of important projects in case the latter dies which is a faster M.2 drive. Also this project has a plenty of files and I don't know if it will completely restart the process or continue it. 🙂

I do it on an i7-6820HQ - however, I gave up the docker solution (it wanted to be too automatic). Most likely it ran out of free space but it did not write what was the problem, so I have set up an Ubuntu 20.04 in chroot instead. ...then I have restarted it and now I ran out of free space on that partition, so currently I am moving the whole environment to another, khm... SSD. It needs a plenty of free space.

Yes, that is why we started pushing a lot of messages here. 🙂 What is why I have started digging into the driver is the practically absolute inability to remap keys pushed together with slant arrow. I have also found other things in the fn-part of the buttons and I would also suggest to add AltGr function to those buttons even if there are hardcoded layout settings. If there would be another setting(s) beside QWERTY and QWERTZ then it is possible to build the very same keyboard map what stock OS has (named as QWERTY) and also a non-shifted variant which then will be combatible with

Thanks. Had you do any settings or it worked atomatically? It may did a restart because I have opened its settings from status bar to see anything related why I haven't see anything.

...just a question... Is HDMI output expected to work? I could achieve a soft-restart (twice) of Android upon connecting it to an extrernal display. Kernel still shows around 2 days of uptime.