TonyStone has quit [Remote host closed the connection]
TonyStone has joined #maemo-leste
Pali has quit [Ping timeout: 240 seconds]
macros__ has quit [Ping timeout: 252 seconds]
macros__ has joined #maemo-leste
Oksanaa has quit [Ping timeout: 240 seconds]
Oksanaa has joined #maemo-leste
TonyStone has quit [Quit: Leaving]
System_Error has quit [Ping timeout: 240 seconds]
System_Error has joined #maemo-leste
joerg has quit [Ping timeout: 256 seconds]
joerg has joined #maemo-leste
macros_ has quit [Ping timeout: 250 seconds]
mardy has joined #maemo-leste
macros__ has quit [Ping timeout: 272 seconds]
pere has quit [Ping timeout: 240 seconds]
rafael2k has joined #maemo-leste
macros__ has joined #maemo-leste
macros_ has joined #maemo-leste
<freemangordon>
uvos: eglinfo reports "wrong' caps as it tries to use /dev/dri/card0 with pvr dri and fails
<freemangordon>
so it does fallback to kms_swrast(I guess)
<freemangordon>
this is not the same as what happens with sdl
<freemangordon>
pvr *does not* report OGL as being supported
<freemangordon>
so that's not the issue
macros_ has quit [Ping timeout: 250 seconds]
<freemangordon>
will see later on if I can debug
pere has joined #maemo-leste
<freemangordon>
renaming card0<->card1 makes eglinfo report correct API support (no OGL)
<Wizzup>
ah
Pali has joined #maemo-leste
macros_ has joined #maemo-leste
macros_ has quit [Ping timeout: 250 seconds]
xmn has quit [Quit: ZZZzzz…]
_inky has joined #maemo-leste
uvos has joined #maemo-leste
<uvos>
freemangordon: right eglinfo reports on the caps of sw rendering
<uvos>
freemangordon: but when you go to create a context you get pvr
<uvos>
freemangordon: ie if i print glGetString(GL_RENDERER) in gles2 mode in charging_sdl i get PowerVR SGX 540
<freemangordon>
sure, but that's another issue
<uvos>
right
<freemangordon>
ok, but that's gles2
<freemangordon>
not ogl
<uvos>
sure
<uvos>
but if egl is reporing on sw rendering
<freemangordon>
and I can assure you pvr does not report OGL
<uvos>
it must provide sw rendering when creating a context
<uvos>
thats why ogl fails
<uvos>
it tries to create a context with pvr
<freemangordon>
I think it is something else
<uvos>
the gles2 caps are wrong too
<freemangordon>
because renaming card0<->card1 does not fix segfault
<freemangordon>
what do you mean?
<freemangordon>
uvos: I think it is an issue in sdl, IIUC it detects OGL support by checking for libGL.so presence
<uvos>
freemangordon: even if thats true, reporting on the caps of swrast in egl but then creating a pvr context is wrong.
<uvos>
it causes the extensions strign to be wrong and the supported configurations too
<uvos>
even just for gles2
<freemangordon>
why do you think it reports swrast caps to sdl?
<freemangordon>
do yo uhave some traces?
macros_ has joined #maemo-leste
<uvos>
egl caps
<uvos>
no gles caps
<freemangordon>
where?
<uvos>
it gets pvr gles
<freemangordon>
how do you know that?
<uvos>
in egl info, this is irrelivant to if sdl reads it
<uvos>
if you read egl
<uvos>
you get caps of swrast
<uvos>
if you create a context you get pvr
<freemangordon>
do we have a test case?
<uvos>
disgarding what egl sais about support apis
<uvos>
its wrong
<freemangordon>
uvos: lemme rephrase - I am not arguing if it is wrong or correct
<freemangordon>
I want you to provide test case to repro here
<uvos>
well eglinfo reports on swrast dri no?
<freemangordon>
that way I will be able to debug and see what happens
<uvos>
and if you create a gles2 context with sdl you get glGetString(GL_RENDERER) == SGX
<freemangordon>
eglinfo reports correct things
<uvos>
so the caps cant possible be right
<uvos>
since mesa provided pvr later
<freemangordon>
wait, I think we are mixing EGL with GLES2
<uvos>
no
<uvos>
egl must report the configurations its gles2 implementation supports
<uvos>
like if pvr dident support gles2 on 16 bit
<freemangordon>
it does
<uvos>
it should not report that as a valid configuration
<freemangordon>
it supports it and reports it
<uvos>
freemangordon: i know but if it dident it wouls _STILL_ report is as availble because swrast supports it
<freemangordon>
pvr supports gles2 on 16 bit
<uvos>
i know
<uvos>
egl would report it available regardless of wheather pvr supports or not
<uvos>
becuase the caps are from swrasw
<freemangordon>
uvos: sorry, I got lost, so, lemme try to explain what happens IMO:
mepy has quit [Ping timeout: 272 seconds]
<freemangordon>
eglinfo report both OGL and GLES because it opens wrong /dev/dri/cardN and PVR DRI refuses to use that fd so mesa switches to kms_swrast
<uvos>
right so configureations reflect swrast
<uvos>
then the application cooses one
<uvos>
and asks egl for a context
<freemangordon>
if you rename card0<->card1 then eglinfo correctly reports ES only
<uvos>
upon asking egl for a context mesa then chooses pvr because ofMESA_LOADER_DRIVER_OVERRIDE
<uvos>
regardless of the context choosen
<freemangordon>
maybe this is because of MESA_LOADER_DRIVER_OVERRIDE
<freemangordon>
yeah
<uvos>
and that obv fails
<freemangordon>
but this is not a bug in mesa or pvr
<uvos>
if the configuration you choose is not supported by both pvr and swrast
<freemangordon>
MESA-LOADER: failed to open omapdrm: /usr/lib/dri/omapdrm_dri.so: cannot open shared object file: No such file or directory (search paths /usr/lib/arm-linux-gnueabihf/dri:\$${ORIGIN}/dri:/usr/lib/dri, suffix _dri)
<freemangordon>
failed to load driver: omapdrm
<freemangordon>
xcb_connection_has_error() returned true
<freemangordon>
Segmentation fault
<freemangordon>
I don;t think that supports your theory
<freemangordon>
uvos: ^^^
<uvos>
dosent matter (theroy wise)
<uvos>
its reporing on swrast es2 configurations
<uvos>
and you get pvr when you create the context
<uvos>
thats provable by reading glGetString(GL_RENDERER)
<freemangordon>
hmm
<uvos>
and is wrong allready
<uvos>
like if i decide to change swrast to not support gles2 @32 bit depth
<uvos>
then egl will report that as not available
<uvos>
even tho pvr supports it
<uvos>
ie this its wrong allready
<freemangordon>
that's a bug in mesa then
<uvos>
right i suspect so
<freemangordon>
but, I see pvr gets called to return supported contexts
<uvos>
as mentioned before eglinfo on my desktop amdgpu machine also dosent make sense
<freemangordon>
but, if you are right, modesetting will not work too
<freemangordon>
unless I miss something
<uvos>
not really
<uvos>
any application could work
<uvos>
by catching the context creating fails and trying again with a different configuration
<uvos>
(or getting lucky by choosing the right one)
<freemangordon>
ok, why SDL does not work then?
<freemangordon>
16bits are supported by pvr
<uvos>
it fails to catch that context creation fails
<freemangordon>
why context creatin fails?
<uvos>
because it tries opengl first
<freemangordon>
yes, but why? because of the libGL.so presence?
<freemangordon>
if that's the case (and I suspect so), even if there are issues in mesa, this is pure bug in SDL
<uvos>
no because it works on x11 where egl reports
<uvos>
no opengl
<uvos>
it chooses gles
<uvos>
on gbm it chooses opengl
<freemangordon>
why?
<freemangordon>
ah
<uvos>
i strongly suspect the fact that egl reports opengl available is the reason
<freemangordon>
no
<freemangordon>
I already debug that
<freemangordon>
and no opengl support is announced
<freemangordon>
but, will debug again
<uvos>
if you flip card0 , 1?
<freemangordon>
does not matter
<uvos>
but if you flip card0 and 1
<freemangordon>
ogl is not reported in mesa I have here
<uvos>
mesa dose it for it based on eglQueryDevicesEXT i gues, not sure
rafael2k has quit [Ping timeout: 272 seconds]
marabej has joined #maemo-leste
cockroac1 has joined #maemo-leste
macros_ has quit [Ping timeout: 250 seconds]
<marabej>
Hi guys. I received a week ago Motorola Droid 4. It has safestrap 3.75 and Android 4.1.2 installed in the stock slot. For trying Maemo Leste, should I install kexecboot or It can boot the linux by safestrap? Or If I install kexecboot, will it remove the SafeStrap or will be installed alongside it?
<uvos>
you could boot linux with safestrap but its complicated and really annoying and we dont support it
<Wizzup>
iirc we recommend using kexecboot - you can use kexecboot to boot to safestrap and android
sunshavi has quit [Remote host closed the connection]
sunshavi has joined #maemo-leste
mepy has joined #maemo-leste
<marabej>
"but its a bit buggy" - for example? what bug? I just don't want to remove safestrap
<sixwheeledbeast>
What sort of battery duration should I be expecting on Leste/N900? Brand new polarcell getting around 4-5 hours of standby with only wifi?
<marabej>
Thank you for the link which you provided about configuration
<Wizzup>
sixwheeledbeast: yes, leste does not enter RET/OFF mode yet, even on 5.15, because some drivers need more PM work
<Wizzup>
on the droid4 you can expect 2 days
<Wizzup>
I started working on the n900 PM, but there's quite a bit to do there
<sixwheeledbeast>
so it sounds about right for now?
<Wizzup>
I would expect a bit more, maybe 8 hours, but yeah
<Wizzup>
without leste ui it can last much longer (in off mode)
<Wizzup>
but debugging that fixing drivers takes time and patience
<uvos>
marabej: kexecboot -> safestrap -> rom slot boot chain hangs the device pretty often, im not sure why but it dosent matter because invoking the rom slot directly from kexecboot works fine and compeard to kexecboot safestrap is a terrible hack
<uvos>
im also not sure why you want to keep safestrap
<uvos>
its pretty mutch obsolete at this point
pere has quit [Ping timeout: 240 seconds]
<bencoh>
17:12 < Wizzup> without leste ui it can last much longer (in off mode)
<bencoh>
hm, actually that sounds good / promising
<bencoh>
(I kinda hope pvr isn't the one preventing OFF mode though :])
<uvos>
looking at d4 sales it seams like supply is just 2/month or so by now
<Wizzup>
mhm
<uvos>
compeard to 2019 thats not so hot
<Wizzup>
yeah
<tmlind>
uvos: so i had some progress with the mz617 lcd and got it to probe.. but looks like one of the bridge gpios is some test mode gpio and i2c access with that set trashed what seem to be some eeprom regs
<tmlind>
uvos: any chance you could manually tweak some mz617 gpios and run i2cdump on those regs to restore for me at some point? :)
<tmlind>
uvos: meanwhile best not to configure any of the lcd stuff in the dts, the gpio in question is gpio_40
pere has joined #maemo-leste
<tmlind>
uvos: i don't think this can be easily tested from android as it's in a different mode
<tmlind>
uvos: i think gpio_40 defaults to 0 which is the risky mode for any i2c access
<tmlind>
well at least that's the theory right now without knowning the good reg values
<tmlind>
mine ended up with nothing on the lcd on boot :)
<uvos>
tmlind: sure yeah. tell me what to do
<tmlind>
uvos: so first if 0 out the lcd stuff from your dts
<tmlind>
uvos: then boot mz617 and manually set the bridge gpios 40 and 46 to the bad values
<tmlind>
echo out > /sys/class/gpio/gpio96/direction
<tmlind>
echo out > /sys/class/gpio/gpio40/direction
<tmlind>
echo 1 > /sys/class/gpio/gpio96/value
<tmlind>
echo 0 > /sys/class/gpio/gpio40/value # This should be normally kept high
<tmlind>
echo 1 > /sys/class/gpio/gpio46/value
<tmlind>
i2cdump -f -y 0 0x50
<tmlind>
that should produce the bridge reg values to restore
<tmlind>
android should have both 40 and 46 high when lcd is in use afaik
<freemangordon>
hmm, d4 hung on powerdown and no WD kicked
<freemangordon>
is that normal/expected?
<uvos>
its related to serial oops i think
<uvos>
sometimes some processies hang
<freemangordon>
it is
<uvos>
and then its stuck
<freemangordon>
but I would expect WD reset
<uvos>
no
<uvos>
its not fully stuck
<uvos>
just userspace
<uvos>
so it remains in limbo
<freemangordon>
dsme still kicks WD?
<freemangordon>
hmmm
<uvos>
its init failing to kill a process in permanent D state
<uvos>
becuase of the oops
<uvos>
iirc
<uvos>
so yeah dsme would be fine
macros_ has joined #maemo-leste
<sicelo>
sixwheeledbeast: while i haven't run Leste on my N900 in a long time (probably more than a year now), my not-so-special battery did 8 hours as Wizzup hinted. Yours should do more. Or this is with active use?
<marabej>
uvos, I'm noob and because of that I asked about safestrap. So It's better to remove safestrap and after that install kexecboot. In kexecboot I should add the android slot and maemo
<uvos>
there is not need to remove safestrap, but otherwise yeah
<Wizzup>
also the android one is automatically there, I don't think you need to add it manually
<Wizzup>
(slot)
<uvos>
no
<uvos>
the one that boots safestrap is, but not the ones that boot safestrap slots
<Wizzup>
right
macros_ has quit [Ping timeout: 252 seconds]
halftux has joined #maemo-leste
<sixwheeledbeast>
sicelo: nope new battery just sat on my desk not doing much
<sixwheeledbeast>
reads 1700mAh in the status applet
<sicelo>
of course possible that it still needs another calibration cycle (recall bq27200 doesn't accept change more than about 6% at a time). but yes, 4-5 hours seems excessively short. what's the current or power consumption reported by bq27200 when you're not using the device?
pere has quit [Ping timeout: 252 seconds]
<sixwheeledbeast>
how can i check?
macros_ has joined #maemo-leste
halftux has left #maemo-leste [maemo]
sunshavi has quit [Read error: Connection reset by peer]
sunshavi has joined #maemo-leste
pere has joined #maemo-leste
__20h__ has quit [Quit: WeeChat 3.0.1]
__20h__ has joined #maemo-leste
<tmlind>
Wizzup, uvos, freemangordon: so are you guys seeing the shutdown issue every time or just sometimes?
<uvos>
tmlind: yes, unless you avoid detaching the kernel console by not running the droid4-pm script
<uvos>
tmlind: im pretty sure i also tried just not detaching the console in the script and that was fine to, so its explicitly the detach (or it occures when shuting down the driver whilest the device is idle or so)
<tmlind>
uvos: ok trying understand what's going on
akossh has joined #maemo-leste
uvos has quit [Remote host closed the connection]
mardy has quit [Quit: WeeChat 2.8]
macros_ has quit [Quit: Konversation terminated!]
macros_ has joined #maemo-leste
_inky has quit [Remote host closed the connection]
_inky has joined #maemo-leste
xmn has quit [Ping timeout: 272 seconds]
pere has quit [Ping timeout: 272 seconds]
_inky has quit [Remote host closed the connection]
_inky has joined #maemo-leste
akossh has quit [Quit: Leaving.]
sunshavi has quit [Ping timeout: 272 seconds]
TonyStone has joined #maemo-leste
sunshavi has joined #maemo-leste
macros_ has quit [Ping timeout: 272 seconds]
uvos has joined #maemo-leste
<uvos>
tmlind: my mz617 hangs at [ 14.474121] calling emif_driver_init+0x0/0x1000 [emif] @ 491
<uvos>
we had this before
<uvos>
what was the solution again
<uvos>
(the hang is right after udev probes the modules
<uvos>
)
macros_ has joined #maemo-leste
mepy has quit [Quit: Leaving]
macros__ has quit [*.net *.split]
enyc has quit [*.net *.split]
Evil_Bob has quit [*.net *.split]
zmatt has quit [*.net *.split]
r3boot has quit [*.net *.split]
macros_ has quit [Ping timeout: 240 seconds]
Evil_Bob has joined #maemo-leste
zmatt has joined #maemo-leste
r3boot has joined #maemo-leste
macros__ has joined #maemo-leste
enyc has joined #maemo-leste
enyc has quit [Max SendQ exceeded]
enyc has joined #maemo-leste
<uvos>
perhaps unsuprisingly removing emif from dts worked