Import hildon-status-bar-usb

[MerlijnWajer]

https://github.com/community-ssu/hildon-status-bar-usb

[MerlijnWajer]

Likely won't work out of the box, since it requires HAL?

[MerlijnWajer]

Most of the info we need is (for N900 anyway) at least in /sys: "/sys/devices/platform/68000000.ocp/480ab000.usb_otg_hs/musb-hdrc.0.auto/udc/musb-hdrc.0.auto"

Not sure if there is still a hw abstraction layer for this?

[MerlijnWajer]

Relevant hal code, linked by Pali: https://github.com/community-ssu/hal/blob/master/hald/linux/addons/addon-usb-cable.c

Relevant files in /sys:

/sys/devices/platform/68000000.ocp/48070000.i2c/i2c-1/1-0048/48070000.i2c:twl@48:twl4030-usb/vbus (udev also triggers on this!)

(off,on) - detect if anything is powering n900

/sys/devices/platform/68000000.ocp/480ab000.usb_otg_hs/musb-hdrc.0.auto/mode

(at least) b_idle, b_peripheral -- b_idle is when (I think) no computer is detected, e.g. dumb storage. b_peripheral shows up when I connect to my laptop.

[MerlijnWajer]

Wonder how we should handle this. Do we create a simple dbus tool for this, providing what hal used to provide?

We can also hardcode these paths now, but that won't work for other devices.

[MerlijnWajer]

@freemangordon - any thoughts?

[freemangordon]

Maybe we should have device specific dbus battery service and common applet that just uses it. I doubt we'll be able to have code that works on all the devices. We may also check what GNOME power manager does.

[freemangordon]

we should check https://bazaar.launchpad.net/~indicator-applet-developers/indicator-power/trunk.16.10/files as well

[MerlijnWajer]

@freemangordon - I think I confused you, this is for usb cable status, not about battery. I'll see what gnome power manager does for batteries, but I am pretty sure it just uses upower, which means it's also broken for our devices. I will look why UPower is so bad later.

[MerlijnWajer]

https://bazaar.launchpad.net/~indicator-applet-developers/indicator-power/trunk.16.10/view/head:/src/device-provider-upower.c#L29 seems to use the 'display' device invented by UPower, which also gives bad values, because I think it is averaging all the 'batteries'. Let's pick this up on #67

[MerlijnWajer]

Just to summarise my question about usb status -- we should figure out if we want to provide some daemon for querying the device status, say, over usb, or just some library to watch/poll it. If we do that, we should also consider how to do if for specific devices. Droid4 also has similar sysfs files, and the vbus we might be able to just find via sys, but I am not so sure about musb.

So:

(1) Write a piece of code/library that uses libudev and poll(2) to watch for vbus changes and then read mode (b_idle, etc) and act on it - for now only for N900 and extend it asap
(2) Like (1), but turn it into dbus daemon and have hildon-status-bar-usb listen on dbus events from this daemon.

Both implementations will likely need some device specific paths.

[freemangordon]

right, it is not you confusing me, it is myself confusing me, too much things around are distracting :). However, my stance for having per-device provider stays the same - I doubt we'll be able to have a universal piece of code.

[MerlijnWajer]

I will hack up some code that will be shared by (1) and (2) later, and then we can figure out how to do the device specific paths.

[MerlijnWajer]

On the droid4 the paths are like this:

/sys/devices/platform/44000000.ocp/4a0ab000.usb_otg_hs/musb-hdrc.0.auto/vbus
/sys/devices/platform/44000000.ocp/4a0ab000.usb_otg_hs/musb-hdrc.0.auto/mode (b_idle - powered or no cable, a_idle (otg cable), probably also b_peripheral..., and something for host mode that works)

[MerlijnWajer]

The N900 also has /sys/devices/platform/68000000.ocp/480ab000.usb_otg_hs/musb-hdrc.0.auto/vbus, but reading that causes panics for me on the current kernel.

[MerlijnWajer]

@parazyd We probably want CONFIGFS enabled for our kernels -- CONFIG_USB_CONFIGFS and CONFIG_USB_CONFIGFS_MASS_STORAGE ; etc

