2855 replies to this topic

[ejtagle]

Scanno, on 27 November 2012 - 09:24 PM, said:

I am also seeing this:

21:30:09.281 Info bluedroid 803 enable
21:30:09.281 Debug bt-btif 803 BTIF ENABLE BLUETOOTH
21:30:09.293 Debug bt-btif 803 bte_main_enable
21:30:09.317 Info bt_hci_bdroid 803 init
21:30:09.317 Error bt_hw 803 !!! Failed to load libbt-vendor.so !!!
21:30:09.317 Info bt-btif 803 libbt-hci init returns 0
21:30:09.317 Error bt_hci_bdroid 803 vendor lib is missing!
21:30:09.317 Error bt_hci_bdroid 803 vendor lib is missing!
21:30:09.317 Info bt_hci_bdroid 803 bt_hc_worker_thread started
21:30:09.317 Error bt_userial 803 userial_open: missing vendor lib interface !!!
21:30:09.317 Error bt_userial 803 userial_open: unable to open UART port
21:30:09.317 Info bt-btif 803 HC preload_cb 1 [0:SUCCESS 1:FAIL]
21:30:09.329 Debug bt-btif 803 btif_task: received trigger stack init event
21:30:11.348 Debug BluetoothAdapterService 1107362040 getState(): mAdapterProperties: com.android.bluetooth.btservice.AdapterProperties@42011a20

I am guessing we need to get libbt-vendor.so sources from somewhere....

We have those sources, if thats the problem! -- https://groups.googl...V7GXLZza0MJ��-- I'll see if something is needed ... AR6002 bt module does not need firmware to make it work, so this lib should be nearly trivial to implement...

If you look at the places suggested at that post, you will find the definitions tor bluetooth for each supported device...

Edited by ejtagle, 28 November 2012 - 04:14 AM.

[Scanno]

ejtagle, on 28 November 2012 - 04:06 AM, said:

We have those sources, if thats the problem! -- https://groups.googl...V7GXLZza0MJ��-- I'll see if something is needed ... AR6002 bt module does not need firmware to make it work, so this lib should be nearly trivial to implement...

If you look at the places suggested at that post, you will find the definitions tor bluetooth for each supported device...

Thanks for the link. Will have a look at it.  Hopefully I can find an implementation for the ar6002 that can be added to the device config.

Oh and 4.2.1 is out if yo did not know already.

EDIT:
Am I right in the assumption that atheros is part of Qualcomm? And us such we can use the Qualcomm implementation of the lib and add the line
BOARD_HAVE_BLUETOOTH_QCOM := true

To the board config. It should then compile the Qualcomm BT vendor lib if it is added to the device config (if it is not already part of the android download)


EDIT 2:
OK looks like it is part of the standard android repo. So it is just a matter of adding the line to the boardconfig. Can anybody confirm that Atheros = Qualcomm ?

Edited by Scanno, 28 November 2012 - 02:30 PM.

[ejtagle]

Scanno, on 28 November 2012 - 11:30 AM, said:

Thanks for the link. Will have a look at it.  Hopefully I can find an implementation for the ar6002 that can be added to the device config.

Oh and 4.2.1 is out if yo did not know already.

EDIT:
Am I right in the assumption that atheros is part of Qualcomm? And us such we can use the Qualcomm implementation of the lib and add the line
BOARD_HAVE_BLUETOOTH_QCOM := true

To the board config. It should then compile the Qualcomm BT vendor lib if it is added to the device config (if it is not already part of the android download)


EDIT 2:
OK looks like it is part of the standard android repo. So it is just a matter of adding the line to the boardconfig. Can anybody confirm that Atheros = Qualcomm ?

Even if they are not, most bluetooth chipsets use the same protocol (HCI), so probably it will work... or require very small adjustments... -- But it would not hurt to make sure baudrate and serial port are the ones expected ...

Edited by ejtagle, 28 November 2012 - 05:26 PM.

[ejtagle]

