hi Tomasz, On Mon, Oct 1, 2012 at 12:20 PM, Tomasz Bursztyka < tomasz.burszt...@linux.intel.com> wrote:
> Hi Alok, > > But you might not even have drivers for it, so it won't be possible to get >>> > it enabled (my patches does not fix that issue anyway, there is an >>> issue to >>> > solve here) >>> > And #3 because API 1.0 does not propose anything about that. >>> > >>> >> Cant we just return an different error for hard blocked ? the UI can >> interpret the state acc to the error then. >> > It changes the API 1.0 a bit then. And I consider that a hw rfkilled > technology is not an error: it's a configuration issue (see my previous > mail about it, what could be done for 2.0). > On the contrary, raising an error due to lack of backend and/or driver > could make sense (but then again: being not exposed could also be the > solution here: then it's up to distro > maintainer to fix the issue... And simplify a lot the UI also ;) ). > > I think we definitely need to show the list of available technologies irrespective of hard block/unblock. its worse if we dont innumerate the technology if its hard blocked. the user would be confused about not seeing any wifi tech even though he knows there is wifi on his desktop/laptop. I agree that Giving hardblocked state info to the UI would mean API change. so a diff error might be a work around. ust my 2 cents. > What's your opinion about that Marcel? Tomasz > > Cheers, Alok. > ______________________________**_________________ > connman mailing list > connman@connman.net > http://lists.connman.net/**listinfo/connman<http://lists.connman.net/listinfo/connman> > _______________________________________________ connman mailing list connman@connman.net http://lists.connman.net/listinfo/connman