[MerlijnWajer]

Or at least make g_nokia not =y

[MerlijnWajer]

There's a possible fix for the vbus issue: https://marc.info/?l=linux-omap&m=151950561123649&w=2

[MerlijnWajer]

(It works for me)

[MerlijnWajer]

I have the udev code pretty much ready (can replace hal code).

One of these (or both) seem usable/nice:

https://github.com/libusbg/libusbg
https://github.com/kopasiak/gt

This will depend on configfs, but our current n900 kernels are already configfs enabled.

[MerlijnWajer]

I have prepared very basic version for importing, many things remain to be done.

[MerlijnWajer]

https://github.com/maemo-leste/hildon-status-bar-usb

maemo-leste/hildon-status-bar-usb@fca950f

[MerlijnWajer]

TODO is listed here: https://github.com/maemo-leste/hildon-status-bar-usb/blob/master/udev-helper.c#L14

[MerlijnWajer]

@meridion - do you want to pick this up?

[MerlijnWajer]

The code here (linked before) can be useful if we want to match the exact modes: https://github.com/community-ssu/hal/blob/master/hald/linux/addons/addon-usb-cable.c

[MerlijnWajer]

Pali suggested using this interface on the n900 for detecting what kind of charger is connected:

root@n900devuan:/sys/devices/platform/isp1707/power_supply/isp1704# cat uevent
POWER_SUPPLY_NAME=isp1704
POWER_SUPPLY_PRESENT=1
POWER_SUPPLY_ONLINE=1
POWER_SUPPLY_CURRENT_MAX=1800
POWER_SUPPLY_MODEL_NAME=isp1707
POWER_SUPPLY_MANUFACTURER=NXP
root@n900devuan:/sys/devices/platform/isp1707/power_supply/isp1704# cat uevent
POWER_SUPPLY_NAME=isp1704
POWER_SUPPLY_PRESENT=1
POWER_SUPPLY_ONLINE=1
POWER_SUPPLY_CURRENT_MAX=500
POWER_SUPPLY_MODEL_NAME=isp1707
POWER_SUPPLY_MANUFACTURER=NXP
root@n900devuan:/sys/devices/platform/isp1707/power_supply/isp1704# cat type
USB_CDP
root@n900devuan:/sys/devices/platform/isp1707/power_supply/isp1704# cat type
USB_DCP

We should check if there are similar interfaces on available on other devices (at least the droid4) and then see how we can use it.

I am not planning to close this issue until the droid4 also works, and there's a list of things that need to be fixed still (if at all).

[MerlijnWajer]

Gadget switching works now, and it's pretty easy to compose them (!). Integrating it now seems to be harder part. Likely I will make it standalone from ke-recv first, since that's a huge code base and also relies on hal very heavily. We'll have to work on ke-recv (or something like it!) later though.

[MerlijnWajer]

ke-recv repo is here: https://github.com/community-ssu/ke-recv/blob/master/src/ke-recv.c

Not yet imported (since it'd be a lot of work to port, too)

[MerlijnWajer]

I am inclined to quickly push a basic version based on just the dialog, not ke-recv, and then just focus on connectivity.

[MerlijnWajer]

OK, so the summary, I think, is that we need musb and a power driver (like isp1704 on n900). Then we cna use the isp1704 for detecting if a cable is plugged, and use musb to check if the connected device is a pc or just charger. The main difficulty here is that musb will only report anything sensible if a gadget is loaded. So we'll need to have a gadget loaded just to know when we should load a gadget...

So the plan now is to modify udev-helper in ke-recv and hildon-status-bar-usb, implement always loading some gadget in ke-recv, and then have hildon-status-bar-usb work with ke-recv. And not forget to have hildon-status-bar-usb depend on ke-recv again (parazyd removed that in a previous commit).

Now we just need to decide what gadget to load/use when we just want to know what we're being connected to...

[MerlijnWajer]

With version 3.0.3 I think this should suffice for the short term. It should detect the usb mode on start, and allows changing to other modes by interaction with udev enabled ke-recv.