ejtagle, on 28 November 2012 - 05:09 PM, said:

Even if they are not, most bluetooth chipsets use the same protocol (HCI), so probably it will work... or require very small adjustments... -- But it would not hurt to make sure baudrate and serial port are the ones expected ...

Guess i spoke too soon.. Qualcomm bt libs will not work with our chip... Probably, the broadcom ones are much closer to what we need...

[ejtagle]

The only way to make our bt chipset work with bluedroid, is to write a new lib for it... Basically, the bluedroid lib can use it through its HCI H4 driver, but our chip requires previous initialization ... That is what the hciattach utility did, but now we cant use it... I am working in porting the init code found in hciattach to the new required lib, but it will take some time... :S

[Scanno]

ejtagle, on 30 November 2012 - 02:31 AM, said:

The only way to make our bt chipset work with bluedroid, is to write a new lib for it... Basically, the bluedroid lib can use it through its HCI H4 driver, but our chip requires previous initialization ... That is what the hciattach utility did, but now we cant use it... I am working in porting the init code found in hciattach to the new required lib, but it will take some time... :S

Thanks in advance for the effort. Hopefully it is not too much work.
I am still trying to get the backlight control working. Using the changes in the overlay did not work for me. But i will try some more combinations in the overlay config xml files.

[ejtagle]

Scanno, on 30 November 2012 - 07:51 AM, said:

Thanks in advance for the effort. Hopefully it is not too much work.
I am still trying to get the backlight control working. Using the changes in the overlay did not work for me. But i will try some more combinations in the overlay config xml files.

The same thing relatedto backlight control happened to me with the n10 lunch target i was working with. The only thing required to make it work was to adjest the overlay entries with the ones i pasted here. There is an easy way to check if the lights module is properly loadingand being used: When androids boots, when the androd logo starts to roll, at nearly the end of the process, the backlight dims a bit... This happenede with the previous android versions and also happens with the new ones. If it does not dim, as it did on previous versions, there is something wrong with the lights module. If it dims, the problem is in the overlay...

[Scanno]

ejtagle, on 01 December 2012 - 03:56 PM, said:

The same thing relatedto backlight control happened to me with the n10 lunch target i was working with. The only thing required to make it work was to adjest the overlay entries with the ones i pasted here. There is an easy way to check if the lights module is properly loadingand being used: When androids boots, when the androd logo starts to roll, at nearly the end of the process, the backlight dims a bit... This happenede with the previous android versions and also happens with the new ones. If it does not dim, as it did on previous versions, there is something wrong with the lights module. If it dims, the problem is in the overlay...

Thanks for the hint. lights.shuttle.so was not being build because of a := instead of a +=
Backlight working fine now.

Edited by Scanno, 01 December 2012 - 08:41 PM.

[ejtagle]

Well... there good and bad news regarding bluetooth... As you know, bluedroid stack has replaced BlueZ stack as the main bluetooth stack on Android. This has several implications... Bluedroid was written by Broadcom, so, as you could imagine, there is essentially no support on it for other bluetooth solutions, such as all CSR chips out there (that use a USART protocol called BCSP). BCSP is the BlueChip Serial protocol, and it is used by some bluetooth chipsets such as the one the Shuttle is using..   ..
The stack supports an older protocol called H4, that is the one used by Broadcom. Even worse, in the original Bluez stack, the Bluetooth protocol (BCSP, or H4, or...) was / is implemented in kernel space, and also the power management of the chip, but in the new stack (Bluedroid), all the UART protocols are implemented in the stack itself... So, the bluetooth UART protocol implemented in kernel is not used at all...
There is some things missing in the bt stack (BT4.0 can't be enabled, as there are missing files!) .. What i fear is that this is a move to favour Broadcom some way.... Implementing their chip solutions is straightforward, but implementing all the other bluetooth chipsets usually requires reimplementing a lot of the stack code... I guess Broadcom even will license the complete stack, instead of the incomplete one we are given through AOSP to those manufacturers that use their chips...
I will see what can i do about BCSP on the bluedroid stack...

[ejtagle]

Well, an update on the bluedroid stack.... I've been lately toying with 2 alternate solutions, both seem to be feasible:
1) Write a new module to implement the bcsp protocol, then add a libbt-vendor that instanciates that module... That would keep the all-in-userspace feature of the bluedroid stack, and would allow us to use a CSR bluetooth chipset.
2) The other possibility is to write a new module for the bluedroid stack that uses the linux kernel bluetooth subsystem (that is already implementing all the usart protocols we need, inclusing BCSP)... This is also perfecly possible, and would move a part of the processing (the usart protocol) to kernel space. That is the way blueZ works (uses the kernel bluetooth subsystem, instead of implementing it in userland, as bluedroid does). Yes, even if broadcom tells otherwise, i think it is more clean to use the linux kernel bluetooth subsystem, and would allow more bluetooth devices to work with bluedroid.

