Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Import hildon-status-bar-usb #39

Closed
MerlijnWajer opened this issue Jan 27, 2018 · 30 comments

Comments

@MerlijnWajer

This comment has been minimized.

Copy link
Member Author

@MerlijnWajer MerlijnWajer commented Jan 27, 2018

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

@MerlijnWajer

This comment has been minimized.

Copy link
Member Author

@MerlijnWajer MerlijnWajer commented Feb 14, 2018

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 MerlijnWajer self-assigned this Feb 14, 2018
@MerlijnWajer

This comment has been minimized.

Copy link
Member Author

@MerlijnWajer MerlijnWajer commented Feb 14, 2018

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

This comment has been minimized.

Copy link
Member Author

@MerlijnWajer MerlijnWajer commented Feb 14, 2018

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

This comment has been minimized.

Copy link
Member Author

@MerlijnWajer MerlijnWajer commented Feb 14, 2018

@freemangordon - any thoughts?

@freemangordon

This comment has been minimized.

Copy link

@freemangordon freemangordon commented Feb 15, 2018

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

This comment has been minimized.

@MerlijnWajer

This comment has been minimized.

Copy link
Member Author

@MerlijnWajer MerlijnWajer commented Feb 15, 2018

@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

This comment has been minimized.

Copy link
Member Author

@MerlijnWajer MerlijnWajer commented Feb 15, 2018

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

This comment has been minimized.

Copy link
Member Author

@MerlijnWajer MerlijnWajer commented Feb 15, 2018

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

This comment has been minimized.

Copy link

@freemangordon freemangordon commented Feb 15, 2018

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

This comment has been minimized.

Copy link
Member Author

@MerlijnWajer MerlijnWajer commented Feb 15, 2018

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

This comment has been minimized.

Copy link
Member Author

@MerlijnWajer MerlijnWajer commented Feb 15, 2018

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

This comment has been minimized.

Copy link
Member Author

@MerlijnWajer MerlijnWajer commented Feb 15, 2018

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

This comment has been minimized.

Copy link
Member Author

@MerlijnWajer MerlijnWajer commented Feb 15, 2018

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

@MerlijnWajer

This comment has been minimized.

Copy link
Member Author

@MerlijnWajer MerlijnWajer commented Feb 15, 2018

Or at least make g_nokia not =y

@MerlijnWajer

This comment has been minimized.

Copy link
Member Author

@MerlijnWajer MerlijnWajer commented Feb 24, 2018

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

@MerlijnWajer

This comment has been minimized.

Copy link
Member Author

@MerlijnWajer MerlijnWajer commented Feb 24, 2018

(It works for me)

@MerlijnWajer

This comment has been minimized.

Copy link
Member Author

@MerlijnWajer MerlijnWajer commented Mar 1, 2018

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

This comment has been minimized.

Copy link
Member Author

@MerlijnWajer MerlijnWajer commented Mar 1, 2018

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

@MerlijnWajer

This comment has been minimized.

Copy link
Member Author

@MerlijnWajer MerlijnWajer commented Mar 1, 2018

@MerlijnWajer

This comment has been minimized.

Copy link
Member Author

@MerlijnWajer MerlijnWajer commented Mar 1, 2018

@meridion - do you want to pick this up?

@MerlijnWajer

This comment has been minimized.

Copy link
Member Author

@MerlijnWajer MerlijnWajer commented Mar 2, 2018

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

This comment has been minimized.

Copy link
Member Author

@MerlijnWajer MerlijnWajer commented Mar 3, 2018

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

This comment has been minimized.

Copy link
Member Author

@MerlijnWajer MerlijnWajer commented Mar 4, 2018

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

This comment has been minimized.

Copy link
Member Author

@MerlijnWajer MerlijnWajer commented Mar 4, 2018

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

This comment has been minimized.

Copy link
Member Author

@MerlijnWajer MerlijnWajer commented Mar 4, 2018

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

@MerlijnWajer

This comment has been minimized.

Copy link
Member Author

@MerlijnWajer MerlijnWajer commented Oct 1, 2018

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

This comment has been minimized.

Copy link
Member Author

@MerlijnWajer MerlijnWajer commented Oct 14, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.