libera/#maemo-leste/ Tuesday, 2022-02-15

freemangordonuvos: eglinfo reports "wrong' caps as it tries to use /dev/dri/card0 with pvr dri and fails08:32
freemangordonso it does fallback to kms_swrast(I guess)08:32
freemangordonthis is not the same as what happens with sdl08:33
freemangordonpvr *does not* report OGL as being supported08:34
freemangordonso that's not the issue08:34
freemangordonwill see later on if I can debug08:35
freemangordonrenaming card0<->card1 makes eglinfo report correct API support (no OGL)08:54
Wizzupah09:18
uvosfreemangordon: right eglinfo reports on the caps of sw rendering12:09
uvosfreemangordon: but when you go to create a context you get pvr12:10
uvosfreemangordon: ie if i print glGetString(GL_RENDERER) in gles2 mode in charging_sdl i get PowerVR SGX 54012:10
freemangordonsure, but that's another issue12:10
uvosright12:10
freemangordonok, but that's gles212:10
freemangordonnot ogl12:10
uvossure12:10
uvosbut if egl is reporing on sw rendering12:10
freemangordonand I can assure you pvr does not report OGL12:11
uvosit must provide sw rendering when creating a context12:11
uvosthats why ogl fails12:11
uvosit tries to create a context with pvr12:11
freemangordonI think it is something else12:11
uvosthe gles2 caps are wrong too12:11
freemangordonbecause renaming card0<->card1 does not fix segfault12:12
freemangordonwhat do you mean?12:12
freemangordonuvos: I think it is an issue in sdl, IIUC it detects OGL support by checking for libGL.so presence12:13
uvosfreemangordon: even if thats true, reporting on the caps of swrast in egl but then creating a pvr context is wrong.12:14
uvosit causes the extensions strign to be wrong and the supported configurations too12:14
uvoseven just for gles212:15
freemangordonwhy do you think it reports swrast caps to sdl?12:15
freemangordondo yo uhave some traces?12:15
uvosegl caps12:15
uvosno gles caps12:15
freemangordonwhere?12:15
uvosit gets pvr gles12:15
freemangordonhow do you know that?12:15
uvosin egl info, this is irrelivant to if sdl reads it12:15
uvosif you read egl12:15
uvosyou get caps of swrast12:16
uvosif you create a context you get pvr12:16
freemangordondo we have a test case?12:16
uvosdisgarding what egl sais about support apis12:16
uvosits wrong12:16
freemangordonuvos: lemme rephrase - I am not arguing if it is wrong or correct12:16
freemangordonI want you to provide test case to repro here12:16
uvoswell eglinfo reports on swrast dri no?12:17
freemangordonthat way I will be able to debug and see what happens12:17
uvosand if you create a gles2 context with sdl you get glGetString(GL_RENDERER) == SGX12:17
freemangordoneglinfo reports correct things12:17
uvosso the caps cant possible be right12:17
uvossince mesa provided pvr later12:17
freemangordonwait, I think we are mixing EGL with GLES212:18
uvosno12:18
uvosegl must report the configurations its gles2 implementation supports12:18
uvoslike if pvr dident support gles2 on 16 bit12:18
freemangordonit does12:18
uvosit should not report that as a valid configuration12:18
freemangordonit supports it and reports it12:18
uvosfreemangordon: i know but if it dident it wouls _STILL_ report is as availble because swrast supports it12:19
freemangordonpvr supports gles2 on 16 bit12:19
uvosi know12:19
uvosegl would report it available regardless of wheather pvr supports or not12:19
uvosbecuase the caps are from swrasw12:19
freemangordonuvos: sorry, I got lost, so, lemme try to explain what happens IMO:12:19
freemangordoneglinfo 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_swrast12:20
uvosright so configureations reflect swrast12:21
uvosthen the application cooses one12:21
uvosand asks egl for a context12:21
freemangordonif you rename card0<->card1 then eglinfo correctly reports ES only12:21
uvosupon asking egl for a context mesa then chooses pvr because ofMESA_LOADER_DRIVER_OVERRIDE12:21
uvosregardless of the context choosen12:21
freemangordonmaybe this is because of MESA_LOADER_DRIVER_OVERRIDE12:22
freemangordonyeah12:22
uvosand that obv fails12:22
freemangordonbut this is not a bug in mesa or pvr12:22
uvosif the configuration you choose is not supported by both pvr and swrast12:22
freemangordonah, I see what you mean12:22
freemangordonroot@devuan-droid4:~/mesa# unset MESA_LOADER_DRIVER_OVERRIDE12:23
freemangordonroot@devuan-droid4:~/mesa# ./egltest12:23
freemangordonxcb_connection_has_error() returned true12:23
freemangordonMESA-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)12:23
freemangordonfailed to load driver: omapdrm12:23
freemangordonSegmentation fault12:23
freemangordonI don;t think that supports your theory12:23
freemangordonuvos: ^^^12:24
uvosdosent matter (theroy wise)12:24
uvosits reporing on swrast es2 configurations12:24
uvosand you get pvr when you create the context12:24
uvosthats provable by reading glGetString(GL_RENDERER)12:24
freemangordonhmm12:24
uvosand is wrong allready12:24
uvoslike if i decide to change swrast to not support  gles2 @32 bit depth12:25
uvosthen egl will report that as not available12:25
uvoseven tho pvr supports it12:25
uvosie this its wrong allready12:25
freemangordonthat's a bug in mesa then12:25
uvosright i suspect so12:26
freemangordonbut, I see pvr gets called to return supported contexts12:26
uvosas mentioned before eglinfo on my desktop amdgpu machine also dosent make sense12:26
freemangordonbut, if you are right, modesetting will not work too12:27
freemangordonunless I miss something12:27
uvosnot really12:27
uvosany application could work12:27
uvosby catching the context creating fails and trying again with a different configuration12:28
uvos(or getting lucky by choosing the right one)12:28
freemangordonok, why SDL does not work then?12:28
freemangordon16bits are supported by pvr12:28
uvosit fails to catch that context creation fails12:28
freemangordonwhy context creatin fails?12:28
uvosbecause it tries opengl first12:29
freemangordonyes, but why? because of the libGL.so presence?12:29
freemangordonif that's the case (and I suspect so), even if there are issues in mesa, this is pure bug in SDL12:30
uvosno because it works on x11 where egl reports12:30
uvosno opengl12:30
uvosit chooses gles12:30
uvoson gbm it chooses opengl12:30
freemangordonwhy?12:30
freemangordonah12:30
uvosi strongly suspect the fact that egl reports opengl available is the reason12:30
freemangordonno12:30
freemangordonI already debug that12:31
freemangordonand no opengl support is announced12:31
freemangordonbut, will debug again12:31
uvosif you flip card0 , 1?12:31
freemangordondoes not matter12:31
uvosbut if you flip card0 and 112:31
freemangordonogl is not reported in mesa I have here12:32
uvosok12:32
uvosegl dose not report card012:32
uvosok12:32
uvoser egl dose not report ogl12:32
freemangordonI #ifdef-ed all OGL stuff in pvr12:32
freemangordonyes, because it uses pvr then12:32
uvosso? whats your eglinfo?12:32
freemangordonif you mean eglinfo12:32
freemangordonwith cards swapped?12:32
freemangordonsec12:33
freemangordonuvos: https://pastebin.com/QJYgLMfJ12:36
freemangordonwith cards swapped12:36
uvosand with cards swapped12:36
uvossdl still segfaults12:36
freemangordonyes12:36
uvosok12:36
uvosthats a sdl bug12:36
uvosprobubly12:36
freemangordonhave to attend $work$ mtg, ttyl12:37
freemangordonagree12:37
freemangordonuvos: BTW, iven without my #ifdefs, with cards swapped eglinfo still reports "EGL client APIs: OpenGL_ES"12:45
freemangordon*even12:45
freemangordonalso, I don;t agree that always swrast caps are reported12:46
freemangordonthis is for swrast https://pastebin.com/P6fcSDFV12:47
uvosthats exatly the same12:49
freemangordonnot really12:50
uvosas what eglinfo reports where with MESA_LOADER_DRIVER_OVERRIDE=pvr12:50
freemangordonno, it is not12:50
freemangordonpvr reports 12 contaxts12:50
freemangordonswrast 0x1e12:50
uvosright12:51
uvosbut if you dont swap cards12:51
freemangordonalso "EGL client APIs: OpenGL OpenGL_ES "12:51
uvosyou get swrast12:51
uvosi get the same thing12:51
freemangordonbut that's a bug in eglinfo12:51
freemangordonwhich uses wrong card12:51
freemangordonSDL is smarter and uses the correct card12:51
uvoshow is it suppoed to know what is the correct card?12:51
freemangordondidn;t verify12:52
freemangordonbut somehow passes the correct fd to gbm functions12:52
uvoshmm12:52
uvosim not sure how you would know12:52
freemangordonby setting a breakpoint in   PVRDRIInitScreen and checking the fd member of   psDRIScreen in /proc/$pid12:54
uvosno i mean how an applicaion would know12:54
freemangordonah12:54
uvoswhat card12:54
freemangordonwell, that's why most apps have a cmdline parameter to pass the dri card12:54
freemangordonkmscube for example12:55
freemangordonsame for modesetting12:55
freemangordonttyl12:55
uvoshttps://gitlab.freedesktop.org/mesa/demos/-/blob/main/src/egl/opengl/eglinfo.c12:55
uvoseglinfo dosent choos a card at al12:55
uvosmesa dose it for it based on eglQueryDevicesEXT i gues, not sure12:57
marabejHi 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?15:05
uvosyou could boot linux with safestrap but its complicated and really annoying and we dont support it15:07
Wizzupiirc we recommend using kexecboot - you can use kexecboot to boot to safestrap and android15:07
uvosinstalling kexecboot dosent remove safestrap15:07
uvosbut its a bit buggy15:07
uvosbut you can boot safestrap android images from kexec boot15:07
uvosthat works very well15:07
uvosinstrucitons are here: https://github.com/tmlind/droid4-kexecboot/blob/master/CONFIGURATION15:08
uvossee entrys on bootling safestrap rom slots15:08
marabej"but its a bit buggy" - for example?  what bug?  I just don't want to remove safestrap16:11
sixwheeledbeastWhat sort of battery duration should I be expecting on Leste/N900? Brand new polarcell getting around 4-5 hours of standby with only wifi?16:11
marabejThank you for the link which you provided about configuration16:11
Wizzupsixwheeledbeast: yes, leste does not enter RET/OFF mode yet, even on 5.15, because some drivers need more PM work16:11
Wizzupon the droid4 you can expect 2 days16:11
WizzupI started working on the n900 PM, but there's quite a bit to do there16:12
sixwheeledbeastso it sounds about right for now?16:12
WizzupI would expect a bit more, maybe 8 hours, but yeah16:12
Wizzupwithout leste ui it can last much longer (in off mode)16:12
Wizzupbut debugging that fixing drivers takes time and patience16:13
Wizzuphttps://github.com/maemo-leste/bugtracker/issues/545#issuecomment-980458784 and below16:13
sixwheeledbeastUnderstood.16:14
uvosmarabej: 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 hack16:31
uvosim also not sure why you want to keep safestrap16:33
uvosits pretty mutch obsolete at this point16:33
bencoh17:12 < Wizzup> without leste ui it can last much longer (in off mode)16:39
bencohhm, actually that sounds good / promising16:40
bencoh(I kinda hope pvr isn't the one preventing OFF mode though :])16:40
Wizzupit is not16:41
Wizzupuvos: heh https://www.ebay.com/itm/16501370879616:44
uvosWizzup: this again? :P16:46
uvosWizzup: what do you want with those :D16:47
Wizzupnothing16:47
Wizzupjust saw them16:47
Wizzup:D16:47
uvoslooking at d4 sales it seams like supply is just 2/month or so by now16:48
Wizzupmhm16:48
uvoscompeard to 2019 thats not so hot16:48
Wizzupyeah16:48
tmlinduvos: 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 regs17:04
tmlinduvos: any chance you could manually tweak some mz617 gpios and run i2cdump on those regs to restore for me at some point? :)17:04
tmlinduvos: meanwhile best not to configure any of the lcd stuff in the dts, the gpio in question is gpio_4017:05
tmlinduvos: i don't think this can be easily tested from android as it's in a different mode17:06
tmlinduvos: i think gpio_40 defaults to 0 which is the risky mode for any i2c access17:07
tmlindwell at least that's the theory right now without knowning the good reg values17:07
tmlindmine ended up with nothing on the lcd on boot :)17:09
uvostmlind: sure yeah. tell me what to do17:09
tmlinduvos: so first if 0 out the lcd stuff from your dts17:14
tmlinduvos: then boot mz617 and manually set the bridge gpios 40 and 46 to the bad values17:14
tmlindjust a sec i'll paste the gpio commands17:14
tmlindecho -n 96 > /sys/class/gpio/export     # LCD regulator17:17
tmlindecho -n 46 > /sys/class/gpio/export     # lvds_wp_e17:17
tmlindecho -n 40 > /sys/class/gpio/export     # lvds_wp_g17:17
tmlindecho out > /sys/class/gpio/gpio96/direction17:17
tmlindecho out > /sys/class/gpio/gpio46/direction17:17
tmlindecho out > /sys/class/gpio/gpio40/direction17:17
tmlindecho 1 > /sys/class/gpio/gpio96/value17:17
tmlindecho 0 > /sys/class/gpio/gpio40/value   # This should be normally kept high17:17
tmlindecho 1 > /sys/class/gpio/gpio46/value17:17
tmlindi2cdump -f -y 0 0x5017:17
tmlindthat should produce the bridge reg values to restore17:17
tmlindandroid should have both 40 and 46 high when lcd is in use afaik17:17
freemangordonhmm, d4 hung on powerdown and no WD kicked17:19
freemangordonis that normal/expected?17:20
uvosits related to serial oops i think17:20
uvossometimes some processies hang17:20
freemangordonit is17:20
uvosand then its stuck17:20
freemangordonbut I would expect WD reset17:20
uvosno17:20
uvosits not fully stuck17:20
uvosjust userspace17:20
uvosso it remains in limbo17:20
freemangordondsme still kicks WD?17:20
freemangordonhmmm17:20
uvosits init failing to kill a process in permanent D state17:21
uvosbecuase of the oops17:21
uvosiirc17:21
uvosso yeah dsme would be fine17:21
sicelosixwheeledbeast: 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?17:32
marabejuvos, 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 maemo17:32
uvosthere is not need to remove safestrap, but otherwise yeah17:32
Wizzupalso the android one is automatically there, I don't think you need to add it manually17:33
Wizzup(slot)17:33
uvosno17:33
uvosthe one that boots safestrap is, but not the ones that boot safestrap slots17:34
Wizzupright17:34
sixwheeledbeastsicelo: nope new battery just sat on my desk not doing much17:49
sixwheeledbeastreads 1700mAh in the status applet17:50
siceloof 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?17:52
sixwheeledbeasthow can i check?17:54
tmlindWizzup, uvos, freemangordon: so are you guys seeing the shutdown issue every time or just sometimes?19:34
uvostmlind: yes, unless you avoid detaching the kernel console by not running the droid4-pm script19:35
uvostmlind: 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)19:36
tmlinduvos: ok trying understand what's going on19:40

Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!