My personal opinion on BlueZ compared to bluedroid is that BlueZ is a far more clean and documented piece of code that bluedroid. By just looking at the bluedroid stack, you will find it to be of less quality than BlueZ.. The only explanation i find for this switch is that Google either has a cooperation agreement with Broadcom, or they just don't want to maintain and update the blueZ stack, and it was easier to switch to the supposedly more complete Broadcom supplied one...

I really don't care about the reasons, I really don't care if we need to hack the bluedroid stack to interface with CSR. Just, I would like that the chosen approach let us use the bluedroid stack with the CSR chips... And, the broader chip compatibility we could get, the better.

I think that i will write the module that interfaces to the linux bluetooth subsystem. I think it is the best approach here. And, as an added bonus, this would also allow us to continue using the hciattach tool that is part of the blueZ stack... ... badword you Broadcom! (badword = censored word... I really hate when there is no apparent reason for the switch besides "lack of knowledge" ... or maybe commercial reasons, and that decision does not bring us any advantage, except a lot of work to port to the new stack ,,, :S :S )

Any thoughts or suggestions or good reasons not to proceed with this solution (or reasons to proceed with it) are welcome!

Edited by ejtagle, 07 December 2012 - 03:07 AM.

[Scanno]

ejtagle, on 07 December 2012 - 03:02 AM, said:

Well, an update on the bluedroid stack.... I've been lately toying with 2 alternate solutions, both seem to be feasible:
1) Write a new module to implement the bcsp protocol, then add a libbt-vendor that instanciates that module... That would keep the all-in-userspace feature of the bluedroid stack, and would allow us to use a CSR bluetooth chipset.
2) The other possibility is to write a new module for the bluedroid stack that uses the linux kernel bluetooth subsystem (that is already implementing all the usart protocols we need, inclusing BCSP)... This is also perfecly possible, and would move a part of the processing (the usart protocol) to kernel space. That is the way blueZ works (uses the kernel bluetooth subsystem, instead of implementing it in userland, as bluedroid does). Yes, even if broadcom tells otherwise, i think it is more clean to use the linux kernel bluetooth subsystem, and would allow more bluetooth devices to work with bluedroid.

My personal opinion on BlueZ compared to bluedroid is that BlueZ is a far more clean and documented piece of code that bluedroid. By just looking at the bluedroid stack, you will find it to be of less quality than BlueZ.. The only explanation i find for this switch is that Google either has a cooperation agreement with Broadcom, or they just don't want to maintain and update the blueZ stack, and it was easier to switch to the supposedly more complete Broadcom supplied one...

I really don't care about the reasons, I really don't care if we need to hack the bluedroid stack to interface with CSR. Just, I would like that the chosen approach let us use the bluedroid stack with the CSR chips... And, the broader chip compatibility we could get, the better.

I think that i will write the module that interfaces to the linux bluetooth subsystem. I think it is the best approach here. And, as an added bonus, this would also allow us to continue using the hciattach tool that is part of the blueZ stack... ... badword you Broadcom! (badword = censored word... I really hate when there is no apparent reason for the switch besides "lack of knowledge" ... or maybe commercial reasons, and that decision does not bring us any advantage, except a lot of work to port to the new stack ,,, :S :S )

