Please publish the complete WiFi source code kernel

[pgw308]

Why is the 5G WiFi signal of the ROM built with your source code is particularly weak and the signal of Oxygen OS 5G WiFi is particularly strong Please publish the complete or specially optimized WiFi code

[Hikari-no-Tenshi]

I guess problem is not just kernel or WiFi kernel modules.
I've tried to use custom ROM with Oxygen kernel and Oxygen WiFi modules and still had same weak signal.
More likely needd changes are in system (wifi-service, wificond). WiFi firmware may expect some commands from system to configure its transmition power.

If OnePlus reads this, leave comment to confirm my guess.

[pgw308]

I guess problem is not just kernel or WiFi kernel modules.
I've tried to use custom ROM with Oxygen kernel and Oxygen WiFi modules and still had same weak signal.
More likely needd changes are in system (wifi-service, wificond). WiFi firmware may expect some commands from system to configure its transmition power.

If OnePlus reads this, leave comment to confirm my guess.

Yes, there may be many other things that they haven’t released. I heard that this problem affects the entire 7 series models’ third-party firmware. WiFi 7pro, 7t, and 7tpro have similar problems.

[Hikari-no-Tenshi]

Because this changes not a part of Open source you can forget about it to be released.
You must find solution by yourself.
Some time ago i've tried to fix 5GHz band power, but no luck. Then i just dropped my attempts.
I'm for 99% sure that wifi-service.jar controlling WiFi power and with help of vendorcmdtool sending commands to WiFi driver.

[pgw308]

Because this changes not a part of Open source you can forget about it to be released.
You must find solution by yourself.
Some time ago i've tried to fix 5GHz band power, but no luck. Then i just dropped my attempts.
I'm for 99% sure that wifi-service.jar controlling WiFi power and with help of vendorcmdtool sending commands to WiFi driver.

Wow! If successful, the 5GWiFi problem will be resolved, then you will make a major share for the 7T custom community

[pgw308]

Because this changes not a part of Open source you can forget about it to be released.
You must find solution by yourself.
Some time ago i've tried to fix 5GHz band power, but no luck. Then i just dropped my attempts.
I'm for 99% sure that wifi-service.jar controlling WiFi power and with help of vendorcmdtool sending commands to WiFi driver.

And I found that not only the 5G WiFi signal is weak, the 2.4G WiFi is also a bit weak

[luk1337]

@vl3550 @Hikari-no-Tenshi try this change https://review.lineageos.org/c/LineageOS/android_device_oneplus_sm8150-common/+/309551

[RealJohnGalt]

@vl3550 @Hikari-no-Tenshi try this change https://review.lineageos.org/c/LineageOS/android_device_oneplus_sm8150-common/+/309551

No change whatsoever in 5ghz wlan performance. Also it appears to load same firmware with or without this change on HD1905 for me.

[luk1337]

adb logcat | grep -i cnss and post output.

[RealJohnGalt]

adb logcat | grep -i cnss and post output.

05-07 13:05:28.878 1236 1236 I cnss-daemon: nl80211 response handler invoked
05-07 13:05:28.878 1236 1236 I cnss-daemon: nl80211_response_handler: cmd 103, vendorID 4980, subcmd 13 received
repeatedly spammed.

[luk1337]

Start logging at the beginning of booting up.

[RealJohnGalt]

Start logging at the beginning of booting up.

http://ix.io/3m5L

Seems it hanged at some point, will attempt to get a better log.

[luk1337]

05-07 13:07:21.767  1272  1526 I cnss-daemon: pj_id=4, hw_id=14, rf_id=2
05-07 13:07:21.767  1272  1526 I cnss-daemon: BDF file properties is set as : 0
05-07 13:07:21.767  1272  1526 I cnss-daemon: it is 18865, begin to load the 18865 BDF file
05-07 13:07:21.771  1272  1526 I cnss-daemon: wlfw_send_bdf_download_req: BDF file : 4bdwlan.b0a
05-07 13:07:21.775  1272  1526 I cnss-daemon: wlfw_send_bdf_download_req: bdf type 0,result 0, error 0

it loads proper FW now.

[luk1337]

You should now see that 2.4GHz TX power is increased ( 20 -> 23, check iw reg get )

[RealJohnGalt]

You should now see that 2.4GHz TX power is increased ( 20 -> 23, check iw reg get )

