Hi Briglia, On Tue, Jul 19, 2011 at 11:34 AM, Anderson Briglia <anderson.briglia@xxxxxxxxxxxxx> wrote: > Hi Claudio, > > On Mon, Jul 18, 2011 at 2:35 PM, Claudio Takahasi > <claudio.takahasi@xxxxxxxxxxxxx> wrote: >> Delegates the Immediate Alert Level control to the caller(client). >> Immediate Alert Service is shared between Path Loss and Find Me. >> >> Cons: distributed actions may impact qualification. Client needs to >> control when to write the Immediate Alert based on the received >> SignalLevel received. >> --- >> >> I'd like to collect feedbacks before proceeding with this change. >> Does it look more clear than the previous API version? >> >> The ideia is to move to the kernel the RSSI value polling. The >> userspace will receive notifications when one of the SignalLevel >> threshold is triggered: "good", "regular", "week". > > How about simplify more and have just two alert levels? Is there any > reason to have three? It could simplify the RSSI Monitor in the > kernel. > > Regards, > > Anderson Briglia Choosing two levels only, clients will not be able to map directly the 3 alert levels values of the Immediate Alert Characteristic: none, mild, high. My suggestion is to implement the following mapping: good->none regular->mild weak->high Of course, based on the proposal of delegating the write operation(SetProperty) to the client, it up to the client to choose when and which alert level to use. Clients could also consider the selected phone profile(eg: silent, meeting, normal) also to choose the alert level. Resuming, I don't have a strong argument to have 3 levels, I defined 3 to simplify the mapping of immediate alert level characteristic. But this is implementation specific. Regards, Claudio. -- 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