Any thoughts or suggestions or good reasons not to proceed with this solution (or reasons to proceed with it) are welcome!

Eduardo,
I am just very happy that you want to try getting BT working on our devices. If i understand correctly, you want to interface the Bluedroid API with the kernel bluetooth subsystem?

I think it could be the best solution, using the parts that we know work.

[Scanno]

I do not know what i am doing wrong. I am trying to get the multi-user stuff working. Overlay is correct and the multi-user is added. I just cannot get the sdcard to mount correctly. I have used the values from the init.grouper.rc (EXTERNAL-STORAGE, EMULATED-STORAGE-SOURCE and EMULATED-STORAGE-TARGET). I also experimented with the values and with vold.fstab to mount the sdcard on several directories, but the /0/ directories are not added to the sdcard. I have been trying for a few days but no luck so far.

The grouper has the internal sdcard as virtual sdcard. In the init.grouper.rc the virtual sdcard is mounted to /mnt/shell/...

If i set vold.fstab to mount the sdcard to that directory it does not get mounted. I am lost. Anyone have ideas?

[ejtagle]

Scanno, on 07 December 2012 - 12:22 PM, said:

Eduardo,
I am just very happy that you want to try getting BT working on our devices. If i understand correctly, you want to interface the Bluedroid API with the kernel bluetooth subsystem?

I think it could be the best solution, using the parts that we know work.

