norayr has joined #maemo-leste
uvos has quit [Ping timeout: 268 seconds]
elastic_dog has joined #maemo-leste
elastic_dog is now known as Guest674
Guest674 has quit [Killed (platinum.libera.chat (Nickname regained by services))]
Daanct12 has joined #maemo-leste
Daanct12 has quit [Ping timeout: 268 seconds]
mardy has joined #maemo-leste
joerg has quit [Ping timeout: 256 seconds]
joerg has joined #maemo-leste
ceene has joined #maemo-leste
Twig has joined #maemo-leste
Twig has quit [Ping timeout: 260 seconds]
Twig has joined #maemo-leste
Daanct12 has joined #maemo-leste
Daanct12 has quit [Quit: Quitting]
uvos has joined #maemo-leste
Twig has quit [Remote host closed the connection]
pere has quit [Ping timeout: 268 seconds]
uvos__ has joined #maemo-leste
pere has joined #maemo-leste
mardy has quit [Read error: Connection reset by peer]
Guest70 has joined #maemo-leste
Guest70 has quit [Quit: Client closed]
mardy has joined #maemo-leste
alex1216 has joined #maemo-leste
norayr has left #maemo-leste [Error from remote client]
uvos__ has quit [Ping timeout: 260 seconds]
uvos__ has joined #maemo-leste
brabo has joined #maemo-leste
uvos has quit [Remote host closed the connection]
alex1216 has quit [Quit: WeeChat 2.3]
<freemangordon> uvos__: I think the same charge-mode bug appeared. LED is green, but battery on the screen has just one thin red line and nothing happens
<freemangordon> it seems this happens only after batter was so empty that mce shut it down
<freemangordon> any hint how to debug?
<freemangordon> if I disconnect the charger, it shuts down
<freemangordon> is it possible that it tries to open the battery sys node only once?
<freemangordon> after reboot it displayed half battery
<freemangordon> hmm, could be related to charger driver
norayr has joined #maemo-leste
<freemangordon> no, this is different issue (ke-recv unbinding musb-hdrc causing it to send 0mA allowed current)
<freemangordon> Wizzup: any idea what's going on here https://pastebin.com/982WS9T9 ?
<freemangordon> this happens on boot with USB cable connected to PC
<Wizzup> freemangordon: what about it?
<freemangordon> it remains disconnected
<freemangordon> so if you boot with cable attached neither charging nor usb0 work
<freemangordon> until you detach/attach the cable
<freemangordon> will provide le-recv log in a minute
<freemangordon> *ke-recv
<freemangordon> Wizzup: https://pastebin.com/S7Tuxwy5
<Wizzup> is kernel in the right state?
<freemangordon> what do you mean?
<freemangordon> what to check?
<Wizzup> well, ke-recv just follows kernel/udev state
<freemangordon> sure, but how is that state set?
<Wizzup> by kernel/drivers I think?
<freemangordon> where?
<Wizzup> I don't know
<freemangordon> what to verify
<Wizzup> I would check some /sys
<freemangordon> ah
<Wizzup> or maybe udevadm can tell you
<freemangordon> yeah, /sys it is, but which one?
<Wizzup> or whatever the things is to query uevent files of specific /sys
<Wizzup> hmm, probably the usb and battery, let me check
<freemangordon> ok, but which one?
<freemangordon> usb power supply: POWER_SUPPLY_STATUS=Not charging
<freemangordon> what does it expect from battery?
<freemangordon> and actually we *can* read the mode from extcon ;)
<Wizzup> well at the time of writing I don't think the extcon was working
<Wizzup> this is mostly used for triggers
<freemangordon> hmm, where is that 'type' located, lemme try to find it
<freemangordon> ah
<freemangordon> in usb: POWER_SUPPLY_TYPE=USB
<freemangordon> Wizzup: also, what about "USB_SDP"?
<Wizzup> maybe we need to add it?
<freemangordon> shall I start ke-recv from console to see what will it say?
<Wizzup> sure
<freemangordon> Probing for drivers for Nokia N900
<freemangordon> Probing for drivers for LIME2
<freemangordon> Cannot find supply for Nokia N900
<freemangordon> Found supply
<freemangordon> Found otg
<freemangordon> that's all
<freemangordon> Wizzup: but, even with wall charger connected (DCP) it is the same
<freemangordon> otg mode is b_idle
<freemangordon> in /sys/module/musb_hdrc/drivers/platform:musb-hdrc/musb-hdrc.2.auto
<freemangordon> Wizzup: umm...
<freemangordon> why is that battery?
<freemangordon> shouldn't that be "usb"?
<freemangordon> also, on init update_info() is not called
<freemangordon> is that by design?
<Wizzup> dinner at, back in a bit
<freemangordon> ok
<Wizzup> freemangordon: I think it's probably good to call it on init
<Wizzup> freemangordon: maybe because of your new kernel patch it mistakes it for a lime
<Wizzup> that's what it looks like to me
pere has quit [Ping timeout: 260 seconds]
<freemangordon> because of extcon?
<freemangordon> ok, there is /sys/class/extcon/extcon0
<freemangordon> BTW, why do we care which device is that?
<freemangordon> I think if we have extcon, we should not care about otg at all
<freemangordon> but just enumerate extconN and try to find USB_XXX cables
<freemangordon> unless I am missing something
<freemangordon> what I didn't get though, is shall I set USB cable state to on if it is DCP port
<Wizzup> You can try to make it generic if you want, I found that a big challenge
<Wizzup> on some devices, certain things didn't trigger in udev
<freemangordon> sure, just tell me what we need to detect
<freemangordon> I have allwinner here as well
<freemangordon> so I can test there too
<freemangordon> it is also good testbed because it can charge from either USB or dedicated port
<freemangordon> just tell me what needs to be detected
<Wizzup> the tablet should be similar to lime2 I think
<freemangordon> mhm
<Wizzup> although I suppose the lime has no battery typiclaly
<Wizzup> while you may have one
<freemangordon> yes
<Wizzup> anyway I think my idea was to just add some things to this list until we found a more generic way
ceene has quit [Remote host closed the connection]
<Wizzup> given that it now finds your d4 to be a lime2, I think it's related to the kernel changes
<freemangordon> ok, but what do you need detected? USB cable?
<freemangordon> and not host?
<Wizzup> I think so, yes
<Wizzup> I don't know what DCP is to be honest
<freemangordon> Dedicated Charger Port
<freemangordon> wall charger
<freemangordon> SDP is Standard Downstream Port or USB 2.0 port, IIUC
<freemangordon> Charging Downstream Port or CDP is some USB2.0 that is able to provide up to 900mA
<freemangordon> but I don;t know how is that detected
<freemangordon> seems some game with D+/D- voltages is required
<Wizzup> I think that for those we don't want to show the dialog
<Wizzup> or load a gadget, really, unless we need to have one loaded
<Wizzup> of course we could have it show some icon for dedicated wall charger
<freemangordon> we need to have gadget loaded for USB/SDP only
<tmlind> freemangordon: fyi, because of commit 1ec92e974277 ("tty: n_gsm: fix decoupled mux resource"), there's a double free now in maemo-5.18.y kernel tree.. kfree in gsm_serdev_unregister_device() should be removed
<tmlind> last kref release already takes care of it
<tmlind> otherwise unloading serdev-ngsm will cause random oopses
<freemangordon> umm, why do you tell that to me?
<freemangordon> you want me to make a patch?
<freemangordon> I mean - I don;t object
<tmlind> rebasing stuff on v6.1-rc tree
<freemangordon> just don;t understand what am I required to do :)
<tmlind> and noticed this and you have patches applied on top in maemo-5.18.y :)
<freemangordon> ok
<freemangordon> tmlind: any idea why is sre so quiet?
<tmlind> yeah a patch to drop that kfree would be good to apply
<tmlind> i think sre is overly busy with work
<freemangordon> ah
<freemangordon> also, did you understand what greg wanted me to do i his comment re [PATCH] usb: phy: add dedicated notifier for charger events?
<freemangordon> sometimes reviews are so fuzzy...
<freemangordon> what is "notifier type"?
<freemangordon> sorry for pestering you, but I don't know whom else to ask
<freemangordon> Wizzup: so, the plan is: if there is extcon, use it, otherwise fallback to device-specific matching, ok?
<freemangordon> I think we will only need 'hack' for n900
<freemangordon> Wizzup: also, what that note is supposed to mean? https://github.com/maemo-leste/ke-recv/blob/master/src/udev-helper.c#L91
<Wizzup> sounds like the mode doesn't trigger udev
<Wizzup> kernel needs to do things to trigger
<Wizzup> not all drivers do this
<tmlind> freemangordon: maybe he just wants the event type there for the notifier? see include/linux/device/bus.h for BUS_NOTIFY_ADD_DEVICE and other events for example
pere has joined #maemo-leste
<tmlind> so a single notifier but with multiple event types
<freemangordon> and data parameter type to depend on event type? yeah, that would work
<freemangordon> but it would have been good if he stated that in a clear form :(
<tmlind> yeah i think that's what he means :)
<freemangordon> toldya it's fuzzy :)
<freemangordon> I'll wait some time for a follow-up and will send v2 if there is none
<tmlind> yeah ok
<tmlind> freemangordon: rebased your n_gsm patches to v6.1-rc5 fyi, i'll fold in your audio timeout change, ok?
<tmlind> looks like at least one fix is needed to more patches from daniel now merged, need to test a bit more
<tmlind> hmm still seeing audio timeout errors for 4806a000.serial:modem:audio-codec@2..
<freemangordon> timeout patch is needed for sure
<tmlind> maybe i just need to reboot as i did not scp over the updated audio module :)
<freemangordon> :)
<freemangordon> Wizzup: https://pastebin.com/fG4L4u1R
<freemangordon> unplug/plug wall charger
<freemangordon> looks ok to me
<tmlind> freemangordon: i think the real fix for the n_gsm initial timeouts would be to add deferred probe support to ohci-platform so phy-mapphone-mdm6600 won't init the phy until it's functional.. and then serdev-ngsm could wait for the phy too.. no luck trying to use serdev_device_wait_for_cts() to check when it might work
akossh has joined #maemo-leste
akossh has quit [Remote host closed the connection]
<freemangordon> hmm, yeah
akossh has joined #maemo-leste
akossh has quit [Remote host closed the connection]
akossh has joined #maemo-leste
akossh has quit [Remote host closed the connection]
akossh has joined #maemo-leste
mardy has quit [Quit: WeeChat 3.5]
<Wizzup> uvos__: I have bt working on my hyundai i30
<Wizzup> audio sink and events work
<Wizzup> i got PLAY_CD
<Wizzup> mpv plays
<buZz> w00t
<buZz> :) finally some internet again, my landlord cancelled the isp and 'forgot' to tell me
<Wizzup> calls also worked
<Wizzup> I mean
<Wizzup> no audio
<Wizzup> but ofono+bluez did the right thing
<Wizzup> the car went into calling mode
<Wizzup> freemangordon: ^^
<buZz> hahah cool
<buZz> using blueman? or straight up bluetoothctl
<Wizzup> combination
<Wizzup> blueman has weird settings
<Wizzup> and also I had to set the class of the device to "phone"
<Wizzup> otherwise the car would not see it
<Wizzup> so I dumped bluetooth info of my gf's android phone
<buZz> ah, are those binary blobs?
<Wizzup> no, just reading it from my d4
<Wizzup> sudo hciconfig hci0 class 005a020c
<Wizzup> blueman resets it by making it non discoverable and some other stuff
<Wizzup> anyway I think this can be configured..
<Wizzup> most of the time went into figuring out that the car won't play music over bt when a usb stick is plugged in
<Wizzup> still crackles though.
<buZz> even if you disable wifi?
<freemangordon> nice
<Wizzup> with ifconfig? didn't try
<Wizzup> but I was not connected to any wifi
<Wizzup> freemangordon: my h-d is now messed up (smaller), anything I can do to debug/dump info?
<Wizzup> I think I have debug on in x, but I think it's a h-d thing
<Wizzup> another interesting side effect is that it only redraws the screen on some action, like, when I touch it again
<Wizzup> again, this is an old bug even fremantle has
<Wizzup> I can try to rotate my phone
<Wizzup> rotating rotates hildon-home but not hildon-desktop or xrandr it seems
<buZz> Wizzup: or with that wifidisable statusmenu plugin
<buZz> but ifconfig down should be fine yeah
<buZz> i think the crackles are just the wifi trying to scan for stuff, maybe i could scan the wifi externally a bit
<buZz> s/scan/sniff/
<freemangordon> Wizzup: yes, I know that bug, but it is so rare that I don;t think we'll be able to fix it
<Wizzup> I have it no
<Wizzup> now
<freemangordon> yes, but I have no diea where to look in
<freemangordon> *idea
<freemangordon> maybe try to enable h-d debug
<freemangordon> SIGUSR1 or SIGUSR2
* freemangordon checks
elastic_dog has quit [Read error: Connection reset by peer]
elastic_dog has joined #maemo-leste
<freemangordon> Wizzup: send SIGUSR1 to hildon-dekstop
<Wizzup> ok, and how do I capture stederr?
<Wizzup> stderr*
<Wizzup> freemangordon: so the not-launcher pid, yeah?
<Wizzup> to the*
<Wizzup> user 3736 0.0 0.0 1636 844 ? Ss 20:29 0:00 /usr/bin/hildon-desktop
<freemangordon> yeah
<Wizzup> user 3739 0.7 3.9 98472 40008 ? Ssl 20:29 0:55 /usr/bin/hildon-desktop
<freemangordon> why stderr?
<freemangordon> 3739
<Wizzup> how do I watch debug?
<freemangordon> should be in syslog
<Wizzup> which file?
<freemangordon> /var/log/syslog
<Wizzup> I just see cron there
<freemangordon> well, no idea what happens if G_MESSAGES_DEBUG is not set
<Wizzup> probably nothing :(
<freemangordon> glib that is
<freemangordon> attach gdb
<freemangordon> not that I know what to do there :)
<buZz> Wizzup: capture stderr is 2> bla.log
<freemangordon> buZz: already running process
<Wizzup> [ 6231.717] (II) OMAP(0): drmmode_reallocate_scanout:1193 restoring CRTCs
<Wizzup> [ 6231.717] (II) OMAP(0): drmmode_reallocate_scanout:1197 restore CRTC 1
<Wizzup> [ 6231.717] (II) OMAP(0): drmmode_restore_crtc:273 create framebuffer: 960x540
<Wizzup> [ 6231.717] (EE) OMAP(0): ERROR: failed to set mode: Invalid argument
<Wizzup> [ 6231.717] (EE) OMAP(0): ERROR: failed to reconfig crtc 1
<Wizzup> [ 6231.978] (II) OMAP(0): drmmode_set_mode_major:406: Exiting
<Wizzup> maybe this is it
<freemangordon> that's ok
<buZz> oh, eh, dont know :P
<Wizzup> ok, maybe not
<freemangordon> Wizzup: looks like some GL transformation matrix is wrong
<Wizzup> I think it happened when I rotated the device during unlock
<freemangordon> if you find a way to repro that'd be cool
<freemangordon> but, as you said, even fremantle suffers from that bug
<freemangordon> I was never able to find any sane way to track or repro
<Wizzup> G_MESSAGES_DEBUG=all ?
<freemangordon> mhm
<freemangordon> but, how would you set that to a running process?
<Wizzup> I didn't, I killed it
<Wizzup> hoping it would re-appear
<Wizzup> but nope
<Wizzup> I suppose I could have made a core dump...
<freemangordon> looks like a bug in some tidy class
<freemangordon> or in clutter itself
<freemangordon> anyway, zzz time, night!
<buZz> nn
<sicelo> < freemangordon> I think we will only need 'hack' for n900 -- what is it missing? extcon?
akossh has quit [Quit: Leaving.]
norayr has quit [Quit: Gateway shutdown]
uvos has joined #maemo-leste
<uvos> it appears i was unbanned
<uvos> great
<Wizzup> hi
norayr has joined #maemo-leste
<buZz> uvos: why were you banned? by who aswell
<buZz> i dont think anyone was banned on this channel in age
<buZz> s
<buZz> 00:21:17 -!- 1 - #maemo-leste: ban *!*@p5deb579e.* [by helium.libera.chat, 6287076 secs ago]
<buZz> pff
<uvos> libera.chat banns me regularly
<buZz> the webchat?
<buZz> we could run our own, i guess
<uvos> no from the servers
<buZz> oh ok
<uvos> i get banned because i share an ip address with all customers of my isp via carrier grade nat
<uvos> and they keep on banning that ip
<buZz> they do use DNSBL or some other list
<buZz> i've been on it, its no fun getting removed
<uvos> and then i have to go though the procedure to get it unbanned
<uvos> this happens qutie regularly
<uvos> yeah dronebl
<buZz> idiot ip range? :P
<buZz> i irc from such range
<buZz> its just so cheap
<uvos> well i could irc from my server 185.53.129.145
<uvos> but its lame
<uvos> i dont want to have to do that
<Wizzup> wb
<norayr> i irc via my xmpp to irc gateway. the software is called biboumi.