Hi Claudio, > >> >>> if TX power is only read once than the kernel should just do it once > >> >>> and > >> >>> be done with it. > >> >>> > >> >>> And for RSSI, it would be better if the kernel read this periodically > >> >>> based on current sniff mode etc. Userspace can not trigger this with > >> >>> proper timing anyway. And it will potentially at some point start > >> >>> blocking the controller. Only the kernel really knows when it is > >> >>> acceptable to read the RSSI value. > >> >> > >> >> Reading the RSSI by the kernel, will force a certain limitation on the > >> >> current and future Profiles. I believe setting the timing should be done > >> >> by the profile itself, not the bluez user space code or the kernel. It > >> >> is the responsibility of the profile to periodically poll the RSSI Level. > >> >> For some cases, polling it every 5 seconds would be ok, and for some > >> >> Others, it may be better to read it every second. I believe we must not > >> >> impose any limitation here. > >> > > >> > You probably forgot that besides bluetoothd there should be no other > >> > application holding the mgmt socket, so not you can't really do it in > >> > poll in the application side and doing it over D-Bus is overkill. Also > >> > I notice that from some parties, you include, there is some tendency > >> > to have the profiles split from the bluetoothd, IMO this will only add > >> > fragmentation with each and every platform using BlueZ having their > >> > own implementation of each profile and not sharing much, making the > >> > IOP a complete mess. > >> > > >> > >> Some additional comments... > >> > >> Health plugin will need a similar approach to read the clock. It will > >> be good to implement the same approach. > >> In our suggested implementation the adapter controls when to send the > >> command to read the RSSI, keeping the same logic for both: hciops and > >> mgmtops. If the adapter is managing when to send the commands, > >> repeated commands can be avoided, multiple callbacks can be registered > >> by the profiles, but only one command to read the RSSI will be sent. > >> The cover letter of the userspace patches contains more details how we > >> implemented it. > >> > >> Reading the RSSI directly by the kernel will break hciops. These are > >> the arguments that I have to support our decision. > > > > what I am hearing is that we want the kernel to poll for certain > > information if userspace needs them. And either it is a one-shot poll or > > it is on a regular interval. > > If everybody agree we can do it. Our objective is to have the patches upstream. > To keep the Proximity Monitor functional on both adapter_ops plugins > we can move part of the logic from the adapter.c to the hciops. The > polling to read the RSSI can be moved to hciops, in the management the > polling will be in the kernel. The remaining code to register the > callbacks doesn't need to be changed. > Do you agree? I am really open for suggestion, but just duplicating HCI is not going to cut it. We have to be a lot smarter with the kernel mgmt interface. So lets give this approach and go and see how it works out. And btw. I do not care about the hciops that much anymore. If you wanna do the hard work to make it work, fine with me. > > The management interface will be primarily used by bluetoothd, but it is > > open for other users as well. Mainly some low-level system tools or more > > important qualification tools. > > > > So triggering certain actions from userspace is always tricky and then > > we need to have bluetoothd sync with itself, its plugins etc. So I > > rather prefer that we tell the kernel which pollable information to read > > at which interval and then just get a notification if they have changed. > > Let the kernel do its job without having to wakeup half of userspace to > > make a simple decision to poll a value. > > > > And don't get me wrong, the stupid Bluetooth chip should be able to poll > > this value with an interval natively. The best we can do is emulate that > > in the kernel. > > No problem. We will change the code and send another RFC. > Do you want another channel in the BTPROTO_HCI socket or keep > everything inside HCI_CHANNEL_CONTROL? It is an async event on HCI_CHANNEL_CONTROL. That is good enough for me. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
