Closed ahmedtohamy1 closed 6 months ago
Switched to https://github.com/projects-nexus/nexus_kernel_xiaomi_sm8250 to met vantom recommendations about ksu
Status update: Qpr2 booted https://t.me/AgmadSpace/269 but after some source commit and qpr2 dt side fixes Source commit is: https://github.com/ricedroidOSS/android_build/commit/338d60c8a12bfe2294636c2f44d4fde26039025c
I believe thats commit was there before qpr2
@ahmedtohamy1 No, it was not there before QPR2 and it will not be there on QPR2. You'll have to change the configuration in your tree instead.
@basamaryan fair enough just revised alioth official common tree and it doesnt have it as mine, so reverted.
@basamaryan but nah i was right it was there in qpr1 https://github.com/PixelOS-AOSP/build/commit/8c1845c3594faefc10988992dba42dea9f2a382c
You will not inline a kernel that ships KernelSU and/or its hooks.
@cyberknight777 i already declared that i switched to https://github.com/projects-nexus/nexus_kernel_xiaomi_sm8250
Which is already used in alioth official builds after i discussed that topic with vantom
Use the kernel in github.com/PixelOS-Devices. Not the one in nexus-devices as that ships the KernelSU driver and hooks.
@cyberknight777 oki got it, will use. Any other reviews about dts itself?
Which kernel are you using again, if you don't mind me asking?
Sorry but we don't do that here https://github.com/Apollo-Trees/device_xiaomi_sm8250-common/commit/a9271894cefa89fcf00d99b3d0c0d71b01e86547
https://github.com/Apollo-Trees/device_xiaomi_sm8250-common/commit/07755610d3261ad6da54b0e0ba653adb08fd3c6b Logs there are not really justifying on why the QTI Thermal is failing to intialize.
Amend with proper authorship, not the thanks in the commit description. https://github.com/Apollo-Trees/device_xiaomi_sm8250-common/commit/ae7d3a2c0ad15f0613d52fb4ec9adb49be18d50d
https://github.com/Apollo-Trees/device_xiaomi_sm8250-common/commit/e1235f59945e4c2c0a21b95d0362df6b3ee16218 How is Android.mk changes related with powerhint changes, separate both changes in two different commits.
Is this change really required? What happens when you don't have it? https://github.com/Apollo-Trees/device_xiaomi_sm8250-common/commit/63395d6edaf5e7df62d0db873ab2016cf396458e
Was there really any need to move back to armv8-a for TARGET_ARCH_VARIANT ? If you're talking about the build issues, it should have been fixed if you had the TARGET_2ND_ARCH_VARIANT as armv8-a. https://github.com/Apollo-Trees/device_xiaomi_sm8250-common/commit/18fefb36e3660a61e07b8dc9cab2e6a01ac2c480
Why would you change SHIPPING_API_LEVEL? https://github.com/ahmedtohamy1/device_xiaomi_apollo/commit/249daa1fdd98f458342d3259c4f54c850f731490
https://github.com/ahmedtohamy1/device_xiaomi_apollo/commit/74caf0051d1b1237a818895ad282f3d869b2f45d https://github.com/ahmedtohamy1/device_xiaomi_apollo/commit/f7d5951b2586208209f7d164a5e523080d375d1c Squash merge with better commit message and description. And yeah so you removed and added the same thing at last huh https://github.com/ahmedtohamy1/device_xiaomi_apollo/commit/9111fbfab9b27eebd5dc2c9ebb36023ee30d8edc
https://github.com/ahmedtohamy1/device_xiaomi_apollo/commit/ec21ce37c72a6aa27ff5e9222d3a58bef7bc758f Since when does importing configs remove these?
Any reasons on why you are doing this? https://github.com/ahmedtohamy1/device_xiaomi_apollo/commit/bd663e9ce76510a84eefd760a1f782a4ee1a27bc
Use the shim from hardware/compat https://github.com/ahmedtohamy1/device_xiaomi_apollo/commit/44a22b832313e76b5b066b839899f8471f395f78 Also why are you using two same shims?
https://github.com/Apollo-Trees/device_xiaomi_sm8250-common/commit/ba94edea0f5739b53719a86178fdaacf18b7e06f You say apollo doesn't support wrappedkey but I feel like you're missing changes for making it work. Go through https://source.android.com/docs/security/features/encryption/hw-wrapped-keys.
@kawaaii for kernel currently using this https://github.com/LineageOS/android_kernel_xiaomi_sm8250 as even nexus rebasing over it and its doing fine now.
for changes u mentioned:
@ahmedtohamy1 I used to just do https://github.com/PixelOS-Devices/device_xiaomi_sm6150-common/commit/d731e4495bcc4bc1ee9883a5ad0ae4d752b0b18c but have now switched to https://review.lineageos.org/c/LineageOS/android_device_xiaomi_sm6150-common/+/387795
@basamaryan got it
- nothing more on logs thats the case on rest of mikona devices, but will drop for now and retest
There is no such thing as nothing more on logs, build yourself eng build and find out what's wrong.
- part of display hal device side wasnt building
What part?
- already using blobs from munch which are from a13 so tested upreving api and it went without issues as per logs so kept it also removed in rebased tree
That's not a proper reason for upreving SHIPPING_API level to R for a device launched with Q.
Use INTERACTION hint rather than these props. https://github.com/Apollo-Trees/device_xiaomi_sm8250-common/commit/a185a78ac224b203d7fc184fa42a6f7980c7ab19
https://github.com/Apollo-Trees/device_xiaomi_sm8250-common/commit/4c975cec8d3cb78e673d730a48b929f6b4ef1b8c Can you tell me why you don't want to use AOSP default configuration?
https://github.com/Apollo-Trees/device_xiaomi_sm8250-common/commit/40d5d65c19a623a5c928db1bc66eacd5ace4be48 Why in the tree? This is something to be done in source. Also why GoogleDialer?
https://github.com/Apollo-Trees/device_xiaomi_sm8250-common/commit/e8d866c054f8cc8227cce8e3669e301e3d6a997c Can't you just use LLVM_BINUTILS, which is enabled by default?
Just wanted to know, does your device not support FM in stock?
@kawaaii 1.2.3.4. will drop no prob 5 no it doesn't
@kawaaii 1.2.3.4. will drop no prob 5 no it doesn't
I am actually interested in knowing why you did those changes in first place now, especially 2,3 and 4.
@kawaaii
- part of display hal device side wasnt building
What part?
?
@kawaaii also stock does build it
@kawaaii also stock does build it
Show me stock having vendor.qti.hardware.display.mapperextensions@1.2 built, because I can just find stock having till vendor.qti.hardware.display.mapperextensions@1.1 while you claim stock has @1.2 interface as well. Am I missing something?
@kawaaii also stock does build it
Show me stock having vendor.qti.hardware.display.mapperextensions@1.2 built, because I can just find stock having till vendor.qti.hardware.display.mapperextensions@1.1 while you claim stock has @1.2 interface as well. Am I missing something?
Stock has old version of it, then why not use newer too?
@kawaaii Also as i told i always pick that too https://github.com/EmanuelCN/hardware_qcom-caf_display_sm8250/commit/c2087da868cf29a786bbce21c3fc0fcd02c8b82a
@kawaaii so what?
Hey, I've read the entire conversation and things seems fine now. We might need a very few more changes but it can be fixed in the post.
Please proceed with a PR in official_devices.
Name and Codename of the device you want to apply for
Device Tree sources
What ROM's do you maintain officially/unofficially
How long have you been building Custom ROMs
Any Exceptions/special concern?
List of changes/patches applied to source, if any
Contact
Telegram username
Link to your unofficial PixelOS Build Post other than XDA