Hi,
While playing around with enabling/disabling technology I found out that if a
technology is hardblocked through the physical switch,
first the technology is still listed in GetTechnologies, but of course enabling
it
from dbus API will lead to nothing. User HAS to play with the physical switch.
In order not to mess up the user with it, patch 1 and 2 make so a technology is
not given to the user if it's hardblocked.
So if a technology is shown and disabled: it's just soft block. user can change
that through dbus api.
Technically, this means not registering the technology as a dbus object. And
hardblock on will throw TechnologyRemoved(), and
hardblock off a TechnologyAdded().
Patch 3 is cleaning up the rfkill ghashtable, so it goes the same line as other
part of connman.
Patch 4 is a bit tricky: Some hardware/drivers do some weird thing with rfkill:
having 2 or more rfkill entities for 1 type (wifi for instance)
which reacts in cascading changes on each other. So soft blocking the
technology, will put of these to hardblock on (without any physical switch
touched). I noticed that a real physical hardblock puts all these rfkill
entities to the same value.
So this patch takes care of that: if all rfkill entities from the same
technology type are not on the line about hardblock: we do not count
this technology as hardblock.
I tested it on a good and bad hw: works fine. Playing also around offlinemode
and enabling/disabling (soft blocking) or physical switch.
Please review,
Tomasz Bursztyka (4):
technology: Add helpers when (un)registering a technology in dbus
technology: Apply rfkill hardblock relevantly
technology: Handle rfkill hash table in a saner way
technology: Handle harblock if only all are identical for the same
rfkill type
src/technology.c | 123 +++++++++++++++++++++++++++++++++++++++++--------------
1 file changed, 93 insertions(+), 30 deletions(-)
--
1.7.12
_______________________________________________
connman mailing list
[email protected]
http://lists.connman.net/listinfo/connman
