| freemangordon | uvos: ok, will check | 08:08 |
|---|---|---|
| freemangordon | Wizzup: re crashes: maybe implementing ReuseBuffer function in DDX will fix it | 08:09 |
| Wizzup | freemangordon: mhm | 11:28 |
| Wizzup | uvos: is https://github.com/maemo-leste/clown-boot up to date for droid3? | 11:54 |
| Wizzup | BlagovestPetrov[: wants to try it on the d3 | 11:54 |
| uvos | Wizzup: no i havent finished the combination yet | 11:56 |
| uvos | im not sure on what to do about android 4.1 bionics | 11:56 |
| uvos | speaking of witch | 11:57 |
| uvos | "<huckg> I'm still having trouble with droid bionic; I am on step 8 of https://github.com/IMbackK/bionic-clown-boot and getting Sending 'mbm' (256 KB) FAILED (remote: 'unsupported command') despite having upgraded to latest Android platform-tools as uvos suggested." | 11:57 |
| uvos | we missed that | 11:57 |
| Wizzup | uvos: ok so probably better if we use mine atm https://github.com/MerlijnWajer/bionic-clown-boot/tree/solana | 11:57 |
| uvos | Wizzup: right | 11:57 |
| uvos | Wizzup: for solana yeah | 11:57 |
| BlagovestPetrov[ | thanks :) | 11:58 |
| uvos | my d3 rebooted sometime tonight | 11:59 |
| uvos | :( | 11:59 |
| uvos | huckg: if you read the logs: i dont really know whats up with your device so your trying "fastboot flash mbm allow-mbmloader-flashing-mbm.bin", "fastboot --version" gives you "fastboot version 31.0.3-android-tools" or later your allow-mbmloader-flashing-mbm.bin has sha1sum of e44585ce14524e366df485f2784a0acc49d396c8 and your bootloader version, as displaied on device in fastboot mode is 0A.72 or 0A.78 right? | 12:05 |
| Wizzup | uvos: yeah I get freezes within minutes of interacting with the device | 12:06 |
| Wizzup | uvos: I'll have to check and see what happens if I don't detach kerne lconsole | 12:06 |
| uvos | Wizzup: ok | 12:06 |
| uvos | on thing to check might be the EMIF registers on android vs on leste (at load) and compear it with d4 | 12:07 |
| uvos | catching it on serial is a good mission too ofc | 12:08 |
| uvos | as it testing with idle states disabled | 12:08 |
| uvos | i also wonder if the hangs happen | 12:11 |
| uvos | if you kexec to kernel 3.0.8 (ie safestrap) and then kexec to mainline | 12:12 |
| uvos | maybe the old kernel's inialization state is tripping us up | 12:12 |
| Wizzup | yeah, could be for sure | 12:12 |
| Wizzup | uvos: I am also seeing a delay on the d4 to detect it is discharging | 12:46 |
| Wizzup | at least in upower | 12:47 |
| uvos | some delay is expected | 12:52 |
| uvos | the ramp up takes about 1s | 12:52 |
| uvos | and the battery is reported charging only when its compleate | 12:52 |
| Wizzup | ok | 13:01 |
| Wizzup | it took maybe 30+ s or so | 13:01 |
| Wizzup | which is I think the upower poll interval if it gets no other info | 13:01 |
| freemangordon | Wizzup: uvos: or, maybe I shall stop spending time on omap DDX and get back to our initial plan now fence bug is fixed: modesetting/glamor (or replacement) | 13:03 |
| Wizzup | I don't think that makes sense atm | 13:03 |
| freemangordon | for missing rotation support: now I understand way better what omapdrm is doing, so I will fix dma_buf support there to allow rotation through TILER/VRFB for dma_buf BOs as well | 13:04 |
| freemangordon | Wizzup: not atm, for sure | 13:04 |
| Wizzup | check @ rotation | 13:05 |
| freemangordon | but, shall I spend more time trying to fix various bugs (like what uvos and you report)? | 13:05 |
| Wizzup | freemangordon: I mean if we have ddx working well and we think we want to go to for modesetting eventually we can do it of course, I just wouldn't suggest we abandon what we have now since it works well | 13:05 |
| Wizzup | I think yes | 13:05 |
| Wizzup | because we want to push these ddx to stable | 13:05 |
| Wizzup | and the droid4 has twice in the last few days hit this bug where X dies and the screen doesn't want to go on | 13:05 |
| Wizzup | because of this resource exhaustion thing | 13:05 |
| freemangordon | I understand, but I am not sure CMA/TILER bugs are easy to fix, even if possible | 13:06 |
| Wizzup | mm | 13:06 |
| freemangordon | IIUC, on d4 the issue is that TILER/DMM space gets fragmented with time | 13:06 |
| freemangordon | and I see no way to fix that | 13:06 |
| freemangordon | the same happens with CMA on n900 | 13:06 |
| freemangordon | do you have any idea how to fix such an issue? | 13:07 |
| freemangordon | I am not going to implement DMM compaction algo in omapdrm | 13:07 |
| Wizzup | freemangordon: what about reusing buffers and not allocating on the fly? | 13:09 |
| uvos | cant we fix tiler fragmentation by just allocating once | 13:10 |
| uvos | ? | 13:10 |
| uvos | d4 isent hurting for ram so mutch | 13:10 |
| freemangordon | what about rotation? | 13:10 |
| uvos | or tiler space afaik | 13:10 |
| uvos | freemangordon: just allocate a block thats 960x960? | 13:10 |
| freemangordon | HDMI? | 13:10 |
| uvos | hdmi dosent rotate | 13:11 |
| uvos | generaly | 13:11 |
| freemangordon | it does | 13:11 |
| uvos | so allocate a new one then | 13:11 |
| freemangordon | exactly | 13:11 |
| uvos | why would hdmi rotate | 13:11 |
| uvos | ie why would you want to do that often | 13:11 |
| freemangordon | forget about hdmi | 13:11 |
| freemangordon | I am not sure you can allocate 960x960 | 13:11 |
| uvos | why not | 13:11 |
| uvos | its smaller than 1080p and that works ok allready | 13:12 |
| freemangordon | because OMAP DDX passes different flags depending on whether it is rotated or not | 13:12 |
| freemangordon | actually different functions are called | 13:12 |
| freemangordon | omap_bo_new vs omap_bo_new_tiled | 13:12 |
| uvos | 2 questions | 13:13 |
| freemangordon | not to say omap ddx does not support dri3 | 13:13 |
| uvos | thats not so important for now | 13:13 |
| freemangordon | sure | 13:14 |
| uvos | 1. how dose tiler space get fragmented anyhow, we are the only ones allocating something there, so if we deallocate all buffers and then allocate new ones how dose fragmentation occure | 13:14 |
| uvos | 2. why did ddk1.9 that did use the tiler (look at the allocations) work without problems | 13:14 |
| freemangordon | 1: actually DMM is used for *every* buffer on d4 | 13:14 |
| freemangordon | so, we allocate from TILER for scanout rotated buffers and from DMM for all other buffers | 13:15 |
| uvos | ok | 13:16 |
| freemangordon | so, most-probably the allocation taht fails is DMM allocation | 13:16 |
| uvos | but tiler space seams safe | 13:16 |
| uvos | just ddm then | 13:16 |
| uvos | *mm | 13:16 |
| freemangordon | yeah | 13:16 |
| uvos | and ddk1.9 did blits everywhere right | 13:16 |
| freemangordon | wait | 13:16 |
| freemangordon | DDK is TILER basically, like, they share the same address space | 13:17 |
| freemangordon | you just set different properties | 13:17 |
| freemangordon | so, fragmented DMM *is* fragmented TILER | 13:17 |
| freemangordon | there is DMM/TILER map in /sys/kernel/$somewhere, so Wizzup may want to look at it after some usage of his device | 13:18 |
| uvos | yeah i know | 13:18 |
| uvos | looks like irc.txt lost alot of stuff | 13:18 |
| uvos | i was just greping for that | 13:18 |
| freemangordon | uvos: not sure why ddk 1.9 works | 13:19 |
| freemangordon | it is using 3buffer as well | 13:19 |
| freemangordon | maybe I introduced some bug in OMAP ddx with regards to 3buffering | 13:20 |
| freemangordon | Wizzup: could you disable TripleBuffer in xorg.conf and check if is still crashes | 13:20 |
| uvos | watch -n0.3 cat /sys/kernel/debug/dri/1/tiler_map | 13:21 |
| uvos | btw | 13:21 |
| freemangordon | so, about modesetting: | 13:23 |
| freemangordon | 1. dri3 for free. this will fix also the Xorg crashes we are seeing now as buffers are allocated only once in Xorg. A client unable to allocate a buffer will not bring the whole OS down | 13:23 |
| uvos | freemangordon: so tiler map shows more allocations now than it did in ddk1.9 | 13:25 |
| uvos | 1 vs 3 buffers looks like | 13:25 |
| uvos | not sure if relevant | 13:25 |
| freemangordon | sure it is | 13:25 |
| freemangordon | wait, this is in landscape? | 13:25 |
| uvos | yeah | 13:26 |
| uvos | the number of buffers dosent look like it changes in ddk1.9 | 13:26 |
| uvos | it just changes reprisentation in the map (not sure how to read exactly) | 13:26 |
| freemangordon | could you disable 3buffer and see if it makes any difference? | 13:27 |
| uvos | whats the option string? | 13:28 |
| uvos | 3Buffer? | 13:28 |
| uvos | TrippleBuffer? | 13:28 |
| freemangordon | TripleBuffer false | 13:28 |
| freemangordon | only one 'p' | 13:28 |
| freemangordon | https://github.com/maemo-leste/xf86-video-omap/blob/master/src/omap_driver.c#L119 | 13:29 |
| freemangordon | oh, maybe you are right and 1.9 does blit even in fullscreen | 13:29 |
| freemangordon | or, it is simply that I broke omap DDX at some point so it frees buffers more often that it has to | 13:30 |
| freemangordon | *than | 13:30 |
| Wizzup | freemangordon: on d4? sure | 13:31 |
| freemangordon | yes, on d4 | 13:31 |
| uvos | freemangordon: no change | 13:31 |
| uvos | @3buffer | 13:31 |
| freemangordon | hmm | 13:31 |
| Wizzup | you can reproduce it that quickly? | 13:31 |
| freemangordon | Wizzup: wa are looking at the tiler map | 13:31 |
| Wizzup | ok | 13:31 |
| freemangordon | *we | 13:31 |
| freemangordon | uvos: maybe try without pvr_exa | 13:32 |
| freemangordon | though it should not make any difference | 13:32 |
| uvos | freemangordon: do i have to remove the so | 13:32 |
| uvos | or is there an option | 13:33 |
| freemangordon | yep | 13:33 |
| uvos | ok | 13:33 |
| freemangordon | move .so somewhere | 13:33 |
| freemangordon | uvos: BTW, what is omap ddx version? | 13:33 |
| uvos | Version: 0.5.4+2m7.1 | 13:36 |
| freemangordon | please upgrade kernel and ddx | 13:36 |
| uvos | kernel is 5.16 based | 13:36 |
| uvos | i assume you mean leste kernel? | 13:36 |
| freemangordon | yes, leste kernel | 13:37 |
| freemangordon | but, if you use custom one, make sure to have fence patch in it | 13:37 |
| uvos | not yet no | 13:37 |
| freemangordon | and the upgrade ddx to 0.5.4 | 13:37 |
| uvos | btw i havent had any problems with x crashing at all yet | 13:37 |
| uvos | except the vt switch thing | 13:37 |
| freemangordon | you want to do that, trust me :) | 13:37 |
| uvos | ok ok | 13:38 |
| freemangordon | maybe Wizzup has different use pattern or different applications | 13:38 |
| freemangordon | I never had Xorg crashing too | 13:38 |
| uvos | xserver-xorg-video-omap armhf 0.5.5+2m7 | 13:38 |
| freemangordon | yes, but this needs fence patch in kernel | 13:38 |
| uvos | right yeah | 13:38 |
| uvos | i dist-upgraded | 13:39 |
| uvos | should be there | 13:39 |
| freemangordon | it is in leste kernal, yeah | 13:39 |
| Wizzup | freemangordon: well I use the droid daily and probably wake it up ~50 times a day with the slider at leaast | 13:40 |
| freemangordon | uvos: it is possible that ddk1.9 kernel omapdrm does not allocate everything through DMM | 13:40 |
| freemangordon | Wizzup: yeah, obviously you are using the device :) | 13:41 |
| uvos | well same here | 13:41 |
| uvos | i use it as primary phone | 13:41 |
| uvos | so not sure | 13:41 |
| uvos | anyhow | 13:41 |
| freemangordon | well, no idea then | 13:41 |
| freemangordon | (crashes) | 13:42 |
| freemangordon | uvos: I was not expecting difference in allocations | 13:42 |
| uvos | there are none | 13:42 |
| freemangordon | between 5.4 and 5.5 that is | 13:42 |
| freemangordon | but now you have kernel that WL works too on | 13:42 |
| uvos | neat | 13:43 |
| uvos | but the wl phone is still on 5.13 :P | 13:43 |
| freemangordon | basically, dma_buf implicit fencing works | 13:43 |
| uvos | ok | 13:43 |
| freemangordon | in omapdrm that is | 13:43 |
| freemangordon | Wizzup: is there any pattern in regards to Xorg crashes? | 13:44 |
| freemangordon | uvos: wha tiy can do is | 13:44 |
| freemangordon | *what you can do | 13:44 |
| uvos | so what are we expecting to cause a crash here | 13:45 |
| freemangordon | is enable debug logs in xorg and compare dri2 parts between 1.9/1.17 | 13:45 |
| freemangordon | uvos: fragmented DMM/TILER space | 13:45 |
| uvos | sure | 13:45 |
| uvos | would a script that rotates at 1hz help? | 13:45 |
| freemangordon | I don;t hink so | 13:46 |
| uvos | ie can we cause fragmentation here on purpose | 13:46 |
| freemangordon | it will not fragment it | 13:46 |
| freemangordon | but yeah, you can try | 13:46 |
| uvos | ok | 13:46 |
| uvos | @debug logs | 13:46 |
| freemangordon | uvos: make sure to re-enable 3buffer first | 13:47 |
| freemangordon | I tried to compare once, but was not able to draw any sane conclusion | 13:47 |
| freemangordon | but I was after 6ms delay (that appeared to be cause by tmlind's patch) back then, so no surprise | 13:48 |
| freemangordon | uvos: the poin is to understand how often 1.17 ddx creates/destroys buffers compared to 1.9 | 13:48 |
| uvos | btw you can make xorg crash eventually be optinging ever more windows | 13:51 |
| uvos | this is not suprising i gues | 13:51 |
| freemangordon | on d4? | 13:51 |
| uvos | yeah | 13:51 |
| freemangordon | we run out of DMM space I guess | 13:51 |
| uvos | its alot of windows tho | 13:51 |
| freemangordon | could you have a look at tiler map just before the crash? | 13:52 |
| uvos | sure | 13:52 |
| freemangordon | I guess everything is marked as used there | 13:52 |
| uvos | but opening windows doent change it at all | 13:52 |
| freemangordon | how's that | 13:52 |
| uvos | i dont think it did | 13:52 |
| uvos | but sec | 13:52 |
| freemangordon | it should | 13:52 |
| uvos | it certenly dident on ddk1.9 | 13:52 |
| uvos | (device is rebooting) | 13:52 |
| freemangordon | ok, that's another story | 13:52 |
| freemangordon | (ddk 1.9) | 13:53 |
| uvos | yeah no | 13:54 |
| freemangordon | hmm? | 13:54 |
| uvos | opening windows dose squat to tiler_map | 13:54 |
| freemangordon | squat like? | 13:55 |
| freemangordon | rephrase please | 13:55 |
| uvos | ah non | 13:55 |
| uvos | nvm | 13:55 |
| uvos | its filling up | 13:55 |
| uvos | just from the bottom of the addr range | 13:55 |
| freemangordon | on 1.17 that is, right? | 13:55 |
| uvos | yes | 13:55 |
| freemangordon | ok | 13:55 |
| uvos | ah yeah | 13:55 |
| uvos | ok | 13:55 |
| uvos | i see what happens | 13:55 |
| uvos | so if you have many windows open | 13:55 |
| uvos | not that many even | 13:56 |
| uvos | and rotate | 13:56 |
| uvos | it ends up fragmented | 13:56 |
| freemangordon | yep | 13:56 |
| uvos | and then crashes if you open just a few more | 13:56 |
| uvos | soo why do non fullscreen windows need tiler space? | 13:56 |
| uvos | they get blitted anyhow | 13:56 |
| freemangordon | I have absolutely no idea why DMM is used for non-scanout buffers | 13:57 |
| uvos | ok | 13:57 |
| uvos | this is the difference to ddk 1.9 | 13:57 |
| uvos | it has the 1 buffer in there | 13:57 |
| freemangordon | this is something to do with Tomy using some weird IPs that require linear buffers | 13:57 |
| uvos | and no windows | 13:57 |
| uvos | ok | 13:57 |
| freemangordon | do you have ddk 1.9 buffer around? | 13:57 |
| freemangordon | s/buffer/kernel | 13:58 |
| uvos | no | 13:58 |
| uvos | or what do you mean | 13:58 |
| freemangordon | is it on github? | 13:58 |
| Wizzup | stable image could work | 13:58 |
| uvos | i have an sdcard with old leste | 13:58 |
| freemangordon | the source code | 13:58 |
| uvos | oh sure | 13:58 |
| freemangordon | uvos: wait, where do you test ddk 1.9? | 13:58 |
| freemangordon | on 5.15? | 13:58 |
| uvos | no | 13:58 |
| freemangordon | ah, ok :) | 13:58 |
| uvos | it never worked on 5.15 | 13:59 |
| uvos | 5.11 | 13:59 |
| uvos | just the old leste kernel | 13:59 |
| freemangordon | Wizzup: I wanted to check how omapdrm allocates buffers | 13:59 |
| uvos | https://github.com/maemo-leste/droid4-linux | 13:59 |
| uvos | 5.11 branch | 13:59 |
| freemangordon | maemo-5.11? | 13:59 |
| uvos | unfortionatly back then | 14:00 |
| freemangordon | btw, dows it use omapdrm? | 14:00 |
| freemangordon | or omapfb? | 14:00 |
| uvos | you had to also apply the patches in debian dir | 14:00 |
| uvos | but yeah almost | 14:00 |
| uvos | drm | 14:00 |
| freemangordon | ok | 14:00 |
| freemangordon | uvos: definitely omapdrm in 5.11 differs in the way it allocates buffers | 14:05 |
| freemangordon | uvos: oh, I think what happens | 14:10 |
| freemangordon | please remove EXA | 14:10 |
| freemangordon | and retry | 14:10 |
| freemangordon | with EXA enabled PVR imports buffer, which leads to them being pinned, thus DMM mapped | 14:11 |
| uvos | [ 31.782] (WW) Warning, couldn't open module omap_pvr | 14:22 |
| uvos | still allocates windows on tiler | 14:22 |
| freemangordon | weird | 14:22 |
| uvos | also alot of corruption | 14:22 |
| freemangordon | latest kernel? | 14:22 |
| uvos | yeah | 14:22 |
| uvos | no | 14:23 |
| uvos | i booted the wrong kernel by accident | 14:23 |
| freemangordon | Linux devuan-droid4 5.15.2 #1 SMP PREEMPT Thu Jan 6 12:29:58 UTC 2022 | 14:23 |
| freemangordon | :) | 14:23 |
| freemangordon | ok | 14:23 |
| freemangordon | uvos: when you have a chance, could you pastebin tiler_map on ddk 1.9 in landscape with xterm opened? | 14:25 |
| freemangordon | TBH I am almost sure omapdrm allocates differently in 5.15 vs 5.11 | 14:25 |
| uvos | ok | 14:26 |
| freemangordon | yeah, that;s it | 14:28 |
| uvos | take it up with tomi then why they broke it i gues :P | 14:29 |
| freemangordon | in 5.11, omap_gem_pin has one more parameter (remap), https://github.com/maemo-leste/droid4-linux/blob/maemo-5.11/drivers/gpu/drm/omapdrm/omap_gem.c#L837 | 14:29 |
| freemangordon | this is missing in 5.15 | 14:29 |
| freemangordon | so, omap_gem_pin *always* maps through tiler or DMM | 14:30 |
| freemangordon | have to attend work MTG, bbl | 14:30 |
| freemangordon | uvos: I'd rather fix dma_buf and migrate omap ddx to use it | 14:32 |
| freemangordon | uvos: BTW, you can take it to Tomy as well :p | 14:39 |
| uvos | http://uvos.xyz/maserati/tiler | 15:12 |
| uvos | freemangordon: this is with 10 xterms | 15:12 |
| uvos | on all | 15:13 |
| uvos | so clearly the windows, besides hildon-desktop itself (makes sense) are not tiler mapped on ddk1.9 | 15:13 |
| uvos | on rotation ddk1.9 needs only one extra tiler buffer while ddk1.17 looks like it uses 2 | 15:13 |
| uvos | but thats not realy a problem | 15:14 |
| uvos | that part also dosent fragement | 15:14 |
| uvos | closing the windows cleans it up ofc | 15:16 |
| uvos | so i gues | 15:16 |
| uvos | Wizzup has longstanding windows open he never closes | 15:16 |
| uvos | thats why his xorg crashes | 15:16 |
| uvos | i habitually close all or at least most windows and lock the device | 15:16 |
| uvos | so it makes sense i never encouterd this | 15:16 |
| Wizzup | it's really just one or two osso-xterms :p | 15:17 |
| uvos | how long is your uptime | 15:20 |
| uvos | i took the 10 xterms for a 50 rotation spin | 15:20 |
| uvos | and its not close to full yet | 15:20 |
| uvos | anyhow yeah this is liekly the prblem here | 15:20 |
| freemangordon | uvos: this is with PVR EXA? | 15:21 |
| uvos | freemangordon: yes | 15:21 |
| freemangordon | ok | 15:21 |
| uvos | freemangordon: and makes no difference | 15:21 |
| freemangordon | yeah | 15:21 |
| uvos | ofc its without pvr exa on ddk1.9 | 15:21 |
| uvos | (dosent exist there) | 15:21 |
| freemangordon | yeah | 15:22 |
| freemangordon | Wizzup: you have production PP, right? | 15:45 |
| freemangordon | not devel kit | 15:45 |
| freemangordon | Wizzup: USB networking does not seem to work either | 15:48 |
| freemangordon | device generates lots of heat too | 15:49 |
| freemangordon | maybe this happens only if you boot with usb cable connected | 15:50 |
| Wizzup | freemangordon: I ahve devel kit only | 15:52 |
| freemangordon | yeah, same here | 15:52 |
| Wizzup | freemangordon: ok let me take today to merge rafael2k's changes | 15:52 |
| Wizzup | parazyd: do you have a production pinephone? | 15:53 |
| freemangordon | Wizzup: I see issues on devel kit | 15:53 |
| freemangordon | with maemo-leste-1.0-arm64-pinephone-20220102.img.xz | 15:53 |
| freemangordon | wifi does not show any connection, device heats like crazy, display blinks twice a second. with old kernel it works fine | 15:54 |
| freemangordon | USB networking does not work either (with latest image) | 15:54 |
| Wizzup | freemangordon: is this -devel or stable | 15:55 |
| Wizzup | freemangordon: I don't see any of these problems btw | 15:55 |
| Wizzup | freemangordon: this image? https://maedevu.maemo.org/images-devel/pinephone/20220102/ | 15:56 |
| freemangordon | I just followed the link you pasted on #lima | 15:56 |
| freemangordon | do you boot with usb cable attached? | 15:56 |
| Wizzup | no | 15:56 |
| freemangordon | try with | 15:56 |
| Wizzup | I boot with power supply | 15:56 |
| freemangordon | what do you mean? | 15:56 |
| Wizzup | freemangordon: I think we should first take rafael2k's work on the kernel | 15:56 |
| Wizzup | freemangordon: lab psu | 15:56 |
| Wizzup | I soldered to where the battery goes | 15:57 |
| freemangordon | ah :) | 15:57 |
| freemangordon | ok, I boot with a battery | 15:57 |
| freemangordon | and USB cable attached | 15:57 |
| freemangordon | now I wait fo battery to charge a bit | 15:57 |
| freemangordon | Wizzup: yeah, please do it (kernel changes) | 15:57 |
| freemangordon | same happens with USB cable disconnected, besides this time wifi seems to work | 16:10 |
| Wizzup | can you elaborate on 'wifi does not work' | 16:12 |
| Wizzup | does it not see the interface? | 16:12 |
| freemangordon | how do I know without being able to write commnds? :) | 16:12 |
| freemangordon | it does not work like "INternet connections dialog shows 'no connection avalable'" | 16:13 |
| freemangordon | when booted with cable detached, there are connection, so wifi works then | 16:14 |
| freemangordon | *connections | 16:14 |
| freemangordon | however I cannot write the password | 16:14 |
| Wizzup | damn that's quite broken | 16:14 |
| freemangordon | mhm | 16:14 |
| Wizzup | I am not sure if I have braveheart or not anymore, maybe I swapped | 16:14 |
| freemangordon | and this is the kernel | 16:14 |
| freemangordon | braveheart? | 16:14 |
| freemangordon | is this some HW release? | 16:15 |
| Wizzup | braveheart I think is the pre release thing we have, no? | 16:15 |
| freemangordon | could be, that's why I ask, I am not in line with PP releases | 16:15 |
| freemangordon | lemme check what is written on the box | 16:16 |
| freemangordon | well, nothing useful | 16:16 |
| Wizzup | if you have an official box I think it's not some pre production one | 16:17 |
| freemangordon | yes, it is official box | 16:17 |
| Wizzup | https://wiki.pine64.org/wiki/PinePhone_v1.1_-_Braveheart | 16:17 |
| Wizzup | also https://wiki.pine64.org/wiki/PinePhone#Hardware_revisions | 16:17 |
| Wizzup | so v1.1 is production I think | 16:17 |
| freemangordon | do you know if there is a way to tell which revision I have? | 16:20 |
| Wizzup | I think there might be something in u-boot, but I do not recall on top of my head | 16:20 |
| Wizzup | maybe we should do rafael's stuff first and then try again | 16:20 |
| Wizzup | it might just solve most problems | 16:20 |
| freemangordon | ok | 16:21 |
| freemangordon | Wizzup: mine should be the same as yours delivered after anakin | 16:26 |
| freemangordon | so, if you got braveheart then mine is the same | 16:26 |
| Wizzup | freemangordon: I swapped with parazyd at some point I think | 16:30 |
| parazyd | I burned one and the one I have now is the first release | 16:31 |
| parazyd | That's probably Braveheart | 16:31 |
| Wizzup | ok, so maybe I gave you the one I bought and I have my prerelease one here | 16:31 |
| Wizzup | rafael2k: around? | 16:50 |
| mighty17[m] | is there some build insruction for https://github.com/maemo-leste/xf86-video-omap? or just autoconf, automake? | 17:37 |
| uvos | its just regular autotools | 17:42 |
| uvos | but yes autotools are a pain | 17:42 |
| Wizzup | ./configure.sh ? :p | 17:43 |
| freemangordon | not really :) | 17:44 |
| freemangordon | (pain) | 17:44 |
| Wizzup | I find autotools nice yeah | 17:44 |
| mighty17[m] | Wizzup: doesnt work | 17:47 |
| mighty17[m] | `./configure: line 20131: syntax error: unexpected word (expecting ")")` | 17:48 |
| uvos | regenerate configure | 17:49 |
| freemangordon | mighty17[m]: autoreconf -v -f -i | 17:49 |
| freemangordon | ant then ./configure | 17:49 |
| uvos | the absuridty of autotools layers :P | 17:49 |
| freemangordon | yeah, yeah | 17:49 |
| mighty17[m] | oh alrighty | 17:49 |
| mighty17[m] | well autotools is a pain | 17:49 |
| freemangordon | compared to meson/ninja its a breeze | 17:51 |
| freemangordon | Wizzup: did you do some HW modifications to PP, besides connecting PSU instead of battery? | 17:51 |
| Wizzup | freemangordon: no | 17:54 |
| Wizzup | fwiw I mailed rafael about his work | 17:54 |
| Wizzup | he did some things I don't understand wrt kernel package names | 17:55 |
| freemangordon | ok | 17:55 |
| sicelo | btw, the wlan firmware thing on droid 4 runs automatically only on first boot? or does it re-run on all boots? | 19:33 |
| uvos | sicelo: just once | 19:33 |
| uvos | parazyd: you here? | 19:33 |
| sicelo | asking because - perhaps we need a similar approach with expanding Leste to the size of the SD card | 19:34 |
| uvos | hmm | 19:34 |
| uvos | im not sure we want to do that automaticly | 19:34 |
| uvos | we could maybe ask the user on first boot | 19:34 |
| uvos | i for one often flash a sdcard and then dd it over to emmc | 19:34 |
| uvos | if you just expand the partition youll break that | 19:35 |
| uvos | so i ported charge-mode over to drm | 19:36 |
| parazyd | uvos: What's up? | 19:36 |
| uvos | parazyd: i need to you change sdl2 | 19:36 |
| parazyd | Can I have more context please? | 19:36 |
| uvos | sure sec | 19:36 |
| uvos | parazyd: so charge-mode was using the directfb sdl backend, beacuse of bugs in ddk1.9 | 19:38 |
| uvos | parazyd: next version (ready to be taged out) of charge-mode uses drm now | 19:38 |
| uvos | parazyd: but we need to enable it in sdl2 | 19:38 |
| uvos | (and disable directfb) | 19:38 |
| uvos | https://github.com/maemo-leste-upstream-forks/libsdl2/blob/master/debian/rules | 19:38 |
| parazyd | So what are the new flags we should use? | 19:39 |
| uvos | so wee need --disable-video-directfb and --enable-video-kmsdrm --disable-kmsdrm-shared | 19:39 |
| uvos | i would also disable opengl | 19:39 |
| uvos | since that forces some games to use gles | 19:39 |
| uvos | --disable-video-opengl | 19:39 |
| uvos | parazyd: we can also scrub directfbrc.leste for all devices in leste-config | 19:40 |
| uvos | but having it dosent break anything | 19:41 |
| uvos | so we can do so later | 19:41 |
| uvos | i can pr if you like | 19:41 |
| parazyd | Sure | 19:41 |
| parazyd | I pushed libsdl change | 19:42 |
| parazyd | Should I just build it for devel? | 19:42 |
| uvos | yeah | 19:42 |
| uvos | ill just update charge-mode for devel first too | 19:42 |
| parazyd | *nod* | 19:42 |
| uvos | parazyd: please make a mental/phyiscal note to promote these together | 19:42 |
| parazyd | noted :) | 19:43 |
| freemangordon | Wizzup: don't know what it is, but have a look https://xff.cz/kernels/5.15/README | 19:51 |
| Wizzup | freemangordon: yes but I think we want the one rafael linked, the mobian 5.15 one | 19:55 |
| Wizzup | he said: | 19:55 |
| Wizzup | 22:27 < rafael2k> so this works: https://github.com/rafael2k/pine64-kernel/tree/maemo/beowulf-devel with this kernel https://github.com/rafael2k/sunxi64-linux/tree/mobian-5.15 | 19:55 |
| Wizzup | but his maemo/beowulf-devel tree there changes the pkg name | 19:56 |
| freemangordon | Wizzup: ok, if you say so | 19:57 |
| Wizzup | freemangordon: see https://github.com/rafael2k/pine64-kernel/blob/maemo/beowulf-devel/debian/patches/series | 19:58 |
| freemangordon | omg | 19:58 |
| freemangordon | why are those not in mainline linux? | 19:58 |
| Wizzup | but he added 5.15 here https://github.com/rafael2k/pine64-kernel/blob/maemo/beowulf-devel/debian/control#L20 | 19:58 |
| Wizzup | so I need to check what that is about | 19:58 |
| Wizzup | we want it to be 'our' name | 19:59 |
| freemangordon | yeah | 19:59 |
| Wizzup | have guests atm, so not super around atm | 19:59 |
| Wizzup | https://github.com/rafael2k/pine64-kernel/commit/cf1c86ff04eaa7850087d561ad7a51cb97731a4e | 19:59 |
| freemangordon | ok, lets continue tomorrow | 19:59 |
| sicelo | "why are those not in mainline linux?" - afaik they will be. it's just there have been a lot of PP kernel forks for a while, leading to massive fragmentation. now people are finally working on it together, with aim to have one cross-distro kernel. should be easier to mainline | 20:04 |
| sicelo | what was that device that had smartphone form factor, but didn't have a modem? Leste was also mentioned in its pages. I forgot the name now | 20:23 |
| Wizzup | the finnish thing? | 20:39 |
| Wizzup | necunos? | 20:39 |
| sicelo | yeah. thanks! i wonder what happened to them | 20:39 |
| uvos | Wizzup: btw so can we enable charge-mode by default for some devices now | 23:42 |
| uvos | Wizzup: also since the n900 problem is fixed i think we should add sphone to meta on devel | 23:42 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!