Hi Guys,
As you may notice from my signature, I'm actually an LG G4 owner (attempting ) to assist with the development of Oreo roms for the G4. @kessaras and @steadfasterX have done a magnificent job so far and we have two bugs left - the torch tile in quick settings doesn't work (not a big deal right now, we just recommend an app as a workaround) and also we have robotic bt calling with a hands free set.
I have been browsing the hammerhead forums and noticed that this exact problem is also plaguing the Nexus 5 (and we share the same broadcom 4339 bt/wifi chipset, so I would imagine this is why we suffer from the same issue), and I was wondering whether it would be a good idea to share any ideas here as to how we could fix it - we have tweaked a lot of bluetooth settings so far but it has either made no difference or killed the bluetooth entirely.
@amaces I noticed you mentioned in your Unlegacy Android thread that you got it to work in a hardcoded and messy way - would it be possible for you to share it? I know you said it wasn't good for a production build, but if we could see how you got it working then it would definitely help us to find a proper fix.
Thanks for any help
I have that same problem. (android 8.1 or 9.0)
Nexus 5 D820
The issue is probably caused by the HIDLization and the introduction of eSCO command set. Prior to Oreo vendor specific commands(VSCs) were sent to the controller which would trigger I2S/PCM sco configuration.
When the HIDLization started the VSC for the sco configuration was removed 796523d and later on with the introduction of eSCO command setup these calls to the broadcom's libbt-vendor(pre-SCO setup) were completely removed a9152a2.
I tried retrieving retrieving these calls removed by eSCO(3/5), yet I cant get it working.
Here's what I've done so far:
system/bt stack
fb1d404
47f50f8-a2df04b
hardware/interfaces
dd21c98
The issue is either the way I attempt to send the VSC via send_command method, or in some of the methods which are supposed to notify the AG that the pre-sco is done.
So far I noticed that the code of bta_ag_ci_sco_open_continue method is never reached, but things could've went south even before this method, I dunno.
Looking at the snoop log nothing is even sent to the controller about this.
@steadfasterX @ThePiGuy if you guys are still interested in fixing this issue, you should really focus on retrieving these calls imho.
Would be good if anyone tries this c0d86fb. What I am trying is basically to avoid the need of hw_set_audio_state() call from bt stack to configurare SCO over PCM.
Should be accompanied by this commit in order to work.
@amaces @razorloves
Hi there,
Sorry for delay. I was a bit busy today. Here is my workaround for bt issue:
1) android_hardware_broadcom_libbt
2) device tree
Honestly this workaround is terrible (explanations will be provided below) and disabled by default. You should add two parameters to vendor config in order to activate it:
1) BTHW_FW_EXTENDED_CONFIGURATION - Enable/disable the fix. TRUE/FALSE. Default value is FALSE.
2) BTHW_FW_EXTENDED_SCO_CODEC - SCO codec. Use the numeric value from the sco_codec_t enum. Default value is SCO_CODEC_CVSD.
Seems that the problem lies in firmware for our BT chip and eSCO command set. Controller have invalid audio configuration or doesn't have any audio configuration at all after firmware upload. That was not a problem before this change (Thanks @Sashko98 for research). I've tried a solution proposed by @Sashko98 but nothing changed. After a couple of days playing with different parameters in configs i noticed interesting line in logcat:
Code:
W/bt_hci:
filter_incoming_event command complete event with no matching command (opcode: [B]0xfc6d[/B])
0xfc6d is a HCI_VSC_WRITE_I2SPCM_INTERFACE_PARAM constant defined here and used inside of the hw_sco_i2spcm_config method. Seems that bt controller responds to HCI_VSC_WRITE_I2SPCM_INTERFACE_PARAM command. But why we still have an issue with audio? The answer is simple: SCO configuration can not be completed because bt_hci blocks events and callbacks are not called at all! If device uses SCO_INTERFACE_PCM bus interface then hw_sco_i2spcm_config method will send 3 commands: HCI_VSC_WRITE_I2SPCM_INTERFACE_PARAM, HCI_VSC_WRITE_SCO_PCM_INT_PARAM, HCI_VSC_WRITE_PCM_DATA_FORMAT_PARAM. Each next command will be sent only if previous was sent successfully and controller responded with correct status. Сontroller responds, but bt_hci blocks the very first event and SCO configuration fails.
We have 2 possible solutions here:
1) Understand why bt_hci blocks events... This is ideal solution, but not easy! bt_hci is a part of system bluetooth stack and bluetooth stack is huge!
2) Send all the necessary commands without waiting for response from bt controller. Yep, i know how it sounds but it works! At least for now...
I've implemented solution #2. Look at hw_config_continue_sco_setup method. It works just like the hw_set_SCO_codec method but doesn't wait for response from bt controller. Why the hw_set_SCO_codec? Because it sends one more command related to WBS before calling the hw_sco_i2spcm_config.
As i said before i think this solution is terrible. Here are my concerns about it:
1) Uncontrolled commands sent to bt controller. Who knows how long this will work...
2) Can be applied only for broadcom chips.
That's all I found at the moment. I will try to implement the solution #1, but I can't tell whether it will work. Feel free to contact me if you have any questions/ideas/improvements.
Many thank to devs who still support our old hammy! @razorloves, @amaces, @EnesSastim, @voidz777, @KiD3991, @Hannibal226, @hhrokarvi, @Sashko98 and many other! You guys are awesome! Thanks a lot for your work!!! All this would be impossible without you!!!
PS: Sorry for my terrible english
z3DD3r said:
We have 2 possible solutions here:
1) Understand why bt_hci blocks events... This is ideal solution, but not easy! bt_hci is a part of system bluetooth stack and bluetooth stack is huge!
2) Send all the necessary commands without waiting for response from bt controller. Yep, i know how it sounds but it works! At least for now...
As i said before i think this solution is terrible. Here are my concerns about it:
1) Uncontrolled commands sent to bt controller. Who knows how long this will work...
2) Can be applied only for broadcom chips.
Click to expand...
Click to collapse
If i understand correctly this is just a warning that the hci module doesn't recognize the command, which I believe is normal since the call is not made from the bt stack( which is not quite needed at this point anyway).
What is curious to me is why are the VSCs even required. I mean I tried to replicate the exact clock/codec etc.. configuration as it would've been configured if the VSCs were send, in the vnd config and there was no change at all. Probably there is something in the hcd patch about this, which would explain why my attempt in the post above works for Galaxy Note 3 and doesn't work for us.(if i am right than your hack could be considered just as extended of the hcd patch.)
Broadcom's libbt-vendor is pretty much obsolete, thus it will be easier to maintain this hack in further OS versions. Changes to bt-stack to get this work would be just too much time consuming to maintain considering that the guys from Google working on the AOSP want as less VSCs as possible.
Read this https://source.android.com/devices/bluetooth just to see how the Bluetooth works,if you plan to retrieve the VSCs to bt stack.
Sashko98 said:
If i understand correctly this is just a warning that the hci module doesn't recognize the command, which I believe is normal since the call is not made from the bt stack( which is not quite needed at this point anyway).
Click to expand...
Click to collapse
This is partly true. This warning means that HCI received event for command which was not sent from bt stack. Some commands are send directly from the VendorInterface class and should be handle only here.
Sashko98 said:
What is curious to me is why are the VSCs even required. I mean I tried to replicate the exact clock/codec etc.. configuration as it would've been configured if the VSCs were send, in the vnd config and there was no change at all.
Click to expand...
Click to collapse
It is not enough to just setup the vnd config. U still need to call hw_sco_i2spcm_config or hw_set_SCO_codec. But as i described above these methods fails.
Sashko98 said:
Probably there is something in the hcd patch about this, which would explain why my attempt in the post above works for Galaxy Note 3 and doesn't work for us.(if i am right than your hack could be considered just as extended of the hcd patch.)
Click to expand...
Click to collapse
You are right! This issue can be fixed new firmware or additional firmware prepatch. But we will never receive such update) I did one experiment. Your fixes + custom firmware for our chip downloaded from here = working bt calls But this way is more crazy that my current hack)))
Sashko98 said:
Broadcom's libbt-vendor is pretty much obsolete, thus it will be easier to maintain this hack in further OS versions. Changes to bt-stack to get this work would be just too much time consuming to maintain considering that the guys from Google working on the AOSP want as less VSCs as possible.
Read this https://source.android.com/devices/bluetooth just to see how the Bluetooth works,if you plan to retrieve the VSCs to bt stack.
Click to expand...
Click to collapse
Looks like we don't need to change anything in bt stack. Seems i have found the real issue. Look at VendorInterface::HandleEvent method. Seems that this is an entry point for all events sent from controller. This method uses the internal_command to determine how the received event should be handled. internal_command is populated inside of transmit_cb which is called from the libbt-vendor. So, what happens if someone will send 2 commands one after another? First command will be recorded into the internal_command var and the second command will be recorded to internal_command var. Second command will overwrite the infrormation about first. And since the communication is made via UART, controller will sent us response for first command (which is already gone) and then response for second command. Thats why nothing works! Thats why i saw that strange lines in logcat!!!
All that means that your fix should work. U just need to improve it a bit:
1. android_hardware_interfaces. Move lib_interface_->op(BT_VND_OP_SCO_CFG, nullptr); right after the lib_interface_->op(BT_VND_OP_LPM_SET_MODE, &mode);
2. c0d86f. Call the hw_set_SCO_codec for PCM instead of hw_sco_i2spcm_config
I have not tried it myself yet. But logs and logic seems correct. Bt calls issue may be not fixed cos of initialization sequence, but all callbacks should be called correctly.
---------- Post added at 08:47 AM ---------- Previous post was at 08:37 AM ----------
Hmm, seems that based on my finding i can improve my initial solution. At least i can made controllable configuration of the SCO with all required callbacks! Will try it today...
z3DD3r said:
This is partly true. This warning means that HCI received event for command which was not sent from bt stack. Some commands are send directly from the VendorInterface class and should be handle only here.
Click to expand...
Click to collapse
The VendorInterface still comunicates with the bt stack via the hci_layer.
z3DD3r said:
It is not enough to just setup the vnd config. U still need to call hw_sco_i2spcm_config or hw_set_SCO_codec. But as i described above these methods fails.
You are right! This issue can be fixed new firmware or additional firmware prepatch. But we will never receive such update) I did one experiment. Your fixes + custom firmware for our chip downloaded from here = working bt calls But this way is more crazy that my current hack)))
Click to expand...
Click to collapse
In ideal case the hcd patch wouldn't need VSCs for such configuration, because It would've already been configured(what you tried with the custom patch just proves it). Appereantly Xperia Z3(shinano) is using its own solution by configuring the controller using bt drivers link. Perhaps this is why it is the only device I know of with BCM4339 Wifi/bt chip which didn't have any issues with bt-sco. Their code compiles perfectly with our kernel, but there are many init changes needed to happen to make it work.
z3DD3r said:
Looks like we don't need to change anything in bt stack. Seems i have found the real issue. Look at VendorInterface::HandleEvent method. Seems that this is an entry point for all events sent from controller. This method uses the internal_command to determine how the received event should be handled. internal_command is populated inside of transmit_cb which is called from the libbt-vendor. So, what happens if someone will send 2 commands one after another? First command will be recorded into the internal_command var and the second command will be recorded to internal_command var. Second command will overwrite the infrormation about first. And since the communication is made via UART, controller will sent us response for first command (which is already gone) and then response for second command. Thats why nothing works! Thats why i saw that strange lines in logcat!!!
Click to expand...
Click to collapse
If there is any race happening I think it should be handled by the VendorInterface, thought looking at the VendorInterface::HandleIncomingEvent method in vendor_interface.cc it is already handling such cases.
On Nougat the I2S/PCM interface was configured only when sco connection was established, if you look at the first eSCO commit you'll see that the initial idea was to keep the pre-SCO vendor setup link, thus I I used to be focused pretty much on bringing this back, till I understood there is no point, as it would require changes not only to the bt stack, but to Bluetooth app aswell.
As I said its just consumes too much time, not only to do it successfully, but to maintain it.
z3DD3r said:
All that means that your fix should work. U just need to improve it a bit:
1. android_hardware_interfaces. Move lib_interface_->op(BT_VND_OP_SCO_CFG, nullptr); right after the lib_interface_->op(BT_VND_OP_LPM_SET_MODE, &mode);
2. c0d86f. Call the hw_set_SCO_codec for PCM instead of hw_sco_i2spcm_config
..
Click to expand...
Click to collapse
hw_set_SCO_codec is useless at this point, as everything goes back to hw_sco_i2spcm_config to configure sample rate for the required codec. The clock rate is the same regardless of the codec.
On my local builds I moved lib_interface_->op(BT_VND_OP_SCO_CFG, nullptr); to the end of the method. Just for the tests once I put it even in VendorInterface;;Open, doesn't really matter where it is as long as it is called. The problem is that the callback methods arent reached. I tried sending BT_VND_OP_SET_AUDIO_STATE opcode command to start the whole sequene, but it doesnt get past the first send VSC(HCI_VSC_ENABLE_WBS) I believe it was, exactly due to the cbacks.
Sashko98 said:
In ideal case the hcd patch wouldn't need VSCs for such configuration, because It would've already been configured(what you tried with the custom patch just proves it). Appereantly Xperia Z3(shinano) is using its own solution by configuring the controller using bt drivers . Perhaps this is why it is the only device I know of with BCM4339 Wifi/bt chip which didn't have any issues with bt-sco. Their code compiles perfectly with our kernel, but there are many init changes needed to happen to make it work.
Click to expand...
Click to collapse
I know another device - LG G2. Own bt driver can work, but it looks very complicated to me...
Sashko98 said:
If there is any race happening I think it should be handled by the VendorInterface, thought looking at the VendorInterface::HandleIncomingEvent() method in vendor_interface.cc it is already handling such cases.
Click to expand...
Click to collapse
I don't see any race conditions here. Just a simple mistake. Only one variable is used instead of queue. Maybe this interface wasn't designed to handle such cases...
Sashko98 said:
On Nougat the I2S/PCM interface was configured only when sco connection was established, if you look at the first eSCO commit you'll see that the initial idea was to keep the pre-SCO vendor setup [url=https://github.com/LineageOS/android_system_bt/commit/86f1b61e614b4110d953b91d1eee3812802c1f34#diff-91f58eb08ce9dea17af6a8fd5d3b313aR478]link
Click to expand...
Click to collapse
Sashko98 said:
, thus I I used to be focused pretty much on bringing this back, till I understood there is no point, as it would require changes not only to the bt stack, but to Bluetooth app aswell.
As I said its just consumes too much time, not only to do it successfully, but to maintain it.
Click to expand...
Click to collapse
Fully agree with you. Maintaining all those changes will be painful...
Sashko98 said:
hw_set_SCO_codec is useless at this point, as everything goes back to hw_sco_i2spcm_config to configure sample rate for the required codec. The clock rate is the same regardless of the codec.
Click to expand...
Click to collapse
Who knows. I'm using it cos BT_VND_OP_SET_AUDIO_STATE command actually call hw_set_SCO_codec and not the hw_sco_i2spcm_config. hw_set_SCO_codec sends one additional command to enable/disable WBS. It may be not necessary for Nexus 5, but it can be necessary for other devices. In any case i think we should make this behavior configurable.
Sashko98 said:
On my local builds I moved lib_interface_->op(BT_VND_OP_SCO_CFG, nullptr); to the end of the method. Just for the tests once I put it even in VendorInterface:pen(), doesn't really matter where it is as long as it is called. The problem is that the callback methods arent reached. I tried sending BT_VND_OP_SET_AUDIO_STATE opcode command to start the whole sequene, but it doesnt get past the first send VSC(HCI_VSC_ENABLE_WBS) I believe it was.
Click to expand...
Click to collapse
This is very strange. Look at my logcat (LOS wit BT fix):
Code:
06-18 09:06:15.850 I/bt_hwcfg(7282): hw_config_continue_sco_setup: set SCO related hardware settings
06-18 09:06:15.850 I/bt_hwcfg(7282): hw_config_continue_sco_setup: set SCO codec: 0x1
06-18 09:06:15.850 D/[email protected](7282): buffer_alloc_cb pts: 0x9f483e60, size: 14
[B]06-18 09:06:15.850 D/[email protected](7282): transmit_cb opcode: 0xfc7e, ptr: 0x9f483e60, cb: 0x8b2cfcf9 - First opcode from hw_set_SCO_codec[/B]
06-18 09:06:15.850 I/bt_hwcfg(7282): hw_config_continue_sco_setup: set SCO I2S/PCM codec: 0x1
06-18 09:06:15.850 D/[email protected](7282): buffer_alloc_cb pts: 0x9f483e60, size: 15
06-18 09:06:15.850 I/bt_hwcfg(7282): hw_config_continue_sco_setup: I2SPCM config {0x0, 0x0, 0x0, 0x4}
06-18 09:06:15.850 D/[email protected](7282): transmit_cb opcode: 0xfc6d, ptr: 0x9f483e60, cb: 0x8b2cfcf9
06-18 09:06:15.850 D/[email protected](7282): buffer_alloc_cb pts: 0x9f483e60, size: 16
06-18 09:06:15.850 I/bt_hwcfg(7282): hw_config_continue_sco_setup: SCO PCM configure {0x0, 0x4, 0x0, 0x0, 0x0}
06-18 09:06:15.850 D/[email protected](7282): transmit_cb opcode: 0xfc1c, ptr: 0x9f483e60, cb: 0x8b2cfcf9
06-18 09:06:15.850 D/[email protected](7282): buffer_alloc_cb pts: 0x9f483e60, size: 16
06-18 09:06:15.850 I/bt_hwcfg(7282): hw_config_continue_sco_setup: SCO PCM data format {0x0, 0x0, 0x3, 0x0, 0x0}
06-18 09:06:15.850 D/[email protected](7282): transmit_cb opcode: 0xfc1e, ptr: 0x9f483e60, cb: 0x8b2cfcf9
06-18 09:06:15.850 I/bt_hwcfg(7282): hw_config_continue_sco_setup: finish
06-18 09:06:15.850 D/[email protected](7282): firmware_config_cb result: 0
06-18 09:06:15.850 D/[email protected](7282): OnFirmwareConfigured result: 0
06-18 09:06:15.850 I/[email protected](7282): Firmware configured in 0.635s
06-18 09:06:15.850 D/[email protected](7282): OnFirmwareConfigured: lpm_timeout_ms 1500
06-18 09:06:15.850 I/bt_hci (7282): event_finish_startup
06-18 09:06:15.850 D/[email protected](7282): buffer_alloc_cb pts: 0x9f495958, size: 23
06-18 09:06:15.850 I/bt_core_module(7282): module_start_up Started module "hci_module"
06-18 09:06:15.850 D/[email protected](7282): transmit_cb opcode: 0xfc27, ptr: 0x9f495958, cb: 0x8b2cf4f9
06-18 09:06:15.850 D/[email protected](7282): OnFirmwareConfigured Calling StartLowPowerWatchdog()
06-18 09:06:15.851 D/[email protected](7282): sco_config_cb result: 0
06-18 09:06:15.851 D/[email protected](7282): OnScoConfigured result: 0
06-18 09:06:15.851 D/[email protected](7282): buffer_free_cb ptr: 0x9f483e50
[b]06-18 09:06:15.851 D/[email protected](7282): internal_command_event_match internal_command.opcode = FC27 opcode = fc7e - First event from bt controller[/b]
06-18 09:06:15.851 I/bt_osi_thread(7282): run_thread: thread id 7330, thread name bt_workqueue started
06-18 09:06:15.851 D/[email protected](7282): event_cb_ called
06-18 09:06:15.851 W/bt_hci (7282): filter_incoming_event command complete event with no matching command (opcode: 0xfc7e).
06-18 09:06:15.851 I/ (7282): [0618/090615.851280:INFO:btu_task.cc(107)] Bluetooth chip preload is complete
06-18 09:06:15.851 I/ (7282): [0618/090615.851843:INFO:gatt_api.cc(948)] GATT_Register 81818181-8181-8181-8181-818181818181
06-18 09:06:15.851 I/ (7282): [0618/090615.851972:INFO:gatt_api.cc(968)] allocated gatt_if=1
06-18 09:06:15.852 I/ (7282): [0618/090615.852038:INFO:gatt_api.cc(161)] GATTS_AddService
06-18 09:06:15.852 I/ (7282): [0618/090615.852094:INFO:gatt_api.cc(265)] GATTS_AddService: service parsed correctly, now starting
06-18 09:06:15.852 I/ (7282): [0618/090615.852276:INFO:gatt_api.cc(948)] GATT_Register 82828282-8282-8282-8282-828282828282
06-18 09:06:15.852 I/ (7282): [0618/090615.852333:INFO:gatt_api.cc(968)] allocated gatt_if=2
06-18 09:06:15.852 I/ (7282): [0618/090615.852402:INFO:gatt_api.cc(161)] GATTS_AddService
06-18 09:06:15.852 I/ (7282): [0618/090615.852455:INFO:gatt_api.cc(265)] GATTS_AddService: service parsed correctly, now starting
06-18 09:06:15.852 I/bt_bte (7282): BTE_InitTraceLevels -- TRC_HCI : Level 2
06-18 09:06:15.852 I/bt_bte (7282): BTE_InitTraceLevels -- TRC_L2CAP : Level 2
06-18 09:06:15.852 I/bt_bte (7282): BTE_InitTraceLevels -- TRC_RFCOMM : Level 2
06-18 09:06:15.852 I/bt_bte (7282): BTE_InitTraceLevels -- TRC_AVDT : Level 2
06-18 09:06:15.852 I/bt_bte (7282): BTE_InitTraceLevels -- TRC_AVRC : Level 2
06-18 09:06:15.852 I/bt_bte (7282): BTE_InitTraceLevels -- TRC_A2D : Level 2
06-18 09:06:15.852 I/bt_bte (7282): BTE_InitTraceLevels -- TRC_BNEP : Level 2
06-18 09:06:15.852 I/bt_bte (7282): BTE_InitTraceLevels -- TRC_BTM : Level 2
06-18 09:06:15.852 I/bt_bte (7282): BTE_InitTraceLevels -- TRC_HID_HOST : Level 2
06-18 09:06:15.852 I/bt_bte (7282): BTE_InitTraceLevels -- TRC_PAN : Level 2
06-18 09:06:15.852 I/bt_bte (7282): BTE_InitTraceLevels -- TRC_SDP : Level 2
06-18 09:06:15.852 I/bt_bte (7282): BTE_InitTraceLevels -- TRC_SMP : Level 2
06-18 09:06:15.852 I/bt_bte (7282): BTE_InitTraceLevels -- TRC_HID_DEV : Level 2
06-18 09:06:15.852 I/bt_bte (7282): BTE_InitTraceLevels -- TRC_BTAPP : Level 2
06-18 09:06:15.852 I/bt_bte (7282): BTE_InitTraceLevels -- TRC_BTIF : Level 2
06-18 09:06:15.853 I/bt_osi_thread(7282): run_thread: thread id 7331, thread name btu message loop started
[B]06-18 09:06:15.853 D/[email protected](7282): internal_command_event_match internal_command.opcode = FC27 opcode = fc6d - Second one[/B]
06-18 09:06:15.853 D/[email protected](7282): event_cb_ called
06-18 09:06:15.853 W/bt_hci (7282): filter_incoming_event command complete event with no matching command (opcode: 0xfc6d).
06-18 09:06:15.853 D/[email protected](7282): internal_command_event_match internal_command.opcode = FC27 opcode = fc1c
06-18 09:06:15.853 D/[email protected](7282): event_cb_ called
06-18 09:06:15.853 W/bt_hci (7282): filter_incoming_event command complete event with no matching command (opcode: 0xfc1c).
06-18 09:06:15.853 D/[email protected](7282): internal_command_event_match internal_command.opcode = FC27 opcode = fc1e
06-18 09:06:15.853 D/[email protected](7282): event_cb_ called
06-18 09:06:15.853 W/bt_hci (7282): filter_incoming_event command complete event with no matching command (opcode: 0xfc1e).
06-18 09:06:15.853 D/[email protected](7282): internal_command_event_match internal_command.opcode = FC27 opcode = fc27
06-18 09:06:15.853 I/bt_osi_thread(7282): run_thread: thread id 7332, thread name module_wrapper started
06-18 09:06:15.853 D/[email protected](7282): internal_command.bc called
internal_command.opcode doesn't match to the opcode received from bt controller. All events related to sco configuration will be handled by HCI. But HCI doesn't know anything about these commands and events (filter_incoming_event command complete event with no matching command in the log). Actually FC27 is HCI_VSC_WRITE_SLEEP_MODE. Seems that someone else sends this opcode to controller. I think that this can happens only after firmware configuration. We can try to postpone call of the initialize_complete_cb_ until sco configuration finish.
z3DD3r said:
This is very strange. Look at my logcat (LOS wit BT fix):
internal_command.opcode doesn't match to the opcode received from bt controller. All events related to sco configuration will be handled by HCI. But HCI doesn't know anything about these commands and events (filter_incoming_event command complete event with no matching command in the log). Actually FC27 is HCI_VSC_WRITE_SLEEP_MODE. Seems that someone else sends this opcode to controller. I think that this can happens only after firmware configuration. We can try to postpone call of the initialize_complete_cb_ until sco configuration finish.
Click to expand...
Click to collapse
Its probably because you sent the VSCs directly from libbt-vendor, rather than sending an opcode command from VendorInterface, which then sends VSCs, and thus the VendorInterface considers the last internal opcode(BT_VND_OP_LPM_SET_MODE in this case) saved, as the next opcode commands which are being received.
If these logs bug you so much, just edit small part of the bt_vendor_brcm.c and include named by you opcode command which points to the hw_config_continue method, then call it from the VendorInterface.
If you do this then you should partially revert your commit, and set the firmware configuration as it was before, but then again it doesn't matter where the I2S/PCM interface is configured, what matters most is that it is configured.
Sashko98 said:
Its probably because you sent the VSCs directly from libbt-vendor, rather than sending an opcode command from VendorInterface, which then sends VSCs, and thus the VendorInterface considers the last internal opcode(BT_VND_OP_LPM_SET_MODE in this case) saved, as the next opcode commands which are being received.
If these logs bug you so much, just edit small part of the bt_vendor_brcm.c and include named by you opcode command which points to the hw_config_continue method, then call it from the VendorInterface.
If you do this then you should partially revert your commit, and set the firmware configuration as it was before, but then again it doesn't matter where the I2S/PCM interface is configured, what matters most is that it is configured.
Click to expand...
Click to collapse
Seems that we a talking about different things. It really doesn't matter where the I2S/PCM interface is configured. It matters when!
Good news!
I've managed to improve initial solution!
Commit:
78d62ad58da101371822cee107f7759841d2744b
Changes:
No more memory leaks.
No more uncontrolled commands to bt chip. Each sent command receives callback and handles it appropriately.
Ability to configure codec configuration through the vnd config. We can use only i2spcm or wbs+i2spcm.
@razorloves, what do you think about it?
I can share a test build if anyone is interested.
z3DD3r said:
Seems that we a talking about different things. It really doesn't matter where the I2S/PCM interface is configured. It matters when!
Good news!
I've managed to improve initial solution!
Commit:
78d62ad58da101371822cee107f7759841d2744b
Changes:
No more memory leaks.
No more uncontrolled commands to bt chip. Each sent command receives callback and handles it appropriately.
Ability to configure codec configuration through the vnd config. We can use only i2spcm or wbs+i2spcm.
@razorloves, what do you think about it?
I can share a test build if anyone is interested.
Click to expand...
Click to collapse
Thank you very much Man @z3DD3r
You Rock :fingers-crossed: :highfive:
z3DD3r said:
Seems that we a talking about different things. It really doesn't matter where the I2S/PCM interface is configured. It matters when!
Good news!
I've managed to improve initial solution!
Commit:
78d62ad58da101371822cee107f7759841d2744b
Changes:
No more memory leaks.
No more uncontrolled commands to bt chip. Each sent command receives callback and handles it appropriately.
Ability to configure codec configuration through the vnd config. We can use only i2spcm or wbs+i2spcm.
@razorloves, what do you think about it?
I can share a test build if anyone is interested.
Click to expand...
Click to collapse
I will try to adapt this to the LG g4 and if that works I will kiss your feet , really .. It tried since months to get that working (we have the same chipset) and tested almost everything I could think of .. But you're way ahead of me.. Thanks for taking the time to explain everything and ofc for the fix
Sent from my OnePlus 6T using XDA Labs
Hi @steadfasterX,
This should work for all devices with broadcom bluetooth chip. At least i don't see any reasons not to work... Just get the latest code of the libbt and configure your vnd config.
I think i should rebase libbt to have only one commit with actual description...
---------- Post added at 08:17 PM ---------- Previous post was at 08:17 PM ----------
Hi @steadfasterX,
This should work for all devices with broadcom bluetooth chip. At least i don't see any reasons not to work... Just get the latest code of the libbt and configure your vnd config.
I think i should rebase libbt to have only one commit with actual description...
z3DD3r said:
Hi @steadfasterX,
This should work for all devices with broadcom bluetooth chip. At least i don't see any reasons not to work... Just get the latest code of the libbt and configure your vnd config.
I think i should rebase libbt to have only one commit with actual description...
---------- Post added at 08:17 PM ---------- Previous post was at 08:17 PM ----------
Hi @steadfasterX,
This should work for all devices with broadcom bluetooth chip. At least i don't see any reasons not to work... Just get the latest code of the libbt and configure your vnd config.
I think i should rebase libbt to have only one commit with actual description...
Click to expand...
Click to collapse
Yea I strongly believe it will work especially as we have the exact same chip model.
Would be nice if you rebase but if not then not .. I can test it tomorrow first so ..
Thanks again you have no idea how long the ppl are waiting for such a fix..
Sent from my OnePlus 6T using XDA Labs
@steadfasterX, @razorloves
Rebased:
broadcom libbt
hammerhead device tree
z3DD3r said:
@steadfasterX, @razorloves
Rebased:
broadcom libbt
hammerhead device tree
Click to expand...
Click to collapse
you are incredible @z3DD3r , @Sashko98 .. it really works.. I mean.. over 1 year no one was able to solve that f*** ! You're the saviour .. :highfive:
where the hell is your f*** donation addr @z3DD3r ??? :laugh: I am serious about that q
I recognized one little thing: one letter is not coming through in both directions: Z (german spoken like "zwei") or the C like in "niCe" or "intelligenCe". Its like it gets lost. I have tested with WBS active atm and will do some further tests with maybe clock rate etc. Just wanted to let you know. its still an awesome thing and when you speak out the character very loud it comes through btw.
UPDATE:
ok with or without preferred WBS makes no diff on that lost char issue
UPDATE2:
Log with WBS pref to FALSE (issue still there): https://paste.omnirom.org/view/28af9d55
(stopping audio server, starting it, incoming call, accept call, while talking log is silent)
.. and to clarify its hard to track that "lost char" issue. I am testing with 2 headsets, 1 connected to my main phone (OP6T) and the other to my G4. I mute always one of the both and then talking the little delay in transmitting the voice allows to hear that issue when you know it. so the impact of that here is not big I think but if you have any idea what to try let me know.
.-
z3DD3r said:
@steadfasterX, @razorloves
Rebased:
broadcom libbt
hammerhead device tree
Click to expand...
Click to collapse
This is unnecessary if you want to send HCI_VSC_ENABLE_WBS just route through it. We set the codecs manually anyway.
Code:
#if (BTHW_FW_EXTENDED_CONFIGURATION_ONLY_I2SPCM_CONFIG == FALSE)
hw_config_extended_set_SCO_codec(BTHW_FW_EXTENDED_CONFIGURATION_SCO_CODEC);
#else
hw_config_extended_sco_i2spcm_config(BTHW_FW_EXTENDED_CONFIGURATION_SCO_CODEC);
#endif // (BTHW_FW_EXTENDED_CONFIGURATION_ONLY_I2SPCM_CONFIG)
This could be re-worked
Code:
#if (BTHW_FW_EXTENDED_CONFIGURATION == FALSE)
static void hw_config_extended_start(void)
{
if (bt_vendor_cbacks)
{
bt_vendor_cbacks->fwcfg_cb(BT_VND_OP_RESULT_SUCCESS);
}
}
#else
static void hw_config_extended_finish(uint8_t result)
..........................
into
Code:
case HW_CFG_SET_BD_ADDR:
ALOGI("vendor lib fwcfg completed");
bt_vendor_cbacks->dealloc(p_buf);
#if (BTHW_FW_EXTENDED_CONFIGURATION == TRUE)
hw_config_extended_start();
#else
bt_vendor_cbacks->fwcfg_cb(BT_VND_OP_RESULT_SUCCESS);
#endif
Also since you figured out the callbacks, consider using your idea on the existing methods. No need for all this re-definitions.
The changes in the device tree are unnecessary
BTM_WBS_INCLUDED was removed since Oreo
BTIF_HF_WBS_PREFERRED was removed later on on Pie
steadfasterX said:
ok with or without preferred WBS makes no diff on that lost char issue
UPDATE2:
Log with WBS pref to FALSE (issue still there): https://paste.omnirom.org/view/28af9d55
(stopping audio server, starting it, incoming call, accept call, while talking log is silent)
.. and to clarify its hard to track that "lost char" issue. I am testing with 2 headsets, 1 connected to my main phone (OP6T) and the other to my G4. I mute always one of the both and then talking the little delay in transmitting the voice allows to hear that issue when you know it. so the impact of that here is not big I think but if you have any idea what to try let me know.
Click to expand...
Click to collapse
Try setting the BTHW_FW_EXTENDED_CONFIGURATION_SCO_CODEC as SCO_CODEC_MSBC, if that doesn't work maybe try this 540b42c
Sashko98 said:
Try setting the BTHW_FW_EXTENDED_CONFIGURATION_SCO_CODEC as SCO_CODEC_MSBC
Click to expand...
Click to collapse
thx dude..
already tried that - no change
I also tried setting the SCO rate to force 8K - no change
I will test that commit asap
@Sashko98 ok I tried that commit and this resulted in outgoing = distorted sound, incoming = silence
log: https://paste.omnirom.org/view/c7134f75
.-
steadfasterX said:
thx dude..
already tried that - no change
I also tried setting the SCO rate to force 8K - no change
I will test that commit asap
@Sashko98 ok I tried that commit and this resulted in outgoing = distorted sound, incoming = silence
log: https://paste.omnirom.org/view/c7134f75
Click to expand...
Click to collapse
Send your local vnd config just in case, perhaps there is something in there which effects everything. Other possibility is the mixer_paths or the audio_platform_info.
I see that you get good logs from the ACDB loader. if Nougat or stock rom didn't have such issue establish sco connection and look for line similar to this
Code:
D ACDB-LOADER: ACDB -> send_voice_cal, acdb_rx = 22, acdb_tx = 21,
acdb_rx = SND_DEVICE_OUT_BT_SCO <acdb_id>
acdb_tx = SND_DEVICE_IN_BT_SCO_MIC <acdb_id>
Perhaps something in the acdb mapping has changed. Check if on Nougat/stock rom different acdbs are being used for receiving and transmitting, and if by any change different acdbs are used, map them via the audio_platform_info
Related
I've tried every possible idea i can think of to get GPS to work in the AOSP 1.6 and ghibs 1.6 build, and neither work. I've done full wipes for both, flashed both correctly, installed the bits correctly, and cannot get GPS to function. It turns on (well it checks) but nothing ever turns on, and it can never locate me.
Any suggestions or explanations why GPS would not be working?
EDIT:
Did a RUU, wiped, rerooted and flashed from stock. Seems to be working now.
myke66 said:
I've tried every possible idea i can think of to get GPS to work in the AOSP 1.6 and ghibs 1.6 build, and neither work. I've done full wipes for both, flashed both correctly, installed the bits correctly, and cannot get GPS to function. It turns on (well it checks) but nothing ever turns on, and it can never locate me.
Any suggestions or explanations why GPS would not be working?
Click to expand...
Click to collapse
Can you pull /etc/gps.conf and /system/etc/gps.conf and post the contents of each, the reason I ask is because I had an issue with this file on ghil 1.6 and had to replace that file to get it to work. More than likely that wont be the issue, but it doesn't hurt to check everything.
theoottesen said:
Can you pull /etc/gps.conf and /system/etc/gps.conf and post the contents of each, the reason I ask is because I had an issue with this file on ghil 1.6 and had to replace that file to get it to work. More than likely that wont be the issue, but it doesn't hurt to check everything.
Click to expand...
Click to collapse
Will do. Second.
from /etc
NTP_SERVER=north-america.pool.ntp.org
XTRA_SERVER_1=http://xtra1.gpsonextra.net/xtra.bin
XTRA_SERVER_2=http://xtra2.gpsonextra.net/xtra.bin
XTRA_SERVER_3=http://xtra3.gpsonextra.net/xtra.bin
QOS_ACCURACY=16
Click to expand...
Click to collapse
and from /system/etc
NTP_SERVER=north-america.pool.ntp.org
XTRA_SERVER_1=http://xtra1.gpsonextra.net/xtra.bin
XTRA_SERVER_2=http://xtra2.gpsonextra.net/xtra.bin
XTRA_SERVER_3=http://xtra3.gpsonextra.net/xtra.bin
QOS_ACCURACY=16
Click to expand...
Click to collapse
myke66 said:
Will do. Second.
from /etc
and from /system/etc
Click to expand...
Click to collapse
Yeah that is the same contents of what I had to put it to get mine to work. So I dont think that is it.
If you want to test here is the contents of the gps.conf that did not work for me, you could try and replace it and see if it works out, I know it worked for some people, worth a shot right?
NTP_SERVER=north-america.pool.ntp.org
XTRA_SERVER_1=http://xtra1.gpsonextra.net/xtra.bin
XTRA_SERVER_2=http://xtra2.gpsonextra.net/xtra.bin
XTRA_SERVER_3=http://xtra3.gpsonextra.net/xtra.bin
SUPL_HOST=supl.google.com
SUPL_PORT=7276
Click to expand...
Click to collapse
theoottesen said:
Yeah that is the same contents of what I had to put it to get mine to work. So I dont think that is it.
If you want to test here is the contents of the gps.conf that did not work for me, you could try and replace it and see if it works out, I know it worked for some people, worth a shot right?
Click to expand...
Click to collapse
Sure, ill give that a try, but just to be clear, i dont believe GPS is even turning on, its simply doing nothing when its "turned on" in the options. Ill update and see if that does anything.
Edit: Still nothing. No change whatsoever in the behavior, it just doesnt start GPS. There isnt even an icon for it on the taskbar. It's as if its never turned on, but it is checked.
myke66 said:
Sure, ill give that a try, but just to be clear, i dont believe GPS is even turning on, its simply doing nothing when its "turned on" in the options. Ill update and see if that does anything.
Click to expand...
Click to collapse
Dont forget to reboot after the changes. Just to clarify, are you getting the flashing gps icon on the top bar when you go into google maps?
Edit: Ha you beat me!! The next thing I would suggest is change gps.conf back to the original contents, reboot. Then run turn off gps in the location settings, run "adb logcat" and turn the gps back on and post the results of what happens when you check the box so the dev can see that, hopefully it will tell them whats going on with it.
theoottesen said:
Dont forget to reboot after the changes. Just to clarify, are you getting the flashing gps icon on the top bar when you go into google maps?
Click to expand...
Click to collapse
I did reboot before trying again. I'm getting no icon whatsoever. Like i was saying, its like GPS never turns on.
See my edit in the above post ^^
theoottesen said:
See my edit in the above post ^^
Click to expand...
Click to collapse
Alrighty, already changed it back to that, so ill do the logcat.
D/GpsLocationProvider( 79): enable
D/libgps ( 79): DeferredActionThread started
D/GpsLocationProvider( 79): GpsEventThread starting
D/GpsLocationProvider( 79): pass mutex_lock
D/GpsLocationProvider( 79): NetworkThread starting
D/GpsLocationProvider( 79): setMinTime 1000
D/GpsLocationProvider( 79): NetworkThread out of wake loop
D/GpsLocationProvider( 79): Requesting time from NTP server north-america.pool
.ntp.org
D/GpsLocationProvider( 79): startNavigating
D/libgps ( 79): set PositionMode = 0, sFixFrequency = 1
D/libgps ( 79): qct_gps_start
D/libgps ( 79): pthread_cond_wait returned
D/libgps ( 79): DeferredActionThread calling send_get_position
D/libgps ( 79): PD send_get_position mode: 0, fixFrequency: 1, requestedTimeo
ut: 2, requestedAccuracy: 50, count: 268435455
D/libgps ( 79): PD command:
D/libgps ( 79): RPC_PDSM_PD_CMD_GET_POS
D/SntpClient( 79): round trip: 514 ms
D/SntpClient( 79): clock offset: -17697 ms
D/GpsLocationProvider( 79): calling native_inject_time: 1264578435047 referenc
e: 501771 certainty: 257
D/GpsLocationProvider( 79): NetworkThread wait for 14400000ms
D/GpsLocationProvider( 79): stopNavigating
D/libgps ( 79): pthread_cond_wait returned
D/libgps ( 79): DeferredActionThread calling send_end_session
D/libgps ( 79): PD command:
D/libgps ( 79): RPC_PDSM_PD_CMD_END_SESSION
D/GpsLocationProvider( 79): disable
D/GpsLocationProvider( 79): stopNavigating
D/GpsLocationProvider( 79): pass cond_wait
D/GpsLocationProvider( 79): unlocked mutex
D/GpsLocationProvider( 79): GpsEventThread exiting
D/GpsLocationProvider( 79): stopping NetworkThread
D/GpsLocationProvider( 79): NetworkThread out of wake loop
D/GpsLocationProvider( 79): NetworkThread exiting
D/libgps ( 79): qct_gps_set_fix_frequency(-1452191720)
Click to expand...
Click to collapse
Thats my log from starting, waiting a few, then turning it off.
Edit: Just checked the log for gmaps when trying to find my location and nothing of any use came up, just showed my inputs, and the output of no GPS being found.
It definitely looks different than mine, I am on Modaco's newest rom and I get this when I turn on gps. Hopefully someone more knowledge than myself can help out. Dont know if it makes that much of a difference being on a different rom, if so I can flash to 1.6 and post the logcat that I get from that, or if someone following this thread running 1.6 can post it that would work too.
D/GpsLocationProvider( 144): enable
V/AutoSettingReceiver( 185): AutoSettingReceiver onReceive() : com.htc.app.autosetting.cancel
D/libgps ( 144): DeferredActionThread started
D/GpsLocationProvider( 144): GpsEventThread starting
D/GpsLocationProvider( 144): NetworkThread starting
D/GpsLocationProvider( 144): NetworkThread out of wake loop
D/GpsLocationProvider( 144): Requesting time from NTP server north-america.pool.ntp.org
D/HtcCdmaStatusBar( 144): provide dormancy network icon net:6
D/SntpClient( 144): round trip: 493 ms
D/SntpClient( 144): clock offset: -29919 ms
D/GpsLocationProvider( 144): calling native_inject_time: 1264578644010 reference: 23695123 certainty: 246
D/libgps ( 144): qct_gps_inject_time(1264578644010, 23695123, 246)
D/libgps ( 144): XTRA command:
D/libgps ( 144): RPC_PDSM_XTRA_CMD_TIME_INFO_INJ
D/libgps ( 144): FUNC_RPC_PDSM_XTRA_INJECT_TIME_INFO result: true
D/GpsLocationProvider( 144): NetworkThread wait for 14400000ms
D/libgps ( 144): XTRA event: RPC_PDSM_XTRA_EVENT_STATUS, disc: 2
D/libgps ( 144): flags: 00000001
D/libgps ( 144): status: 1
Click to expand...
Click to collapse
theoottesen said:
It definitely looks different than mine, I am on Modaco's newest rom and I get this when I turn on gps. Hopefully someone more knowledge than myself can help out. Dont know if it makes that much of a difference being on a different rom, if so I can flash to 1.6 and post the logcat that I get from that, or if someone following this thread running 1.6 can post it that would work too.
Click to expand...
Click to collapse
and thats what's even more frustrating, is that GPS on any of the 1.5 roms (fresh, TTG modaco) all work fine.
Well at this point I'm out of ideas, sorry I couldn't have been of more help.
Bump for any ideas
Fixed. Edit in first post.
Hi all,
I'm working on reserve engineering libcamera for Tattoo, based on libcamera2 by NCommander. Thanks to nopy for many help.
HTC have changed a lot in their kernel, and left LOTS of useless or temporary codes not to be cleaned up. Right now, camera codes in the kernel are very clean and tidy and mainly ported from AOSP-donut kernel. Interfaces of /dev/msm_camera/control0, config0, and frame0 are successfully generated. As you know, HTC kernel implemented the /dev/msm_camera/msm_camera0 interface to communicate with requests from user space. I'm not sure why HTC did such a hack. The reason why I ported camera codes from AOSP-donut relies on the fact that most of camera working ROMs for other headsets like Dream or Sapphire did this, even if these ROMs are powered by 2.6.32 or even 2.6.34 kernels.
I've sticked to HTC camera driver in the kernel. Please check out my github.
Here is the explanation of the relationship between libcamera, libqcamera and the kernel, written by NCommander.
This is my first step to reserver engineering work on libcamera. Camera does NOT work yet.
The current logcat and klogtail have been attached here, Donut version as well. Thanks to MrGland, salva.tejero, and kicmi.
If anyone is interested in hacking for Tattoo, just let know. I'll invite you to cooperate with us.
Regards,
do you want try my kernel?
it have a problem with wifi...but the camera and media driver are correctly loaded...
if u want i can send it via pm
i have fix the GL problem on my rom...i haven't a tatto...but if u want i can see again the problem with your rom.
i'm just thinkg to restart my rom from zero. I have already downloaded the froyo source and i'm starting to compile the source and add my personal kernel...
said me if u want collaborate to made a new 2.2 rom
W/dalvikvm( 613): threadid=10: thread exiting with uncaught exception (group=0x400207d8)
I am by no means a c++ expert, but I started learning it last week. A uncaught exception needs catching so that the whole thread does not terminate, you can deal with them using catch(), unless it is a hardware exception
I think you two have the best chance of making a working froyo rom if you work together based on using your roms. I use fyodors 1.6 rom daily
I believe this too.
I prefer fyodor's rom though cause with his roms I never had problems on booting. Ikxdf' s roms from the other side don't boot on my device(except abusu 2.01 and capcake 1.01)
you two (ikxdf,cn.fyodor) are supermans make a team mix up your files and your skills, make a great panfyodorcake ROM and we, tattoo users will be so happy Good Luck
E: omg sry kiljacken and HCDR.Jacob ale supermans too
cn.fyodor said:
I've dived into the source files, and found there was a __NULL__ "config_defaults" array of structure in egl.cpp file. This array was used in eglChooseConfig function, which is heavily related with my issue. I'm not sure what the codes did since not familiar with C++ programming. I've googled a lot, but no luck.
I need C++ experts to read the opengl codes in Froyo system and find the reason why 'No configs match configSpec' error comes up. Thanks in advance.
Regards,
Click to expand...
Click to collapse
If you send me that file or gives me the path to it in the Android source code I'll gladly take a look at it...
If you send me that file or gives me the path to it in the Android source code I'll gladly take a look at it...
Click to expand...
Click to collapse
Same here...
ikxdf said:
do you want try my kernel?
it have a problem with wifi...but the camera and media driver are correctly loaded...
if u want i can send it via pm
i have fix the GL problem on my rom...i haven't a tatto...but if u want i can see again the problem with your rom.
i'm just thinkg to restart my rom from zero. I have already downloaded the froyo source and i'm starting to compile the source and add my personal kernel...
said me if u want collaborate to made a new 2.2 rom
Click to expand...
Click to collapse
Hi, ikxdf
Glad to see you in this dev thread. My kernel can drive the camera correctly, but I haven't verified it yet. Feel free to send yours to me, I'll test it to check whether it works or not.
speedyracer5 said:
W/dalvikvm( 613): threadid=10: thread exiting with uncaught exception (group=0x400207d8)
I am by no means a c++ expert, but I started learning it last week. A uncaught exception needs catching so that the whole thread does not terminate, you can deal with them using catch(), unless it is a hardware exception
Click to expand...
Click to collapse
Thanks for the info. If it's a hardware exception, there must be some bugs in my customized kernel. However, to be honest, I really don't know how to debug the C++ codes.
kiljacken said:
If you send me that file or gives me the path to it in the Android source code I'll gladly take a look at it...
Click to expand...
Click to collapse
Thanks. The top path is frameworks/base/opengl. This exception error was thrown by the ./java/android/opengl/GLSurfaceView.java and the eglChooseConfig function is defined in ./libagl/egl.cpp. Hope you find something useful to debug it.
My greetings,
are the best in the tattoo improving.
Thanks to all the people who try to improve the tattoo...
let´s go friends
cn.fyodor said:
Hi, ikxdf
Glad to see you in this dev thread. My kernel can drive the camera correctly, but I haven't verified it yet. Feel free to send yours to me, I'll test it to check whether it works or not.
Thanks for the info. If it's a hardware exception, there must be some bugs in my customized kernel. However, to be honest, I really don't know how to debug the C++ codes.
Thanks. The top path is frameworks/base/opengl. This exception error was thrown by the ./java/android/opengl/GLSurfaceView.java and the eglChooseConfig function is defined in ./libagl/egl.cpp. Hope you find something useful to debug it.
Click to expand...
Click to collapse
I've looked much at the files and i have fund that the error you get is caused when an app gives some info about a configuration and EGL can't find a config that matches that information...
Does this error happen in the camera app??
cn.fyodor said:
Hi, ikxdf
Glad to see you in this dev thread. My kernel can drive the camera correctly, but I haven't verified it yet. Feel free to send yours to me, I'll test it to check whether it works or not.
Thanks for the info. If it's a hardware exception, there must be some bugs in my customized kernel. However, to be honest, I really don't know how to debug the C++ codes.
Thanks. The top path is frameworks/base/opengl. This exception error was thrown by the ./java/android/opengl/GLSurfaceView.java and the eglChooseConfig function is defined in ./libagl/egl.cpp. Hope you find something useful to debug it.
Click to expand...
Click to collapse
The Exception has been thrown from JAVA because num_config[0] has not been populated by eglChooseConfig. This output parameter it's populated at the last line of eglChooseConfig.
I don't know the architecture of android and egl stuff, what i can reccomend to you is to use the LOGE macro to write in console the list of attibute (attrib_list parameter) and try to see in which point the function returns (using LOGE macro opportunely).
From what i can understand, this function tries to match the list of attributes passed as parameter(attrib_list) with global array of configurations (gConfigs), which contains 8 configurations (every configuration is an array of attributes).
Java makes 2 calls to eglChooseConfig, the first is to retrieve the number of configurations that matches the attribute list, if this number is >0 create an empty array and re-call eglChooseConfig to get the array itself populated, otherwise throws the exception you have showed in your log.
ivendor said:
The Exception has been thrown from JAVA because num_config[0] has not been populated by eglChooseConfig. This output parameter it's populated at the last line of eglChooseConfig.
I don't know the architecture of android and egl stuff, what i can reccomend to you is to use the LOGE macro to write in console the list of attibute (attrib_list parameter) and try to see in which point the function returns (using LOGE macro opportunely).
From what i can understand, this function tries to match the list of attributes passed as parameter(attrib_list) with global array of configurations (gConfigs), which contains 8 configurations (every configuration is an array of attributes).
Java makes 2 calls to eglChooseConfig, the first is to retrieve the number of configurations that matches the attribute list, if this number is >0 create an empty array and re-call eglChooseConfig to get the array itself populated, otherwise throws the exception you have showed in your log.
Click to expand...
Click to collapse
I think you're right...
I think it would be important for all of us, to have a rom 100 % funcional 2.1 or 2.2 without the camera, and before fix the camera...i think
If you make a team i havent doubt could be able to make it real
thanks for all
capito djjkd said:
I think it would be important for all of us, to have a rom 100 % funcional 2.1 or 2.2 without the camera, and before fix the camera...i think
If you make a team i havent doubt could be able to make it real
thanks for all
Click to expand...
Click to collapse
why?
because the devs maybe could stop developing, because they are satisfied of the working camera?
i don't think so. if they could get the camera working, there isn't a long way anymore to a 100% functional 2.1/2.2 ROM.
I hope this comes true, good luck to the devs!!!!!!
ivendor said:
The Exception has been thrown from JAVA because num_config[0] has not been populated by eglChooseConfig. This output parameter it's populated at the last line of eglChooseConfig.
I don't know the architecture of android and egl stuff, what i can reccomend to you is to use the LOGE macro to write in console the list of attibute (attrib_list parameter) and try to see in which point the function returns (using LOGE macro opportunely).
From what i can understand, this function tries to match the list of attributes passed as parameter(attrib_list) with global array of configurations (gConfigs), which contains 8 configurations (every configuration is an array of attributes).
Java makes 2 calls to eglChooseConfig, the first is to retrieve the number of configurations that matches the attribute list, if this number is >0 create an empty array and re-call eglChooseConfig to get the array itself populated, otherwise throws the exception you have showed in your log.
Click to expand...
Click to collapse
I commented out the setEGLConfigChooser() stmt. in Camera/src/*/ui/GLRootView.java source file to use the GLES default config for camera. Although the 'no config match...' exception didn't come up, camera didn't snapshot any images as if the sensor didn't open. Check out the attachment below.
If the setEGLConfigChooser stmt. was added, in eglChooseConfig function, both possibleMatch and num_config will be 0. I'm trying to find the low-level reason.
The setEGLConfigChooser() in Camera/src/*/ui/GLRootView.java source file is defined:
public void
setEGLConfigChooser (int redSize,
int greenSize, int blueSize, int alphaSize, int depthSize, int stencilSize).
All we want (i think) is the correct values for the parameters. Ok at page
http://brandnewreality.com/blog/android-egl-querying-your-gl-driver
there is a java program to query from a donut tattoo the configs....
Now we can correct the parameters at setEGLConfigChooser function.
I hope that this helps us...
seg
segway_ said:
The setEGLConfigChooser() in Camera/src/*/ui/GLRootView.java source file is defined:
public void
setEGLConfigChooser (int redSize,
int greenSize, int blueSize, int alphaSize, int depthSize, int stencilSize).
All we want (i think) is the correct values for the parameters. Ok at page
http://brandnewreality.com/blog/android-egl-querying-your-gl-driver
there is a java program to query from a donut tattoo the configs....
Now we can correct the parameters at setEGLConfigChooser function.
I hope that this helps us...
seg
Click to expand...
Click to collapse
Wont this method you are proposing hard coding the values?Shouldnt these be set by the user?There must be another class with the default values and which saves the user defined values.
Look at the code:
http://android.git.kernel.org/?p=pl...0f823229da7569a51367f20c0c9d048d1cba;hb=froyo
175 private void initialize() {
176 mFlags |= FLAG_INITIALIZED;
177 setEGLConfigChooser(8, 8, 8, 8, 0, 4);
178 getHolder().setFormat(PixelFormat.TRANSLUCENT);
179 setZOrderOnTop(true);
Click to expand...
Click to collapse
Is it hard coded?
seg
Well the values are hard coded.. but at the look of it I guess the hardware need these hard coded values to initialise. Good point seg.
I need to implement a broadcast reciever that will fill variables for the methods my module will hook up.
But every thing that I tried out didnt work.
I tried to implement the reciever in the module class:
public class LogginExtra extends BroadcastReceiver implements IXposedHookLoadPackage {
But it says ClassNotFound.
Tried to make something with sharedPreferences, but the XSharedPreferences doesnt reads the prefs.
And I dont know how to solve this, if someone can help me I need to update 2 variables at the Module class (IXposedHookLoadPackage) from a broadcast reciever.
thanks in advanced.
caioketo said:
I need to implement a broadcast reciever that will fill variables for the methods my module will hook up.
But every thing that I tried out didnt work.
I tried to implement the reciever in the module class:
public class LogginExtra extends BroadcastReceiver implements IXposedHookLoadPackage {
But it says ClassNotFound.
Tried to make something with sharedPreferences, but the XSharedPreferences doesnt reads the prefs.
And I dont know how to solve this, if someone can help me I need to update 2 variables at the Module class (IXposedHookLoadPackage) from a broadcast reciever.
thanks in advanced.
Click to expand...
Click to collapse
The key to the solution is to realize the core of the module (the Xposed hooks) is not an application in itself. Instead its code runs as part of another application or as part of an Android system component. This is why XSharedPreferences is called 'shared'.
It depends on what your module is doing and when/where/how the code of you module runs, which solution is best.
Note that using XSharedPreferences isn't the holy grail either, as this solution might stop working in Android "L", because of new SELinux rules (which could affect quite some modules).
M66B said:
The key to the solution is to realize the core of the module (the Xposed hooks) is not an application in itself. Instead its code runs as part of another application or as part of an Android system component. This is why XSharedPreferences is called 'shared'.
It depends on what your module is doing and when/where/how the code of you module runs, which solution is best.
Note that using XSharedPreferences isn't the holy grail either, as this solution might stop working in Android "L", because of new SELinux rules (which could affect quite some modules).
Click to expand...
Click to collapse
Basically my module hook an Intent method, but I need a way to pass for the module the package name that it should look, and the package Ill get in a broadcast reciever, so, how can I pass a simple String variable for the module?? I understand what you said but still no clue to how to pass a variable from a reciever to the module itself.
caioketo said:
Basically my module hook an Intent method, but I need a way to pass for the module the package name that it should look, and the package Ill get in a broadcast reciever, so, how can I pass a simple String variable for the module?? I understand what you said but still no clue to how to pass a variable from a reciever to the module itself.
Click to expand...
Click to collapse
You can hook Intents at different places, which makes a difference, since this could be either within an application or within an Android component. Hooking within an application makes this simpler, since you will probably be able to use the application context to communicate.
Basically you can use some form of shared storage to pass information (which is what XSharedPreferences does) or inter process calls. Example of IPCs are intents and services, both if which require a proper Context instance to work.
The bottom line is that you first need to understand from where to where you need to communicate.
I am aware that I am not very concrete about what to do. You could take a look at the implementation of XSharedPreferences, which isn't very difficult to understand, or how for example XPrivacy does this, which is more difficult to understand: https://github.com/M66B/XPrivacy (basically the PrivacyManager class is used to fetch settings from a service implemented in PrivacyService class and running within Android).
But what you said about the XSharedPreferences, that it could possible stop working on L, makes me not wanting to use it, so here is my hook code:
findAndHookMethod("android.os.Bundle", loadPackageParam.classLoader, "getString", String.class, new XC_MethodHook() {
@override
protected void afterHookedMethod(MethodHookParam param) throws Throwable {
if (getExtra(loadParam.packageName)) {
String key = (String) param.args[0];
String value = (String) param.getResult();
getExtrasToSend().putString(key, value);
}
}
});
Basically it will grab every call to getExtras, of all packages, and when it get called it should check if the package that called, is the one I'm looking for (from the reciever part), I got 2 ideas, first one I'm testing right now, is I get a class wich holds a static field and method to the packageName variable, and I'm calling it with: (String)XposedHelpers.callMethod(Util.class, "getPackageName", null);
probably wont work, and I was thinking about hooking the method of my own reciever to get the variable in the module class, and use as static variable there.
Any of these should work? Is there a better way to make it??
caioketo said:
But what you said about the XSharedPreferences, that it could possible stop working on L, makes me not wanting to use it, so here is my hook code:
findAndHookMethod("android.os.Bundle", loadPackageParam.classLoader, "getString", String.class, new XC_MethodHook() {
@override
protected void afterHookedMethod(MethodHookParam param) throws Throwable {
if (getExtra(loadParam.packageName)) {
String key = (String) param.args[0];
String value = (String) param.getResult();
getExtrasToSend().putString(key, value);
}
}
});
Basically it will grab every call to getExtras, of all packages, and when it get called it should check if the package that called, is the one I'm looking for (from the reciever part), I got 2 ideas, first one I'm testing right now, is I get a class wich holds a static field and method to the packageName variable, and I'm calling it with: (String)XposedHelpers.callMethod(Util.class, "getPackageName", null);
probably wont work, and I was thinking about hooking the method of my own reciever to get the variable in the module class, and use as static variable there.
Any of these should work? Is there a better way to make it??
Click to expand...
Click to collapse
Static variables probably won't work, since the settings holder and the settings user probably run in different process spaces. You need either some kind of shared storage or an IPC mechanism to communicate the settings.
Is it possible to use files for that? or database? Im really lost, never work with that yet, and seems that there isnt any explanations on google.
caioketo said:
Is it possible to use files for that? or database? Im really lost, never work with that yet, and seems that there isnt any explanations on google.
Click to expand...
Click to collapse
Shared preferences does use an XML file, so yes. A database is possible too, but you need to make sure both the settings manager and the hook do have access to it, same as with using (XML) files. You'll need to take care of locking too, since multiple process will access the file or database.
M66B said:
Shared preferences does use an XML file, so yes. A database is possible too, but you need to make sure both the settings manager and the hook do have access to it, same as with using (XML) files. You'll need to take care of locking too, since multiple process will access the file or database.
Click to expand...
Click to collapse
I have broadcast receivers in my settings activity and my xposed module so they can communicate with each other. You need to setup your receiver in the xposed side programatically:
Code:
Context context = (Context)XposedHelpers.getObjectField(param.thisObject, "mContext");
IntentFilter filter = new IntentFilter();
filter.addAction(XposedReceiver.RESET_ACTION);
filter.addAction(XposedReceiver.REFRESH_ACTION);
context.registerReceiver(mBroadcastReceiver, filter);
The problem is that I'm hooking the Intent class, and it dont have a context field for me to register the broadcast.
EDIT: I don't think Im being clear of what I need, I need to be able to set someway to send the package name to the module, I'll hook this methods:
findAndHookMethod("android.os.Bundle", loadPackageParam.classLoader, "getString", String.class, new XC_MethodHook() { @override
protected void afterHookedMethod(MethodHookParam param) throws Throwable {
if (loadParam.packageName.equals(PACKAGE_NAME_FROM_BROADCAST) {
String key = (String) param.args[0];
String value = (String) param.getResult();
getExtrasToSend().putString(key, value);
}
}
});
and I need to pass that PACKAGE_NAME_FROM_BROADCAST from a broadcast receiver, dont know the way to make it, tried static variables, xsharedpreferences, etc.
Cant get it working. and I dont know more what to try.
caioketo said:
The problem is that I'm hooking the Intent class, and it dont have a context field for me to register the broadcast.
EDIT: I don't think Im being clear of what I need, I need to be able to set someway to send the package name to the module, I'll hook this methods:
Code:
findAndHookMethod("android.os.Bundle", loadPackageParam.classLoader, "getString", String.class, new XC_MethodHook() {
@override
protected void afterHookedMethod(MethodHookParam param) throws Throwable {
if (getExtra(loadParam.packageName)) {
String key = (String) param.args[0];
String value = (String) param.getResult();
getExtrasToSend().putString(key, value);
}
}
});
and I need to pass that PACKAGE_NAME_FROM_BROADCAST from a broadcast receiver, dont know the way to make it, tried static variables, xsharedpreferences, etc.
Cant get it working. and I dont know more what to try.
Click to expand...
Click to collapse
First of all it is not a good idea to hook into android.os.Bundle, since this will impact the system performance significantly.
Moreover android.os.Bundle is used very frequently in applications and various Android components, meaning your hook will run in a variety of process spaces. Getting a Context in this Xposed hook will therefore often not be possible. If you really want to go this way, a service directly registered with the service manager is your only option, but my advice is to find another, less intrusive, way to do what you want.
Ok, the problem is that, my module needs to grabs all calls to "getExtras" ("getStringExtra", "getBooleanExtra", etc) to know all extras that the application will expect, than I'll pass it to AutoShare app, so you can customize and start an intent with all possible extras.
Is there any other way to grab the extras without hooking the Bundle or Intent? About the perform, its doing nothing if its without the right package, so will it still slow the performance???
Thanks for the repply.
caioketo said:
...
About the perform, its doing nothing if its without the right package, so will it still slow the performance???
Thanks for the repply.
Click to expand...
Click to collapse
A hook never does nothing, since there will always be code executed. The hook you are trying to use will be executed really a lot, so there will be significant performance problem.
The 'bundle' is a general 'message', which is used for a lot of things. You should find a way not to hook into the 'bundle', but into a higher level function.
I have made some progress in finding out whats wrong but no idea how to fix it.
After installing evtest I get the following:
Code:
OpenELEC:~ # cat /proc/bus/input/devices
I: Bus=0005 Vendor=1949 Product=0404 Version=011b
N: Name="Amazon Fire TV Remote"
P: Phys=00:1a:7d:da:71:13
S: Sysfs=/devices/platform/bcm2708_usb/usb1/1-1/1-1.3/1-1.3:1.0/bluetooth/hci0/hci0:71/0005:1949:0404.0001/input/input0
U: Uniq=a0:02:dc:e0:f9:d7
H: Handlers=kbd event0
B: PROP=0
B: EV=10001b
B: KEY=10000 1110 40000800 1681 0 0 0
B: ABS=100 0
B: MSC=10
Code:
OpenELEC:~ # evtest /dev/input/event0
Input driver version is 1.0.1
Input device ID: bus 0x5 vendor 0x1949 product 0x404 version 0x11b
Input device name: "Amazon Fire TV Remote"
Supported events:
Event type 0 (EV_SYN)
Event type 1 (EV_KEY)
Event code 96 (KEY_KPENTER)
Event code 103 (KEY_UP)
Event code 105 (KEY_LEFT)
Event code 106 (KEY_RIGHT)
Event code 108 (KEY_DOWN)
Event code 139 (KEY_MENU)
Event code 158 (KEY_BACK)
Event code 164 (KEY_PLAYPAUSE)
Event code 168 (KEY_REWIND)
Event code 172 (KEY_HOMEPAGE)
Event code 208 (KEY_FASTFORWARD)
Event type 3 (EV_ABS)
Event code 40 (ABS_MISC)
Value 0
Min 0
Max 255
Event type 4 (EV_MSC)
Event code 4 (MSC_SCAN)
Properties:
Property type 20 (EV_REP)
Property code 0 (REP_DELAY)
Value 1000
Property code 1 (REP_PERIOD)
Value 33
Testing ... (interrupt to exit)
***********************************************
This device is grabbed by another process.
No events are available to evtest while the
other grab is active.
In most cases, this is caused by an X driver,
try VT-switching and re-run evtest again.
***********************************************
So something is capturing the input and not letting it go through. Any idea how to fix this?
Just an update. Connected a Bluetooth keyboard and that worked fine and gave the same evtest output saying something else was grabbing the input which would mean that's not the problem with the Amazon remote.
Again, any help is welcomed!
This has been bugging me for the last day or two as well; and to be honest - still is.
The below will work but just seems "wrong" to have to use eventlircd for this...
/storage/.config/eventlircd.d/aftvsremote.evmap
(copy /etc/eventlircd.d to /storage/.config/eventlircd.d)
Code:
KEY_KPENTER = KEY_OK
KEY_UP = KEY_UP
KEY_LEFT = KEY_LEFT
KEY_RIGHT = KEY_RIGHT
KEY_DOWN = KEY_DOWN
KEY_MENU = KEY_EPG
KEY_BACK = KEY_EXIT
KEY_PLAYPAUSE = KEY_PLAY
KEY_REWIND = KEY_REWIND
KEY_HOMEPAGE = KEY_MEDIA
KEY_FASTFORWARD = KEY_FASTFORWARD
/storage/.config/autostart.sh
Bind mount because I'm too lazy to rebuild the openelec squashfs image
Code:
mount --bind /storage/.config/eventlircd.d/ /etc/eventlircd.d/
/storage/.config/udev.rules.d/99-eventlircd.rules
Code:
SUBSYSTEMS=="bluetooth", GOTO="begin-bluetooth"
GOTO="end-bluetooth"
LABEL="begin-bluetooth"
ATTRS{name}=="Amazon Fire TV Remote", \
ENV{eventlircd_enable}="true", \
ENV{eventlircd_evmap}="aftvsremote.evmap"
LABEL="end-bluetooth"
Thank you so much!!! I got a chance to enter the code today and it works perfectly! I had to repair after the initial reboot but it keeps pairing after that for all other reboots. I hope they put this into openelec from here on out.
Again thanks!
Hello,
I've found myself in a situation I can't solve myself, so I hope I can find some help here
In my module, I've got a static field "VERSION_CODE".
In one of my hooks I register a BroadcastReceiver for AfterBootCompleted in which I set the field's value (I use the system Context object).
Then, in handleLoadPackage, when I try to read the field "VERSION_CODE", it has it's default value.
I don't understand this. Are there separate JVMs or something? How do I make that field absolutely global?
If it's a final field (constant) of primitive type (int, boolean, etc.) you won't be able to change it since compiler doesn't use variable but inlines value directly everywhere it's used.
C3C076 said:
If it's a final field (constant) of primitive type (int, boolean, etc.) you won't be able to change it since compiler doesn't use variable but inlines value directly everywhere it's used.
Click to expand...
Click to collapse
It isn't declared final.