uvos__ has quit [Ping timeout: 268 seconds]
Langoor has joined #maemo-leste
norly has quit [Read error: Software caused connection abort]
norly has joined #maemo-leste
stintel has quit [Read error: Software caused connection abort]
Danct12 has joined #maemo-leste
stintel has joined #maemo-leste
Danct12 has quit [Quit: Quitting]
jrayhawk has quit [Quit: debugging performance issues in 1.4.3]
jrayhawk has joined #maemo-leste
joerg has quit [Ping timeout: 260 seconds]
joerg has joined #maemo-leste
<freemangordon> sicelo: where, I cannot remember who had issues, but I remember it was related with kernel size
rafael2k has joined #maemo-leste
<freemangordon> from a brief look at the config:
<freemangordon> CONFIG_REMOTEPROC=y
<freemangordon> CONFIG_EXTCON=y
<freemangordon> also, I don;t see why all FS types are built-in, the same for IP stuff
<freemangordon> also, there are various trace/debug options that can (and I think should) be disabled
ceene has joined #maemo-leste
mardy has joined #maemo-leste
rafael2k has quit [Ping timeout: 252 seconds]
uvos__ has joined #maemo-leste
<freemangordon> uvos__: see a9081a008f84819ab2f3da596bf89afa16beea94
<uvos__> hmm?
<uvos__> just waking up
alex1216 has joined #maemo-leste
<freemangordon> well, look at the commit while having your coffee :)
<freemangordon> in regards to usb charging
<uvos__> kernel commit i assume
<freemangordon> sure]
<freemangordon> this one as well 7d21114dc6a2d53babef43a84a8d8db2905d283d
<freemangordon> what I am trying to say is:
<freemangordon> we have to create extcon device that recognizes usb host/charger being attached and calls extcon_set_state_sync()
<freemangordon> and then register phy notifier in cpcap_charger
<freemangordon> and all will start working, IIUC
<freemangordon> I really need tmlind or sre to confirm that
<tmlind> freemangordon: are you trying to configure charger negotiation?
<uvos__> yes he is
<tmlind> ok
<uvos__> freemangordon: yeah thats what it sounds like
<uvos__> configure/implement
rafael2k has joined #maemo-leste
<freemangordon> tmlind: but, what I don't understand is, which phy shall cpcap_charger register notifier to? mausb-hdrc or mapphone?
<tmlind> i think drivers/usb/phy is the legacy framework, we're using driver/phy.. not sure if they work together
<tmlind> freemangordon: phy-cpcap-usb driver is the one for the micro-b usb port
<freemangordon> seems like, I had to comment the check in musb_gadget_vbus_draw() so usb_phy_set_power() to be called
<freemangordon> tmlind: I understand that, but gadget drivers bind to musb driver, no?
<tmlind> yeah
<freemangordon> so the call usb_phy_set_power() on musb phy
<freemangordon> so, cpcap-charger shall register to musb, not to phy-cpcap-usb
<freemangordon> to receive notifications for usb_phy_set_power() calls, no?
<tmlind> maybe grep first if drivers/usb/phy is still supposed to be used though
<freemangordon> umm, in 5.18 it is
<tmlind> so how does it interact with drivers/phy?
<freemangordon> cpcap_usb_try_musb_mailbox() ;)
<tmlind> that's old legacy stuff too..
<freemangordon> this is what we have
<freemangordon> unless this was changed in 6.x
xmn has quit [Ping timeout: 260 seconds]
<tmlind> right, but not sure we should start mixing in anything from the old drivers/usb/phy
<freemangordon> what I propose doe not really depend on that
<tmlind> oh ok
<freemangordon> extcon support is provided by the FW, see 7d21114dc6a2d53babef43a84a8d8db2905d283d
<tmlind> i don't think extcon is needed either.. we already use iio framework
<freemangordon> it is, for charger detection
<freemangordon> at least that's what I understood
<freemangordon> the other option is to have charger_detect phy callback
<uvos__> if tmlind knows one looking at a some other power subsystem driver that supports negotiation might help
<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
<uvos__> negotation/geting power limit from a usb framework
<tmlind> gadgetfs configures the usb-b power limit for the device
<freemangordon> uvos__: well, I grepped all over the place, the only one that uses it is wm831x_power.c
<uvos__> freemangordon: hard to belive that support is not widespread
<freemangordon> tmlind: yes, and gadget driver calls usb_phy_set_power()
<freemangordon> believe it
<tmlind> ok
<uvos__> freemangordon: tht kind of suggsts its not the right way to do it or?
<freemangordon> and that in turn calls usb_phy_set_charger_current()
<tmlind> heh seems like vbus should be just a regulator to linux :)
<freemangordon> tmlind: how is that related to USB host config in terms of gadget
<uvos__> im also pretty shockt this was added in 2017 only..
<freemangordon> me too
<freemangordon> but it is what it is
<freemangordon> and that's why there are no users :)
<tmlind> seems like there should be a better way nowadays :)
* tmlind going offline in a few mins
<freemangordon> tmlind: ok, please, LMK what it is, and I will implement it
<tmlind> no idea :)
<freemangordon> heh
<freemangordon> why "seems like" then?
<tmlind> kind of wondering about the extcon part.. but maybe that's how it's supposed to look like
<freemangordon> actually, axtcon seems fine, as it detects not only chargers, but ACA and carcit and wantever
<freemangordon> *extcon
<tmlind> ok, maybe grep around in iio also in case there's something there nowadays
<freemangordon> oh, typo day it seems ;)
<freemangordon> tmlind: I am grepping for the last 2 days maybe
<tmlind> grep harder :)
<uvos__> is that a flag?
<tmlind> grep -H maybe? :)
<freemangordon> and seems nobody cares about limiting charging current
<freemangordon> tmlind: grep what for?
<freemangordon> sunxi are using extcon, for sure
<freemangordon> so is palmas
<freemangordon> etc
<tmlind> freemangordon: sorry just kidding, i guess there's no better solution
<freemangordon> ah, ok :)
<freemangordon> it seems this was borrowed from android switch_something
<freemangordon> and actually this is what d4 vendor kernel uses
<tmlind> ok
<uvos__> no wonder usb pd is a mess, if few even manag to implement usb 2.0 power xD
<freemangordon> pd == power distribution?
* tmlind bbl later tonight
<freemangordon> bye
<uvos__> usb power delivery
<uvos__> recent spec
<uvos__> (is a)
pere has quit [Ping timeout: 248 seconds]
<freemangordon> ok
Twig has joined #maemo-leste
pere has joined #maemo-leste
rafael2k has quit [Remote host closed the connection]
Danct12 has joined #maemo-leste
akossh has joined #maemo-leste
norayr has left #maemo-leste [Error from remote client]
norayr has joined #maemo-leste
jedertheythem[m] has quit [Quit: You have been kicked for being idle]
ceene has quit [Remote host closed the connection]
ceene has joined #maemo-leste
ceene has quit [Remote host closed the connection]
ceene has joined #maemo-leste
norayr has left #maemo-leste [Error from remote client]
mardy has quit [Read error: Connection reset by peer]
norayr has joined #maemo-leste
mardy has joined #maemo-leste
pere has quit [Ping timeout: 268 seconds]
Daaanct12 has joined #maemo-leste
Daaanct12 has quit [Client Quit]
bencoh has quit [Ping timeout: 248 seconds]
pere has joined #maemo-leste
bencoh has joined #maemo-leste
bencoh has quit [Changing host]
bencoh has joined #maemo-leste
uvos__ has quit [Remote host closed the connection]
uvos__ has joined #maemo-leste
uvos__ has quit [Client Quit]
ceene has quit [Remote host closed the connection]
uvos__ has joined #maemo-leste
uvos__ has quit [Ping timeout: 260 seconds]
xmn has joined #maemo-leste
<Wizzup> where do you guys set a bluetooth headset as output for audio?
<Wizzup> freemangordon: hmm got this http://dpaste.com/C8JFKKRNA
<Wizzup> ah maybe this is done from blueman
<freemangordon> Wizzup: do you have Xorg log file as well?
<Wizzup> argh, I just restarted the device
<freemangordon> it should be in /home/user
<freemangordon> it is copied from /tmo on reboot :)
<freemangordon> */tmp
<Wizzup> ok
<Wizzup> >manager
<Wizzup> Pair & trust your device in blueman, connect audiosink. You can close blueman now. The quality seems a bit better in 'offline mode'.
<Wizzup> this is frustratingly vague
<Wizzup> "connect audiosink"
<Wizzup> freemangordon: http://dpaste.com/4TDQCJZWM
<Wizzup> headset also keeps connecting and disconnecting?
* Wizzup gives up
<Wizzup> the wiki also does not say if i runs as root or not
<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):
<Wizzup> aha...
Twig has quit [Ping timeout: 260 seconds]
<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
<Wizzup> name="(unset)" requested_reply="0" destination="org.bluez" (uid=0 pid=2962 comm="/usr/sbin/bluetoothd ")
<Wizzup> hum
<freemangordon> Wizzup: could you enable debug of omap xorg driver?
<Wizzup> freemangordon: how a quick howto?
<Wizzup> wow the leste wiki made bluetooth look so easy :)
* Wizzup gives up for now for real
<freemangordon> Wizzup: /usr/share/X11/xorg.conf.d/99-omap.conf
<freemangordon> "Device" section
<freemangordon> Option "Debug" "true"
<Wizzup> hm now I see it (the hp)
<Wizzup> freemangordon: ok, will do
<Wizzup> btw, ofono also lacks bt privs it seems
alex1216 has quit [Quit: WeeChat 2.3]
<Wizzup> fwiw I did modify /etc/dbus-1/system.d/bluetooth.conf to allow pa to query for devices
<freemangordon> ok, this usb phy notifier thing seems like a total mess
<freemangordon> everyone seems to call atomic_notifier_call_chain() with absolutely unrelated parameters
<freemangordon> but usb phy charger code calls this: https://elixir.bootlin.com/linux/v6.1-rc4/source/drivers/usb/phy/phy.c#L132
<freemangordon> tmlind: ^^^ !?!
_uvos_ has joined #maemo-leste
_uvos_ has quit [Remote host closed the connection]
_uvos_ has joined #maemo-leste
<_uvos_> Wizzup: i dident have to anything special to get bt audio to work on d4
<_uvos_> on mapphones bt call audio cant possibly work
<sicelo> why
_uvos_ has quit [Ping timeout: 268 seconds]
_uvos_ has joined #maemo-leste
<_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
<_uvos_> so you have to somehow configure the bt chip or modem so that the dais line up
<_uvos_> and i have no idea how thats suposed to work
_uvos_ has quit [Ping timeout: 268 seconds]
Pali has joined #maemo-leste
<Wizzup> uvos: weird, I had to do various things to make it work
<Wizzup> uvos: maybe you run something as root instead of as user or something?
<Wizzup> per the dbus bluetooth rules pulseaudio is clearly not allowed to talk to it
<Wizzup> it only allows services with the group bluetooth
<Wizzup> which even our 'user' is not, currently
xmn has quit [Ping timeout: 246 seconds]
xmn has joined #maemo-leste
elastic_dog has quit [Remote host closed the connection]
elastic_dog has joined #maemo-leste
branon has quit [Ping timeout: 246 seconds]
branon has joined #maemo-leste
<Wizzup> uvos: bionic just reset, with wifi connected (and bt on)
<Wizzup> uvos: buzz: have you seen ofono go crazy when bt headset is connected?
<Wizzup> it just calls poll forever
<buZz> i havent tried a bt headset yet!
<buZz> only BT speakers
<Wizzup> wait, what -did- you try?
<buZz> just eh , plain 'boomboxes' like the kids have nowadays :P
<buZz> and a bt headphone , which is just the same as a speaker for BT
<buZz> not a microphone having headset
<Wizzup> yeah
<Wizzup> maybe this causes ofono to go nuts
<buZz> maybe ... i'll try to get such BT hw soonish to try
<Wizzup> it also crackles a bit unless you set some pa latency
<Wizzup> but hey, the driver works enough that this just work
<Wizzup> s
<Wizzup> so that's something :)
<Wizzup> I think I'll mostly just stick to the good ol cable
<buZz> :D
<buZz> i think we can get it way more reliable without much changes
<buZz> but, once setup, the BT speaker output at least, is rocksolid
<Wizzup> you hear no crackles?
<buZz> only when wifi is on during ;)
<sicelo> btw, wired headphone works fine for voice calls?
<Wizzup> right, I have wifi on
<Wizzup> sicelo: I don't remember if I tested this fully
<Wizzup> I remember there was an issue but maybe it was solved
<buZz> Wizzup: afaik 'using wifi during BT' is some known bad thing , isnt it on wiki?
<Wizzup> well, maybe
<Wizzup> tmlind: freemangordon: https://paste.villavu.com/raw/7529/ this is what caused my d4 to get real hot
<Wizzup> the messages repeats really, really often and causes syslog to use 100%
<Wizzup> huh, just happened again
mardy has quit [Quit: WeeChat 3.5]
_uvos_ has joined #maemo-leste
<_uvos_> sigh my isp's ip got banned here
<_uvos_> again
<_uvos_> wired call audio definatly should work
<_uvos_> but nothing switches to it atm automaticly
<_uvos_> i have used a bt headset extensively
<_uvos_> never seen any issues with that
<_uvos_> i use a bose qc35
<_uvos_> its a pair of headhones that support the high quality audio profile, and the headset profile
<_uvos_> works fine in both modes
<Wizzup> with wifi on?
<_uvos_> i hear crackels sometimes on bt
<_uvos_> yes
<_uvos_> but also crackles on wired
<_uvos_> sometimes too
<_uvos_> this is a pa issue
_uvos__ has joined #maemo-leste
<_uvos__> using the alsa device directly is without crackles
<_uvos__> none of the stuff you linked was nessecary at all here
<Wizzup> I don't hear them on wired I htink
<Wizzup> _uvos__: it was for me
<Wizzup> by default 'user' doesn't even have bt access
<_uvos__> besides loading the right pa modules, starting bluez and modrobin the driver i dident have tondo anything
<Wizzup> weird
<_uvos__> right you have to do that too
<_uvos__> but really thats it
<Wizzup> well pa was erroring out accessing bluez
<Wizzup> over dbus
<_uvos__> load-module module-bluez5-device
_uvos__ has quit [Remote host closed the connection]
_uvos_ has quit [Ping timeout: 268 seconds]
_uvos__ has joined #maemo-leste
_uvos_ has joined #maemo-leste
_uvos_ has quit [Client Quit]
_uvos_ has joined #maemo-leste
<_uvos_> and load-module module-bluez5-discover
<_uvos_> are the modules
<_uvos_> Wizzup: wierd
_uvos__ has quit [Ping timeout: 252 seconds]
_uvos_ has quit [Ping timeout: 252 seconds]
akossh has quit [Ping timeout: 268 seconds]
crab has quit [*.net *.split]
crab has joined #maemo-leste