| freemangordon | sicelo: where, I cannot remember who had issues, but I remember it was related with kernel size | 07:08 |
|---|---|---|
| freemangordon | from a brief look at the config: | 07:14 |
| freemangordon | CONFIG_REMOTEPROC=y | 07:14 |
| freemangordon | CONFIG_EXTCON=y | 07:14 |
| freemangordon | also, I don;t see why all FS types are built-in, the same for IP stuff | 07:17 |
| freemangordon | also, there are various trace/debug options that can (and I think should) be disabled | 07:17 |
| freemangordon | uvos__: see a9081a008f84819ab2f3da596bf89afa16beea94 | 08:20 |
| uvos__ | hmm? | 08:21 |
| uvos__ | just waking up | 08:21 |
| freemangordon | well, look at the commit while having your coffee :) | 08:22 |
| freemangordon | in regards to usb charging | 08:22 |
| uvos__ | kernel commit i assume | 08:22 |
| freemangordon | sure] | 08:22 |
| freemangordon | this one as well 7d21114dc6a2d53babef43a84a8d8db2905d283d | 08:23 |
| freemangordon | what I am trying to say is: | 08:23 |
| freemangordon | we have to create extcon device that recognizes usb host/charger being attached and calls extcon_set_state_sync() | 08:26 |
| freemangordon | and then register phy notifier in cpcap_charger | 08:26 |
| freemangordon | and all will start working, IIUC | 08:26 |
| freemangordon | I really need tmlind or sre to confirm that | 08:27 |
| tmlind | freemangordon: are you trying to configure charger negotiation? | 08:30 |
| uvos__ | yes he is | 08:31 |
| tmlind | ok | 08:31 |
| uvos__ | freemangordon: yeah thats what it sounds like | 08:31 |
| uvos__ | configure/implement | 08:31 |
| freemangordon | tmlind: but, what I don't understand is, which phy shall cpcap_charger register notifier to? mausb-hdrc or mapphone? | 08:33 |
| tmlind | i think drivers/usb/phy is the legacy framework, we're using driver/phy.. not sure if they work together | 08:33 |
| tmlind | freemangordon: phy-cpcap-usb driver is the one for the micro-b usb port | 08:34 |
| freemangordon | seems like, I had to comment the check in musb_gadget_vbus_draw() so usb_phy_set_power() to be called | 08:34 |
| freemangordon | tmlind: I understand that, but gadget drivers bind to musb driver, no? | 08:34 |
| tmlind | yeah | 08:34 |
| freemangordon | so the call usb_phy_set_power() on musb phy | 08:34 |
| freemangordon | so, cpcap-charger shall register to musb, not to phy-cpcap-usb | 08:35 |
| freemangordon | to receive notifications for usb_phy_set_power() calls, no? | 08:35 |
| tmlind | maybe grep first if drivers/usb/phy is still supposed to be used though | 08:36 |
| freemangordon | umm, in 5.18 it is | 08:36 |
| tmlind | so how does it interact with drivers/phy? | 08:36 |
| freemangordon | cpcap_usb_try_musb_mailbox() ;) | 08:37 |
| tmlind | that's old legacy stuff too.. | 08:37 |
| freemangordon | this is what we have | 08:38 |
| freemangordon | unless this was changed in 6.x | 08:38 |
| tmlind | right, but not sure we should start mixing in anything from the old drivers/usb/phy | 08:38 |
| freemangordon | what I propose doe not really depend on that | 08:38 |
| tmlind | oh ok | 08:39 |
| freemangordon | extcon support is provided by the FW, see 7d21114dc6a2d53babef43a84a8d8db2905d283d | 08:39 |
| tmlind | i don't think extcon is needed either.. we already use iio framework | 08:40 |
| freemangordon | it is, for charger detection | 08:40 |
| freemangordon | at least that's what I understood | 08:40 |
| freemangordon | the other option is to have charger_detect phy callback | 08:41 |
| uvos__ | if tmlind knows one looking at a some other power subsystem driver that supports negotiation might help | 08:41 |
| tmlind | my gut feeling is that we should be able to do this nowadays with just drivers/phy and iio.. but maybe extcon is still needed | 08:41 |
| uvos__ | negotation/geting power limit from a usb framework | 08:41 |
| tmlind | gadgetfs configures the usb-b power limit for the device | 08:42 |
| freemangordon | uvos__: well, I grepped all over the place, the only one that uses it is wm831x_power.c | 08:42 |
| uvos__ | freemangordon: hard to belive that support is not widespread | 08:43 |
| freemangordon | tmlind: yes, and gadget driver calls usb_phy_set_power() | 08:43 |
| freemangordon | believe it | 08:43 |
| tmlind | ok | 08:43 |
| uvos__ | freemangordon: tht kind of suggsts its not the right way to do it or? | 08:43 |
| freemangordon | and that in turn calls usb_phy_set_charger_current() | 08:43 |
| tmlind | heh seems like vbus should be just a regulator to linux :) | 08:44 |
| freemangordon | uvos__: see https://www.mail-archive.com/linux-usb@vger.kernel.org/msg93172.html | 08:44 |
| freemangordon | tmlind: how is that related to USB host config in terms of gadget | 08:45 |
| uvos__ | im also pretty shockt this was added in 2017 only.. | 08:45 |
| freemangordon | me too | 08:45 |
| freemangordon | but it is what it is | 08:45 |
| freemangordon | and that's why there are no users :) | 08:45 |
| tmlind | seems like there should be a better way nowadays :) | 08:45 |
| * tmlind going offline in a few mins | 08:46 | |
| freemangordon | tmlind: ok, please, LMK what it is, and I will implement it | 08:46 |
| tmlind | no idea :) | 08:46 |
| freemangordon | heh | 08:46 |
| freemangordon | why "seems like" then? | 08:46 |
| tmlind | kind of wondering about the extcon part.. but maybe that's how it's supposed to look like | 08:47 |
| freemangordon | actually, axtcon seems fine, as it detects not only chargers, but ACA and carcit and wantever | 08:47 |
| freemangordon | *extcon | 08:47 |
| tmlind | ok, maybe grep around in iio also in case there's something there nowadays | 08:48 |
| freemangordon | oh, typo day it seems ;) | 08:48 |
| freemangordon | tmlind: I am grepping for the last 2 days maybe | 08:48 |
| tmlind | grep harder :) | 08:48 |
| uvos__ | is that a flag? | 08:48 |
| tmlind | grep -H maybe? :) | 08:48 |
| freemangordon | and seems nobody cares about limiting charging current | 08:48 |
| freemangordon | tmlind: grep what for? | 08:48 |
| freemangordon | sunxi are using extcon, for sure | 08:49 |
| freemangordon | so is palmas | 08:49 |
| freemangordon | etc | 08:49 |
| tmlind | freemangordon: sorry just kidding, i guess there's no better solution | 08:49 |
| freemangordon | ah, ok :) | 08:49 |
| freemangordon | it seems this was borrowed from android switch_something | 08:50 |
| freemangordon | and actually this is what d4 vendor kernel uses | 08:50 |
| tmlind | ok | 08:50 |
| uvos__ | no wonder usb pd is a mess, if few even manag to implement usb 2.0 power xD | 08:50 |
| freemangordon | pd == power distribution? | 08:51 |
| * tmlind bbl later tonight | 08:51 | |
| freemangordon | bye | 08:51 |
| uvos__ | usb power delivery | 08:51 |
| uvos__ | recent spec | 08:51 |
| uvos__ | (is a) | 08:51 |
| freemangordon | ok | 08:56 |
| Wizzup | where do you guys set a bluetooth headset as output for audio? | 15:59 |
| Wizzup | freemangordon: hmm got this http://dpaste.com/C8JFKKRNA | 16:01 |
| Wizzup | ah maybe this is done from blueman | 16:03 |
| freemangordon | Wizzup: do you have Xorg log file as well? | 16:03 |
| Wizzup | argh, I just restarted the device | 16:05 |
| freemangordon | it should be in /home/user | 16:06 |
| freemangordon | it is copied from /tmo on reboot :) | 16:06 |
| freemangordon | */tmp | 16:06 |
| Wizzup | ok | 16:09 |
| Wizzup | >manager | 16:14 |
| Wizzup | Pair & trust your device in blueman, connect audiosink. You can close blueman now. The quality seems a bit better in 'offline mode'. | 16:14 |
| Wizzup | this is frustratingly vague | 16:14 |
| Wizzup | "connect audiosink" | 16:14 |
| Wizzup | freemangordon: http://dpaste.com/4TDQCJZWM | 16:16 |
| Wizzup | headset also keeps connecting and disconnecting? | 16:17 |
| * Wizzup gives up | 16:22 | |
| Wizzup | the wiki also does not say if i runs as root or not | 16:25 |
| Wizzup | If that still does not work, or you are using PulseAudio's system-wide mode, also load the following PulseAudio modules (again these can be loaded via your default.pa or system.pa): | 16:27 |
| Wizzup | aha... | 16:27 |
| Wizzup | Nov 11 16:32:00 localhost pulseaudio: modules/bluetooth/bluez5-util.c:1052:get_managed_objects_reply:GetManagedObjects() failed: org.freedesktop.DBus.Error.AccessDenied: Rejected send message, 2 matched rules; type="method_call", sender=":1.73" (uid=111 pid=2343 comm="/usr/bin/pulseaudio --fail=1 --daemonize=1 --syste") interface="org.freedesktop.DBus.ObjectManager" member="GetManagedObjects" error | 16:32 |
| Wizzup | name="(unset)" requested_reply="0" destination="org.bluez" (uid=0 pid=2962 comm="/usr/sbin/bluetoothd ") | 16:33 |
| Wizzup | hum | 16:33 |
| freemangordon | Wizzup: could you enable debug of omap xorg driver? | 16:39 |
| Wizzup | freemangordon: how a quick howto? | 16:44 |
| Wizzup | wow the leste wiki made bluetooth look so easy :) | 16:44 |
| * Wizzup gives up for now for real | 16:44 | |
| freemangordon | Wizzup: /usr/share/X11/xorg.conf.d/99-omap.conf | 16:46 |
| freemangordon | "Device" section | 16:46 |
| freemangordon | Option "Debug" "true" | 16:46 |
| Wizzup | hm now I see it (the hp) | 16:47 |
| Wizzup | freemangordon: ok, will do | 16:47 |
| Wizzup | btw, ofono also lacks bt privs it seems | 16:48 |
| Wizzup | fwiw I did modify /etc/dbus-1/system.d/bluetooth.conf to allow pa to query for devices | 16:51 |
| freemangordon | ok, this usb phy notifier thing seems like a total mess | 17:29 |
| freemangordon | everyone seems to call atomic_notifier_call_chain() with absolutely unrelated parameters | 17:30 |
| freemangordon | omap musb code calls this https://elixir.bootlin.com/linux/v6.1-rc4/source/drivers/usb/musb/omap2430.c#L155 | 17:34 |
| freemangordon | but usb phy charger code calls this: https://elixir.bootlin.com/linux/v6.1-rc4/source/drivers/usb/phy/phy.c#L132 | 17:35 |
| freemangordon | OTOH, phy-ab8500-usb calls it like https://elixir.bootlin.com/linux/v6.1-rc4/source/drivers/usb/phy/phy-ab8500-usb.c#L392 | 17:36 |
| freemangordon | tmlind: ^^^ !?! | 17:37 |
| _uvos_ | Wizzup: i dident have to anything special to get bt audio to work on d4 | 17:42 |
| _uvos_ | on mapphones bt call audio cant possibly work | 17:42 |
| sicelo | why | 17:45 |
| _uvos_ | well on mapphones bt call audio works by haveing cpcap switch around the connections so that the bt chip is directly connected to the modem | 17:50 |
| _uvos_ | so you have to somehow configure the bt chip or modem so that the dais line up | 17:51 |
| _uvos_ | and i have no idea how thats suposed to work | 17:51 |
| Wizzup | uvos: weird, I had to do various things to make it work | 18:11 |
| Wizzup | uvos: maybe you run something as root instead of as user or something? | 18:12 |
| Wizzup | per the dbus bluetooth rules pulseaudio is clearly not allowed to talk to it | 18:12 |
| Wizzup | it only allows services with the group bluetooth | 18:12 |
| Wizzup | which even our 'user' is not, currently | 18:12 |
| Wizzup | uvos: bionic just reset, with wifi connected (and bt on) | 20:13 |
| Wizzup | uvos: buzz: have you seen ofono go crazy when bt headset is connected? | 21:06 |
| Wizzup | it just calls poll forever | 21:07 |
| buZz | i havent tried a bt headset yet! | 21:07 |
| buZz | only BT speakers | 21:07 |
| Wizzup | wait, what -did- you try? | 21:07 |
| buZz | just eh , plain 'boomboxes' like the kids have nowadays :P | 21:07 |
| buZz | and a bt headphone , which is just the same as a speaker for BT | 21:08 |
| buZz | not a microphone having headset | 21:08 |
| Wizzup | yeah | 21:08 |
| Wizzup | maybe this causes ofono to go nuts | 21:08 |
| buZz | maybe ... i'll try to get such BT hw soonish to try | 21:09 |
| Wizzup | it also crackles a bit unless you set some pa latency | 21:10 |
| Wizzup | but hey, the driver works enough that this just work | 21:12 |
| Wizzup | s | 21:12 |
| Wizzup | so that's something :) | 21:12 |
| Wizzup | I think I'll mostly just stick to the good ol cable | 21:15 |
| buZz | :D | 21:15 |
| buZz | i think we can get it way more reliable without much changes | 21:15 |
| buZz | but, once setup, the BT speaker output at least, is rocksolid | 21:15 |
| Wizzup | you hear no crackles? | 21:15 |
| buZz | only when wifi is on during ;) | 21:15 |
| sicelo | btw, wired headphone works fine for voice calls? | 21:15 |
| Wizzup | right, I have wifi on | 21:15 |
| Wizzup | sicelo: I don't remember if I tested this fully | 21:16 |
| Wizzup | I remember there was an issue but maybe it was solved | 21:16 |
| buZz | Wizzup: afaik 'using wifi during BT' is some known bad thing , isnt it on wiki? | 21:16 |
| Wizzup | well, maybe | 21:19 |
| Wizzup | tmlind: freemangordon: https://paste.villavu.com/raw/7529/ this is what caused my d4 to get real hot | 21:30 |
| Wizzup | the messages repeats really, really often and causes syslog to use 100% | 21:31 |
| Wizzup | huh, just happened again | 21:34 |
| Wizzup | btw, others also do this: https://github.com/ev3dev/ev3dev.github.io/pull/24/files/50787e9fae767f4a8e5e1748c5bb70b40eb9f259#diff-a9f813bb4c68981de126bda83f8f678b2a0ab006ed11a137b7f0878c063de44aR46 | 21:43 |
| _uvos_ | sigh my isp's ip got banned here | 22:26 |
| _uvos_ | again | 22:26 |
| _uvos_ | wired call audio definatly should work | 22:27 |
| _uvos_ | but nothing switches to it atm automaticly | 22:27 |
| _uvos_ | i have used a bt headset extensively | 22:28 |
| _uvos_ | never seen any issues with that | 22:28 |
| _uvos_ | i use a bose qc35 | 22:28 |
| _uvos_ | its a pair of headhones that support the high quality audio profile, and the headset profile | 22:29 |
| _uvos_ | works fine in both modes | 22:29 |
| Wizzup | with wifi on? | 22:30 |
| _uvos_ | i hear crackels sometimes on bt | 22:30 |
| _uvos_ | yes | 22:30 |
| _uvos_ | but also crackles on wired | 22:30 |
| _uvos_ | sometimes too | 22:30 |
| _uvos_ | this is a pa issue | 22:30 |
| _uvos__ | using the alsa device directly is without crackles | 22:32 |
| _uvos__ | none of the stuff you linked was nessecary at all here | 22:33 |
| Wizzup | I don't hear them on wired I htink | 22:33 |
| Wizzup | _uvos__: it was for me | 22:34 |
| Wizzup | by default 'user' doesn't even have bt access | 22:34 |
| _uvos__ | besides loading the right pa modules, starting bluez and modrobin the driver i dident have tondo anything | 22:34 |
| Wizzup | weird | 22:34 |
| _uvos__ | right you have to do that too | 22:34 |
| _uvos__ | but really thats it | 22:34 |
| Wizzup | well pa was erroring out accessing bluez | 22:35 |
| Wizzup | over dbus | 22:35 |
| _uvos__ | load-module module-bluez5-device | 22:35 |
| _uvos_ | and load-module module-bluez5-discover | 22:37 |
| _uvos_ | are the modules | 22:37 |
| _uvos_ | Wizzup: wierd | 22:38 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!