Can we create devices not backed by sysfs?

Kay Sievers kay.sievers at vrfy.org
Fri Aug 8 00:33:34 PDT 2008


On Wed, Aug 6, 2008 at 13:52, Richard Hughes <hughsient at gmail.com> wrote:
> I need to know if DeviceKit(-power) can, and should, support virtual
> devices that are not backed by a DevkitDevice. For instance:
>
> I have a laptop with two batteries. Each one reports the charge in
> percentage and the time remaining to discharge.
>
> To find out the percentage, we have to average both percentages, and
> also have to perform some clever maths on the time remaining taking into
> account the different battery capacities. This is something I currently
> do in g-p-m, but ideally want to move all the clever maths and stats
> down into DeviceKit.
>
> For this I need a battery of type "virtual" which is aware of the other
> batteries in the system but is a virtual statistical model of a single
> laptop battery.
>
> This sort of thing is going to be needed by the UPS and mice devices
> too, as they are not exposed in sysfs. Ideas? Crack?

I think it's up to the subsystem daemon to provide such a thing. We
really need meta device information like this.

We will likely not stick things like this into any common dk
infrastructure, but keep them in the subsystem daemons. I expect there
will be no such thing as we have in hal today to dump "all" known
devices with all properties from all subsystems. I also don't expect,
that we we will have a global property matching/merging/fdi
device-store thing, it will likely all just end up in the subsystems
daemons as their private implementation which fits just their specific
need.

We should make sure, that the meta-device is properly exposed in the
D-Bus interfaces of the subsytem. In some cases, like here for
dk-power, the "meta-device" might even just be the primary interface,
and not look like an additional device in some list. The real devices,
which feed the data into the meta-device, would be just additional
information, that can be requested for further details.

Thanks,
Kay


More information about the devkit-devel mailing list