elastic_dog has quit [Killed (erbium.libera.chat (Nickname regained by services))]
Pali has quit [Ping timeout: 268 seconds]
xmn has quit [Ping timeout: 268 seconds]
Daanct12 has quit [Read error: Connection reset by peer]
Danct12 has quit [Read error: Connection reset by peer]
Danct12 has joined #maemo-leste
cockroach has quit [Quit: leaving]
joerg has quit [Ping timeout: 240 seconds]
joerg has joined #maemo-leste
mardy has joined #maemo-leste
elastic_dog has quit [Read error: Connection reset by peer]
elastic_dog has joined #maemo-leste
mardy has quit [Ping timeout: 256 seconds]
mardy has joined #maemo-leste
mardy has quit [Ping timeout: 260 seconds]
<freemangordon>
tmlind: uvos: please help, obviously I am doing something stupid, but I cannot figure out what. probe() never gets called https://pastebin.com/Wymn8tpa
<Wizzup>
or maybe this is some debug and it doesn't hang with gconf
<uvos>
ok
<Wizzup>
basically my lock screen didn't respond, but screen did go off after a while
<Wizzup>
when it happens again I'll try to ssh in and see
<uvos>
hmm
<Wizzup>
(it is semi regular)
<Wizzup>
(bionic)
<uvos>
oh ok hmm have not seen sutch a thing
<freemangordon>
BTW< I have coredump from Xorg
<freemangordon>
didn't look at it though
<freemangordon>
uvos: "cpcap-charger cpcap-charger.0: maximum current set to 500 mA"
<uvos>
Wizzup: what makes you think mce specificly hanged?
<Wizzup>
I attached with strace and didn't see a whole lot
<freemangordon>
and it really charges d4 :)
<Wizzup>
and /etc/init.d/mce restart also hanged
<uvos>
sure but if xorg hangs (as happens quite offten) mce will get stuck
<uvos>
just a possiblity
<Wizzup>
ok, that could be
<Wizzup>
brb
<uvos>
freemangordon: ok
<uvos>
dose it work on your 100mA hub btw?
<uvos>
(its at depmod now here)
<freemangordon>
yes, somehow pulling 500 mA :)
<uvos>
hmm
<uvos>
not good
<freemangordon>
oh, lemme remove the power from the hub
<uvos>
the hub surely can supply 500mA if d4 just takes it
<uvos>
esspecaly with just one device connected
<freemangordon>
yeah
<freemangordon>
oh, second d4 with android?
<uvos>
sure
<freemangordon>
yeah, but not now
<uvos>
but also idk if its a totaly great idea
<uvos>
idk how d4 reacts to overload
<freemangordon>
it has wires hanging and stuff :)
<uvos>
it should just trip off
<uvos>
but yeah
<freemangordon>
I'll just wait for you to test :)
<sicelo>
Wizzup: i tried to bisect, but i would end up on wrong commits. i think i'm missing the right trick for avoiding merge commit ... i know the problem doesn't exist in 5.18, but in 5.19 onwards, it's consistently there.
<freemangordon>
sicelo: doesn;t it boot without patches?
<sicelo>
n900 boots vanilla kernel with no issues whatsoever :-)
<freemangordon>
then why merging?
<freemangordon>
just set good to 5.18. bad to 5.19 and start bisectiong
<sicelo>
i'll try again, but it took me to a drm commit or similar :p
<Wizzup>
sicelo: no need to try again if it didn't do anything last tie
<Wizzup>
we'll have to tackle it for sure because mapphone and n900 are now the same kernel
<Wizzup>
(for us)
<sicelo>
well i could use different starting points, etc.
<Wizzup>
you can also tell git bisect to give you another I think
pere has quit [Ping timeout: 260 seconds]
<uvos>
freemangordon: no change in behavior with the xt1602
<uvos>
d4 takes 500mA and reset
<freemangordon>
dmesg?
<uvos>
nothing gets printed
<uvos>
but im a idiot
<Wizzup>
wrong kernel?
<freemangordon>
looks like :)
<uvos>
i have phy_cpcap_usb blacklisted
<freemangordon>
(wrong kernel, not the idiot part :p)
<uvos>
is this relevent
<freemangordon>
sure
<freemangordon>
do gadgets work without it?
<uvos>
it works
<uvos>
d4 dosent activate charging at all
<freemangordon>
:)
<uvos>
xt1602 remains happy
<freemangordon>
nice
<freemangordon>
ok, now, lets see how to upstream all that
<freemangordon>
oh, first I want to finish charger detection
<freemangordon>
somehow, when nokia wall charger is detected, the current drawn is ~1300 mA
<freemangordon>
while with 2.4 A wall charger it is ~1600mA
<freemangordon>
so there must be a way to detect that
<freemangordon>
but not now
<uvos>
ok
<uvos>
anyhow this is a great improvement
<uvos>
no need to be scared of pluging in d4 into random devices...
<freemangordon>
here it works even better, it sets max limit to 500 when connected to USB port and to 1800 when connected to charger
<freemangordon>
once I polish this we will be able to safely remove charge-mode as a requireent
<freemangordon>
*requirement
<Wizzup>
freemangordon: if the usbnet stays alive, do the charging leds still go on and off?
<freemangordon>
no
<freemangordon>
it stays green
<Wizzup>
that is truly great
<freemangordon>
ah,no
<freemangordon>
no
<freemangordon>
wait
<freemangordon>
when the battery is charged, it goes off and on
<Wizzup>
ok
<freemangordon>
but usbnet stays alive
<Wizzup>
still a good improvement :)
<freemangordon>
umm...
<freemangordon>
isnt that an expected behaviour?
<freemangordon>
like, the battery is full
<Wizzup>
on the n900 the led stays green
<Wizzup>
but this is likely interaction with the battery subsystem
<freemangordon>
grennled here means "charging"
<freemangordon>
off means "charged"
<Wizzup>
maybe this is because we let cpcap/kernel control led vs userspace
<freemangordon>
yes
<freemangordon>
it seems all android devices behave like that
<uvos>
no
<freemangordon>
green for charging off for full
<uvos>
well hw implementation
<freemangordon>
well, all I see around are like that
<uvos>
first thing android dose it remove cpcaps hw controll of the led
<uvos>
but yes its sw controll looks the same
<freemangordon>
I guess we can fix that
<freemangordon>
btw, why did you blacklist the phy?
<uvos>
sure its just a reg you set
<sicelo>
my S7 stays green on full
<Wizzup>
we should have all the bits in place for it already
<uvos>
but we need some way to set it
<uvos>
idk what would be a good interface for this
<uvos>
durring boot before mce becomes active we want cpcap to controll the led after all
<freemangordon>
device quirk?
<Wizzup>
I think on the n900 mce does it
<uvos>
freemangordon: sure i mean kernel interface
<freemangordon>
ah
<uvos>
freemangordon: just a random sysfs file i gues
<uvos>
but maybe somthing better can be devised
<freemangordon>
mhm
<Wizzup>
I suppose it could be some led sysfs file
<uvos>
right
<Wizzup>
I think this is what it is for n900
<uvos>
i gues the best way would be the led triggers file
<freemangordon>
uvos: do you want the full patch to test? including charger detection etc?
<Wizzup>
(but I am not sure)
<Wizzup>
freemangordon: we could build it for -devel too if it's ready for further testing
<uvos>
freemangordon: i think i would like to just build it for leste
<uvos>
so a branch
<freemangordon>
I want tmlind to comment on it first
<uvos>
freemangordon: ok
<uvos>
then lets just wait
<sicelo>
Wizzup: the led control is in charger (bq24150)
<Wizzup>
uvos: looks like planet.bin is 46GB btw (navit)
<freemangordon>
as there are few changes in cpcap phy
<Wizzup>
sicelo: check, ty
<uvos>
Wizzup: uff
<Wizzup>
uvos: well there's maps of many countries in europe but somehow not croatia :P
<uvos>
i have just hesse mostly on my sdcard
<freemangordon>
zzz time, night!
<uvos>
good night freemangordon
<Wizzup>
gn
<uvos>
hesse (german state) is about 500MB
<uvos>
for referance
<Wizzup>
did you make it yourself?
<uvos>
hmm good question
<uvos>
i honstly dont remmeber where i got the file
<uvos>
freemangordon: "btw, why did you blacklist the phy?"
akossh has quit [Remote host closed the connection]
Twig has quit [Remote host closed the connection]
pere has joined #maemo-leste
elastic_dog has quit [Ping timeout: 240 seconds]
elastic_dog has joined #maemo-leste
<norayr>
glad to see the work on mz609. that is 8 inch tablet.
<norayr>
mz617 xyboard 10.1, 10 inch tablet, uses the same TI OMAP 4430
<norayr>
but if mz609 works with maemo it doesnt mean that mz617 will work, right?
<norayr>
i don't even know which i want.
<norayr>
i just know we need tablet.
uvos has quit [Ping timeout: 268 seconds]
<mogolobogo[m]>
<uvos> "its just absurdly slow at..." <- Do you possibly have a config example somewhere? Might be very helpful on a wiki as well ?
<mogolobogo[m]>
<Wizzup> "but since monav is removed..." <- Might it be possible or a good plan to add mepo to the repos? I believe that is the pinephone standard
<BlagovestPetrov[>
guys, is there any documentation about the GTK api?
<BlagovestPetrov[>
how is the menu generated, is it using dbus?