Yes, that is exactly the idea... Careful inspection of the bluedroid stack shows that this stack was written for an embedded system, where there is no kernel support for bluetooth (bare-bones embedded systems are like that... And probably, that was a good decision on Broadcom side, as they were licensing the stack to virtually anyone using their chips, and the stack does not target a given OS... Under linux, the OS is the one that should handle differences between hardware, and expose a unified view to the user space. That is why the bluetooth low level protocol (the communication to the chip) is done at kernel level.. and the chip is exposed to user space as a network adapter... Makes pretty good sense to me..  So, i think interfacing bluedroid to that subsystem can be the way to do it... I will try to test this!

[ejtagle]

Scanno, on 07 December 2012 - 08:53 PM, said:

I do not know what i am doing wrong. I am trying to get the multi-user stuff working. Overlay is correct and the multi-user is added. I just cannot get the sdcard to mount correctly. I have used the values from the init.grouper.rc (EXTERNAL-STORAGE, EMULATED-STORAGE-SOURCE and EMULATED-STORAGE-TARGET). I also experimented with the values and with vold.fstab to mount the sdcard on several directories, but the /0/ directories are not added to the sdcard. I have been trying for a few days but no luck so far.

The grouper has the internal sdcard as virtual sdcard. In the init.grouper.rc the virtual sdcard is mounted to /mnt/shell/...

If i set vold.fstab to mount the sdcard to that directory it does not get mounted. I am lost. Anyone have ideas?

Maybe a permission thing... On the N10, it worked out of the box. Remember the data partition is on nand, not on SD... Unless we natively mount the sdcard, it wont work... And, SDcard takes some time to be recognized... Maybe adding a bootdelay=2 in the kernel command line could help here?

[Borkata]

Scanno, on 07 December 2012 - 08:53 PM, said:

I do not know what i am doing wrong. I am trying to get the multi-user stuff working. Overlay is correct and the multi-user is added. I just cannot get the sdcard to mount correctly. I have used the values from the init.grouper.rc (EXTERNAL-STORAGE, EMULATED-STORAGE-SOURCE and EMULATED-STORAGE-TARGET). I also experimented with the values and with vold.fstab to mount the sdcard on several directories, but the /0/ directories are not added to the sdcard. I have been trying for a few days but no luck so far.

The grouper has the internal sdcard as virtual sdcard. In the init.grouper.rc the virtual sdcard is mounted to /mnt/shell/...

If i set vold.fstab to mount the sdcard to that directory it does not get mounted. I am lost. Anyone have ideas?

I am trying to fix this on Adam tablet for a whole week and still no success. Problem is that once sdcard daemon is trying to create the /mnt/shell/emulated/0 which is in rootfs / is mounted as ro already.
@eduardo do you have an advice where sdcard should be started or how to leave rootfs mounted as rw, since later during creation of new user its creating a new dir?

[Scanno]

Borkata, on 08 December 2012 - 06:58 AM, said:

I am trying to fix this on Adam tablet for a whole week and still no success. Problem is that once sdcard daemon is trying to create the /mnt/shell/emulated/0 which is in rootfs / is mounted as ro already.
@eduardo do you have an advice where sdcard should be started or how to leave rootfs mounted as rw, since later during creation of new user its creating a new dir?

So basically you have the same problem i have..
You can leave rootfs as rw by commenting the remount in init.rc i think. But somehow i do not think it would solve the problem.

[Borkata]

Scanno, on 08 December 2012 - 08:19 AM, said:

So basically you have the same problem i have..
You can leave rootfs as rw by commenting the remount in init.rc i think. But somehow i do not think it would solve the problem.

Actually I have done some experiments remounting after boot and actually different users has folders in /data/media/ and pictures and other media are stored on data partition and in my case I have internal sd and external sd So my setup should be little different.

Edited by Borkata, 08 December 2012 - 11:06 AM.

[LeoP]

ejtagle, on 07 December 2012 - 03:02 AM, said:

I think that i will write the module that interfaces to the linux bluetooth subsystem. I think it is the best approach here. And, as an added bonus, this would also allow us to continue using the hciattach tool that is part of the blueZ stack...

...

Any thoughts or suggestions or good reasons not to proceed with this solution (or reasons to proceed with it) are welcome!

ejtagle,

while I am a newbie and definitly not in a position to give advice to the gurus, I think this definitly is the way to go:

- I suspect such a work can enable BT for 4.2 not only on the Vega and relatives, but on lots of devices

- Kernel agnosticy is of no importance for Android. I consider it a misfeature - code duplication on a really stupid scale

- The possibility to use the hci tools will help porting lots of hack-scripts out there, that may not be beautifull, but scratch some dev's itch

[Borkata]

Scanno, on 08 December 2012 - 08:19 AM, said:

So basically you have the same problem i have..
You can leave rootfs as rw by commenting the remount in init.rc i think. But somehow i do not think it would solve the problem.

I have fixed it already. You can check last commit at https://github.com/n...on/tree/jb-aosp

Btw do you have mic workin?

Edited by Borkata, 10 December 2012 - 09:51 AM.

[ejtagle]

Well, i am still investigating Bluedroid stack. Not only the serial protocol (BCSP or H$) is handled in userspace.. Seems all the scheduling of packets is handled in userspace. Bluez handles packet routing in kernel, allowing much more separation between servers (a2dp, internet sharing, etc)... Even, if there is a way to plug the datastream in bluedroid from the bluetooth stack in kernel (i already have a half written module...), i think that using bluedroid will be a huge step back regarding CSR support... Bluez has several workarounds in place to support most bluetooth chipsets out there, not only in kernel space, but also in the bluez daemon itself. Bluedroid has none of those: Has only workarounds for the broadcom chipset. Right now, i am not sure if it is a good move to go the bluedroid way, as i see no significant advantage: Instead of those, i see lots of problems supporting chipsets not manufactured by broadcom.. Lately, i have been thinking about reverting what Google did, and re-port bluez as the main android stack. All the things you could read about the supposed advantages bluedroid has, is not applying to CSR chips. Reverting to the bluez stack wont make apps incompatible with the resulting JB4.2 ... The supposed advantage of writing new extensions for bluedroid Google is advocating, are not true, as user apps can't directly link to the stack binaries... Well, i am now also considering this approach...