Will do, apologies for the false alarm. I tested range with my drone, and as usual it was poor on 5ghz compared to my other device and my old OOS test.

Really nice work if this helps some people.

[gotenksIN]

seems to be working nice for me, thanks :D

[luk1337]

BTW, it's kinda stupid that OnePlus hardcoded setting these props in /system/bin/init...
( my commit message originally said that it was QMI but after a closer look, it was actually init. )

[gotenksIN]

ikr, apparently similar things with perms for input nodes
those actually broke prox with custom kernels even on oos xD

[luk1337]

Hmm...I thought OOS just used oneplus.sensor.infrared.proximity instead of android.sensor.proximity and that's why it didn't need chmod.

[gotenksIN]

according to multiple posts on custom kernel threads (like https://forum.xda-developers.com/t/kernel-25-04-2021-4-14-231-android-11-kirisakura-1-1-6_r-for-op7-pro-aka-guacamole.3933916/post-84798999) it was broken until he added it in bootscripts to chmod

[luk1337]

Wouldn't be surprised if oss kernel was just slightly broken...

[luk1337]

btw @gotenksIN I assume that ALS is not working properly for you on non-OOS? I looked through various forks of my sm8150-common tree and sadly none of them had made any changes to ALS correction code...

[gotenksIN]

yeah, although it does seem be fairly consistent compared to q sensors hal, although no where near to the improvements oos 11 ob2 and newer brought
tried different brightness configs and all but so far the only usable change would be to just increase the debounce values but I feel that it's too ugly :3
but oos does seem to have overlays in OdmOverlay-framework-res.apk with config_limitMinLux which we have no idea what it does but is probably related

[luk1337]

Well...hacking around brightness overlays is only working around the actual problem — ALS correction code just doesn't really work on 7T series devices. It works relatively ok on 7 Pro and maybe 7 but I don't have 7 so can't really talk much about it.

[idoybh]

Well...hacking around brightness overlays is only working around the actual problem — ALS correction code just doesn't really work on 7T series devices. It works relatively ok on 7 Pro and maybe 7 but I don't have 7 so can't really talk much about it.

It works ok-ish on 7p. But it's still way worse than OOS

[luk1337]

Try to disassemble stock libsensorservice. I was amazed at how complex the whole thing was, there are like 20 variables controlling the whole correction code.

        android::String8::append(v2, "fusionlight args list:\n");
        android::String8::appendFormat(v2, "R_max: %f\n", *(float *)&R_max);
        android::String8::appendFormat(v2, "G_max: %f\n", *(float *)&G_max);
        android::String8::appendFormat(v2, "B_max: %f\n", *(float *)&B_max);
        android::String8::appendFormat(v2, "W_max: %f\n", *(float *)&W_max);
        android::String8::appendFormat(v2, "R_max_cal: %f\n", *(float *)&dword_400F4);
        android::String8::appendFormat(v2, "G_max_cal: %f\n", *(float *)&dword_400F8);
        android::String8::appendFormat(v2, "B_max_cal: %f\n", *(float *)&dword_400FC);
        android::String8::appendFormat(v2, "W_max_cal: %f\n", *(float *)&dword_40100);
        android::String8::appendFormat(v2, "R_Comp_1: %f\n", *(float *)&dword_40104);
        android::String8::appendFormat(v2, "R_Comp_2: %f\n", *(float *)&dword_40108);
        android::String8::appendFormat(v2, "R_Comp_3: %f\n", *(float *)&dword_4010C);
        android::String8::appendFormat(v2, "G_Comp_1: %f\n", *(float *)&dword_40114);
        android::String8::appendFormat(v2, "G_Comp_2: %f\n", *(float *)&dword_40118);
        android::String8::appendFormat(v2, "G_Comp_3: %f\n", *(float *)&dword_4011C);
        android::String8::appendFormat(v2, "B_Comp_1: %f\n", *(float *)&dword_40124);
        android::String8::appendFormat(v2, "B_Comp_2: %f\n", *(float *)&dword_40128);
        android::String8::appendFormat(v2, "B_Comp_3: %f\n", *(float *)&dword_4012C);
        android::String8::appendFormat(v2, "Greyscale_1: %f\n", *(float *)&dword_40134);
        android::String8::appendFormat(v2, "Greyscale_2: %f\n", *(float *)&dword_40138);
        android::String8::appendFormat(v2, "Greyscale_3: %f\n", *(float *)&dword_4013C);
        android::String8::appendFormat(v2, "W_Comp_1: %f\n", *(float *)&dword_40140);
        android::String8::appendFormat(v2, "W_Comp_2: %f\n", *(float *)&dword_40144);
        android::String8::appendFormat(v2, "W_Comp_3: %f\n", *(float *)&dword_40148);
        android::String8::appendFormat(v2, "rou_coe: %f\n", *(float *)&dword_40154);
        android::String8::appendFormat(v2, "threshold: %d\n", (unsigned int)dword_40264);
        return android::String8::appendFormat(v2, "level_cal_arg: %f\n", *(float *)&dword_40150);

[pgw308]

So now the WiFi signal problem has been resolved. Is the issue of automatic brightness being discussed now?

[pgw308]

Try to disassemble stock libsensorservice. I was amazed at how complex the whole thing was, there are like 20 variables controlling the whole correction code.

        android::String8::append(v2, "fusionlight args list:\n");
        android::String8::appendFormat(v2, "R_max: %f\n", *(float *)&R_max);
        android::String8::appendFormat(v2, "G_max: %f\n", *(float *)&G_max);
        android::String8::appendFormat(v2, "B_max: %f\n", *(float *)&B_max);
        android::String8::appendFormat(v2, "W_max: %f\n", *(float *)&W_max);
        android::String8::appendFormat(v2, "R_max_cal: %f\n", *(float *)&dword_400F4);
        android::String8::appendFormat(v2, "G_max_cal: %f\n", *(float *)&dword_400F8);
        android::String8::appendFormat(v2, "B_max_cal: %f\n", *(float *)&dword_400FC);
        android::String8::appendFormat(v2, "W_max_cal: %f\n", *(float *)&dword_40100);
        android::String8::appendFormat(v2, "R_Comp_1: %f\n", *(float *)&dword_40104);
        android::String8::appendFormat(v2, "R_Comp_2: %f\n", *(float *)&dword_40108);
        android::String8::appendFormat(v2, "R_Comp_3: %f\n", *(float *)&dword_4010C);
        android::String8::appendFormat(v2, "G_Comp_1: %f\n", *(float *)&dword_40114);
        android::String8::appendFormat(v2, "G_Comp_2: %f\n", *(float *)&dword_40118);
        android::String8::appendFormat(v2, "G_Comp_3: %f\n", *(float *)&dword_4011C);
        android::String8::appendFormat(v2, "B_Comp_1: %f\n", *(float *)&dword_40124);
        android::String8::appendFormat(v2, "B_Comp_2: %f\n", *(float *)&dword_40128);
        android::String8::appendFormat(v2, "B_Comp_3: %f\n", *(float *)&dword_4012C);
        android::String8::appendFormat(v2, "Greyscale_1: %f\n", *(float *)&dword_40134);
        android::String8::appendFormat(v2, "Greyscale_2: %f\n", *(float *)&dword_40138);
        android::String8::appendFormat(v2, "Greyscale_3: %f\n", *(float *)&dword_4013C);
        android::String8::appendFormat(v2, "W_Comp_1: %f\n", *(float *)&dword_40140);
        android::String8::appendFormat(v2, "W_Comp_2: %f\n", *(float *)&dword_40144);
        android::String8::appendFormat(v2, "W_Comp_3: %f\n", *(float *)&dword_40148);
        android::String8::appendFormat(v2, "rou_coe: %f\n", *(float *)&dword_40154);
        android::String8::appendFormat(v2, "threshold: %d\n", (unsigned int)dword_40264);
        return android::String8::appendFormat(v2, "level_cal_arg: %f\n", *(float *)&dword_40150);

Does this mean that if you use this solution, the automatic brightness problem will be solved?

[luk1337]

No, this means that you can't read the most basic code. The actual logic has to be reverse engineered and it's too complex for me.

[Hikari-no-Tenshi]

Last year i asked some guys for help to reverse engineer libsensorservice lib. They told me that this lib built with flags that make reverse engineer very hard or impossible.
Also asked OnePlus to share correction code (just in case). They politely refused.

Community have to мake its own correction algorithm.
Tried to make something useful in this direction, but it is too complicated for my skills.

[Hikari-no-Tenshi]

I think that for correction must also be taken to account: night mode, color profile, dc-dimming.
Someone with professional measuring tools for lcd display brightness can measure brightness of display in different modes to correct OnePlus values.

[Hikari-no-Tenshi]

I've tried to do something for night mode Hikari-no-Tenshi/android_device_oneplus_guacamoleb-merged@e2e4da0
Code maybe ugly, but i'm not a proffessioal programmer.

[pgw308]

I think that for correction must also be taken to account: night mode, color profile, dc-dimming.
Someone with professional measuring tools for lcd display brightness can measure brightness of display in different modes to correct OnePlus values.

@YuHuang65 Yes, there is also a problem with the color profile. OnePlus does need to be corrected.

[gotenksIN]

@vl3550 @Hikari-no-Tenshi try this change https://review.lineageos.org/c/LineageOS/android_device_oneplus_sm8150-common/+/309551

well another good outcome out of this was that now that we are loading proper wlan firmware, wifi aware and wifi rtt works perfectly, just enabled feature flags and props in yaap/device_oneplus_sm8150-common@dcf2bbe

[luk1337]

That app only checks if permission/feature is available...

[gotenksIN]

well logs are pretty happy about it being enabled as well

05-09 13:33:35.039  1411  1411 I SystemServerTiming: StartRttService
05-09 13:33:35.040  1411  1411 I SystemServiceManager: Starting com.android.server.wifi.rtt.RttService
05-09 13:33:35.040  1411  1411 I RttService: Registering wifirtt
05-09 13:33:35.041  1411  1411 I SystemServerTiming: StartWifiAware
05-09 13:33:35.041  1411  1411 I SystemServiceManager: Starting com.android.server.wifi.aware.WifiAwareService
05-09 13:33:35.042  1411  1411 I WifiAwareService: Registering wifiaware
05-09 13:33:35.042  1411  1411 I SystemServerTiming: StartWifiP2P
05-09 13:33:35.042  1411  1411 I SystemServiceManager: Starting com.android.server.wifi.p2p.WifiP2pService

I haven't seen any crashes after that

[luk1337]

I'd look for some more detailed info than "services start". Granted I don't really know how to test Aware/RTT.

[gotenksIN]

well last I tried, it spammed logs miserably about not being able to connect to the wifi interface we specified in the props.
will see if I can test it between devices that support it

Edit: taking a fresh log from boot

05-09 14:59:15.849  1444  1486 I ActivityManagerTiming: OnBootPhase_1000_com.android.server.wifi.aware.WifiAwareService
05-09 14:59:15.849  1444  2204 D WifiService: Handle boot completed
05-09 14:59:15.849  1444  1486 I WifiAwareService: Late initialization of Wi-Fi Aware service
05-09 14:59:16.288  1444  2245 D WIFI_AWARE_FACTORY: got request NetworkRequest [ TRACK_DEFAULT id=26, [ Capabilities: INTERNET&NOT_RESTRICTED&TRUSTED Uid: 10176 AdministratorUids: [] RequestorUid: 10176 RequestorPackageName: com.qualcomm.qti.cne] ] with score 50 and providerId 4

this is all I get apart from service started.

[gotenksIN]

I'd look for some more detailed info than "services start". Granted I don't really know how to test Aware/RTT.

can check with https://play.google.com/store/apps/details?id=com.google.android.apps.location.rtt.wifinanscan, sadly I don't have any other device on hand which does support wifi aware

[luk1337]

None of my devices declare support for it...I could theoretically use two hacked OnePlus phones for it tho.

[luk1337]

Apparently, CtsVerifier has tests for WiFi Aware but it appears that I can't even pass mWifiAwareManager.isAvailable() check there...

[luk1337]

ok, after enabling some qcacld-3.0 debugging i got the following msg: [ 20.945963] NAN separate vdev supported by host, not supported by firmware so RIP Aware/NAN.

[gotenksIN]

F, so stock enables this for keks or are we missing more firmware? since caf seems to enable this by default on msmnile targets

[luk1337]

Stock does not have WiFi Aware/NAN.

[gotenksIN]

I see, well thanks for info

[timocapa]

yo luk, do we not need the proto files from sensors?

https://dumps.tadiphone.dev/dumps/oneplus/oneplus7t/-/tree/qssi-user-11-RKQ1.201022.002-2104060845-release-keys/vendor/etc/sensors/proto

[luk1337]

Unlikely.