| Wizzup | rafael2k: what issues do you see in firefox | 00:06 |
|---|---|---|
| uvos | dose clutter 1.0 still perform terribly | 00:09 |
| uvos | or did it just hit the problem in the old ddk's where they ended up copying the frame on the cpu | 00:09 |
| uvos | like gears | 00:09 |
| Wizzup | uvos: most likely still performs terrible | 00:10 |
| Wizzup | uvos: so they asked for apitrace | 00:10 |
| Wizzup | and the virtual keyboard problems where stuff is not visible *disappears* under apitrace | 00:10 |
| Wizzup | uvos: rafael2k: hey, did we actually try glamor with llvmpipe? | 00:13 |
| Wizzup | or did we only try to disable glamor alltogether? | 00:13 |
| uvos | glamor was disabled | 00:14 |
| uvos | but its not glamors fault since it works on glamor | 00:14 |
| uvos | whenever hildon is not rendering | 00:14 |
| uvos | glamor dose _more_work | 00:14 |
| Wizzup | firefox also has no glitches with apitrace | 00:14 |
| uvos | ie when you disable composistion | 00:14 |
| uvos | then glamor has more work to do | 00:14 |
| Wizzup | I guess this counts as heisenbug then | 00:17 |
| Wizzup | freemangordon: wouldn't mind to pick your brain on this tomorrow | 00:24 |
| _inky | as another method to test things i can suggest trying to run frozen-bubble from debian repos. it'll require bt keyboard though. | 00:51 |
| Wizzup | what do you see? | 00:53 |
| rafael2k | Wizzup: crazy re-drawings in firefox... it looks like its dimensions keep changing, even not scrolling the page the ui elements are drawn in wrong places, then in correct places, then in wrong again... | 07:37 |
| rafael2k | Wizzup: dont really know how to try glamor with llvmpipe... | 07:39 |
| Wizzup | rafael2k: ok, yes | 11:29 |
| Wizzup | rafael2k: I am also not seeing that anymore with apitrace | 11:29 |
| uvos | glamor refuses to enable on llvmpipe, you have to comment out that check in the source | 12:47 |
| uvos | not sure why you would want to in this case tho | 12:47 |
| uvos | the problem seams not to be glamor | 12:47 |
| Wizzup | uvos: ok, I just want to be able to communicate that to them somehow, they didn't ask if it was glamor | 12:51 |
| Wizzup | uvos: but if the major problem goes away in apitrace ... | 12:51 |
| uvos | apitrace slows things down so i gues that helps somehow | 12:54 |
| uvos | :( | 12:54 |
| Wizzup | yes, to which the guy who responded to me said 'we have never seen timing problems so that seems unlikely to me' | 12:54 |
| Wizzup | I guess I can make a video for them | 12:55 |
| uvos | Wizzup: if you want to try llvm on glamor anyhow: https://gitlab.freedesktop.org/xorg/xserver/-/blob/master/glamor/glamor_egl.c#L1056 | 12:56 |
| uvos | just set GALLIUM_DRIVER to llvmpipe for xorg | 12:57 |
| uvos | then you have llvm for glamor and lima for everything else | 12:57 |
| uvos | but if api trace helps | 12:57 |
| uvos | that might help to just because glamor will block forever copying the window pixmap to cpu | 12:57 |
| uvos | so im not sure how usefull it is | 12:58 |
| uvos | runing just hildon/clutter toys on llvm seams more likely to provide information | 12:58 |
| Wizzup | I am not sure what you are suggesting exactly | 13:00 |
| uvos | run hildon (or better some simple application that shows the problem on its own) on llvmpipe while glamor is lima acceleratated | 13:00 |
| uvos | result: glamor exonerated | 13:00 |
| uvos | (problem dissapears) | 13:01 |
| Wizzup | ok | 13:01 |
| uvos | who is they btw | 13:01 |
| uvos | do we have a open bug report? | 13:01 |
| Wizzup | no, I went to #lima on OFTC (you need to register and verify to talk) and asked how to best submit a bug report | 13:02 |
| Wizzup | so running h-d with LIBGL_ALWAYS_SOFTWARE=1 GALLIUM_DRIVER=llvmpipe makes it slow (as expected) and the issues seem to disappear as well | 13:05 |
| uvos | yeah as expected | 13:05 |
| Wizzup | did you also see the gl errors I reported btw? | 13:06 |
| uvos | i did | 13:06 |
| uvos | dont really know what to make of it tho | 13:06 |
| Wizzup | they seem to be related to textures | 13:06 |
| uvos | yes | 13:06 |
| uvos | it makes sense (with the issues you see) | 13:06 |
| uvos | it/that | 13:06 |
| Wizzup | I think I found a way to reproduce the issue in apitrace | 13:07 |
| uvos | ok | 13:08 |
| uvos | anoter reason why checking if you can find some simpler clutter applicaiton that shows this is good is because | 13:09 |
| uvos | maybe this is somehting clutter fixed a long time ago | 13:10 |
| Wizzup | so just 'selecting' stuff in osso-xterm reproduces it | 13:10 |
| uvos | Wizzup: ok | 13:10 |
| Wizzup | want to see the traces? | 13:10 |
| uvos | cant hurt, but really i dont know mutch about gl. | 13:10 |
| Wizzup | just to confirm they seem sensible to you | 13:11 |
| Wizzup | uvos: https://wizzup.org/dirlist/maemo-leste/lima/ | 13:11 |
| Wizzup | hm it looks weird on llvmpipe too doesn't it... in the replay at least? | 13:12 |
| Wizzup | I wish apitrace would be able to introduce a delay per frame | 13:13 |
| Wizzup | uvos: so frame per frame the trace of llvmpipe looks good to me | 13:16 |
| Wizzup | but the replay is a mess | 13:16 |
| Wizzup | actually it's also a mess if I don't replay with LIBGL_ALWAYS_SOFTWARE on my *amd* gpu | 13:17 |
| uvos | so dose dump-images show the issue on lima | 13:17 |
| uvos | on that trace? | 13:17 |
| Wizzup | well even my amdgpu driver shows it apparently :) | 13:17 |
| Wizzup | uvos: can you try to use apitrace and look at frame 47 and show me the contents? | 13:17 |
| Wizzup | of the llvmpipe one | 13:18 |
| Wizzup | qapitrace* | 13:18 |
| Wizzup | I'll do ump images | 13:18 |
| rafael2k | what should do / patch to get battery level indication? | 13:18 |
| Wizzup | rafael2k: I linked you the patch | 13:18 |
| Wizzup | rafael2k: https://github.com/maemo-leste/pine64-kernel/commit/c62a8aeab344523190c7f539de60d94ba6c9cc5f | 13:18 |
| Wizzup | something like thisd | 13:18 |
| rafael2k | tks! | 13:18 |
| Wizzup | but it's a hack | 13:18 |
| rafael2k | what isnt... | 13:18 |
| rafael2k | ; ) | 13:18 |
| Wizzup | uvos: ok let me get you dump-images commands | 13:19 |
| uvos | oh yeah | 13:19 |
| uvos | it looks wrong | 13:19 |
| uvos | even on amdgpu | 13:19 |
| Wizzup | now try LIBGL_ALWAYS_SOFTWARE=1 | 13:19 |
| Wizzup | in front of qapitrace | 13:19 |
| uvos | right thats fine | 13:19 |
| uvos | yeah so there seams to be a problem in clutter | 13:20 |
| Wizzup | or in various mesa drivers | 13:20 |
| uvos | the gallium statetracker maybe | 13:21 |
| uvos | since thats shared | 13:21 |
| uvos | but seams pretty unlikely | 13:21 |
| uvos | amdgpu gets into extreamly well tested teritorry | 13:21 |
| rafael2k | which kernel should I start from? https://github.com/maemo-leste/pine64-kernel/ ? | 13:21 |
| rafael2k | (I mean, which branch ) | 13:22 |
| Wizzup | uvos: I mean supposedly this is good news | 13:23 |
| uvos | so is hildon-desktop clutter 1.0 something thats realtively easy to test | 13:23 |
| uvos | ie dose it compile and work mostly? | 13:23 |
| Wizzup | not super easy | 13:23 |
| uvos | ok hmm | 13:24 |
| Wizzup | uvos: https://wizzup.org/dirlist/maemo-leste/lima/dump-images/ | 13:29 |
| rafael2k | from which brach the actual kernel in the repo is coming from (for pp)? | 13:29 |
| Wizzup | rafael2k: sorry I saw the message but we're debugging the lima stuff and it's taking up my attention | 13:29 |
| Wizzup | rafael2k: the best thing always to do for maemo-leste repos is open the maemo/beowulf or maemo/beowulf-devel branch | 13:29 |
| Wizzup | look at the debian/changelog file and see what tag it references | 13:30 |
| Wizzup | that tag should lead you right to the branch | 13:30 |
| Wizzup | keep in mind that -devel and non-devel can have different versions | 13:30 |
| uvos | kinda wierd that the lima trace has mesa complain about a bounch of errors | 13:31 |
| uvos | but renders ok | 13:31 |
| uvos | and llvm trace is opisit | 13:31 |
| Wizzup | hm? both amdgpu renders seem off, of either trace, no? | 13:32 |
| uvos | amdgpu/radionsi rendering the lima trace is fine here | 13:32 |
| uvos | dont see anything wrong | 13:32 |
| Wizzup | do you see cmd.txt in there? | 13:32 |
| Wizzup | care to run that and compare? | 13:32 |
| Wizzup | oh | 13:33 |
| Wizzup | I messed up the numbers there | 13:33 |
| Wizzup | fck | 13:33 |
| Wizzup | sec | 13:33 |
| rafael2k | Wizzup: go ahead - lima++ | 13:33 |
| rafael2k | ; )) | 13:33 |
| Wizzup | uvos: care to look at cmd.txt now and try? | 13:34 |
| Wizzup | uvos: I bet it will look wrong for you | 13:34 |
| uvos | BAD: apitrace dump-images maemo-summoner-hildon-desktop-llvmpipe.trace -o llvmpipe-trace-amdgpu-redraw --calls=3542 | 13:35 |
| uvos | FINE: LIBGL_ALWAYS_SOFTWARE=1 apitrace dump-images maemo-summoner-hildon-desktop-llvmpipe.trace -o llvmpipe-trace-llvmpipe-redraw --calls=3542 | 13:35 |
| uvos | FINE + MESA ERRORS: apitrace dump-images maemo-summoner-hildon-desktop-lima.trace -o lima-trace-amdgpu-redraw --calls=2357 | 13:35 |
| uvos | FINE + MESA ERRORS: LIBGL_ALWAYS_SOFTWARE=1 apitrace dump-images maemo-summoner-hildon-desktop-lima.trace -o lima-trace-llvmpipe-redraw --calls=2357 | 13:36 |
| Wizzup | what image do you get on the lima-trace-amdgpu-redraw | 13:36 |
| uvos | all frames of the lima look fine | 13:36 |
| uvos | not just that one | 13:36 |
| Wizzup | https://wizzup.org/dirlist/maemo-leste/lima/dump-images/lima-trace-amdgpu-redraw0000002357.png not this one then? | 13:36 |
| uvos | http://uvos.xuz/maserati/lima-trace-amdgpu-redraw0000002357.png | 13:37 |
| uvos | *xyz | 13:37 |
| Wizzup | does this still need an ip? | 13:38 |
| uvos | no | 13:38 |
| Wizzup | oh btw my images were weird because my vm resized the windows lmao | 13:38 |
| uvos | your browser put www on it | 13:38 |
| Wizzup | interesting @ your image | 13:38 |
| Wizzup | I get this: https://wizzup.org/dirlist/maemo-leste/lima/dump-images/lima-trace-amdgpu-redraw0000002357.png | 13:39 |
| uvos | wierd | 13:39 |
| Wizzup | maybe you have tearfree set or something :) | 13:39 |
| uvos | no | 13:39 |
| Wizzup | freemangordon: I think we have a clutter bug on our hands | 13:39 |
| Wizzup | uvos: so I think at this point it's probably safe to say this seems buggy with most mesa drivers except for llvmpipe and with powervr | 13:40 |
| uvos | well llvm makes sense | 13:40 |
| uvos | its extreamly forgiving with using wrong buffers etc since its dosen have hw caches and sutch | 13:41 |
| Wizzup | I can confirm I also see errors only with the lima trace | 13:41 |
| uvos | powervr is not really a mesa driver anyhow | 13:42 |
| uvos | anything that affects this is implemented in the blobs | 13:42 |
| uvos | so eh | 13:42 |
| Wizzup | right | 13:42 |
| Wizzup | my point was mostly that clearly it works on some drivers | 13:42 |
| uvos | right | 13:42 |
| Wizzup | uvos: I'll make a trace on my d4 | 13:46 |
| Wizzup | just to see if that replays ok in mesa | 13:47 |
| Wizzup | uvos: btw any idea how to make apitrace replay delay images | 13:47 |
| uvos | hmm | 13:47 |
| uvos | what are you tring to acive | 13:48 |
| uvos | a video in real time? | 13:48 |
| Wizzup | yeah, that would be nice... | 13:48 |
| uvos | just assemble the images with ffmpeg | 13:48 |
| Wizzup | I cannot see anything really with 'replay' | 13:48 |
| Wizzup | yeah ok | 13:48 |
| Wizzup | I just suspected that replay could do this somehow | 13:48 |
| Wizzup | lol apitrace segfaults with powervr drivers | 13:50 |
| uvos | heh | 13:51 |
| uvos | probubly pvrtrace | 13:51 |
| uvos | is what you need to use | 13:51 |
| uvos | but then you cant replay | 13:51 |
| Wizzup | Thread 1 "maemo-summoner" received signal SIGSEGV, Segmentation fault. | 13:51 |
| Wizzup | 0xb4512662 in ?? () from /usr/lib/arm-linux-gnueabihf/libGLESv2_PVR_MESA.so | 13:51 |
| Wizzup | so I think the code that errors/warns with invalid enum is in clutter-0.8 debian/patches/02-eglx-backend-tfp.patch | 13:53 |
| rafael2k | btw, the power patch is incomplete, this is why... https://github.com/maemo-leste/pine64-kernel/blob/maemo/beowulf-devel/debian/patches/0002-axp20x_battery-hardcode-technology-to-lion-for-now.patch | 13:53 |
| Wizzup | rafael2k: ah it was not rebased ok? | 13:53 |
| rafael2k | should be: https://github.com/maemo-leste/pine64-kernel/commit/c62a8aeab344523190c7f539de60d94ba6c9cc5f | 13:53 |
| Wizzup | parazyd: ayyyy ^ | 13:54 |
| rafael2k | Wizzup: patch is missing an important part... | 13:54 |
| Wizzup | rafael2k: yeah I think parazyd rebased it and missed that property | 13:54 |
| rafael2k | uhum | 13:54 |
| Wizzup | or I did, idk, it's been a while | 13:54 |
| rafael2k | anyway, telephony is missing also, but that is just config tweaking | 13:54 |
| rafael2k | also crypto... | 13:55 |
| Wizzup | rafael2k: yes, maybe summarise it an issue | 13:55 |
| Wizzup | I am waiting for parazyd to do it since I have too much on my hands already with n900 and droid4 kernel | 13:55 |
| uvos | http://uvos.xyz/maserati/lima-trace-amdgpu-redraw.mp4 | 13:55 |
| uvos | looks really fun :P | 13:55 |
| Wizzup | that's pretty accurate probably | 13:56 |
| Wizzup | although I am not sure if I saw the h-d background bleed througfh | 13:56 |
| uvos | its running at 1/2 realtime speed | 13:56 |
| uvos | so | 13:57 |
| uvos | pobubly harder to see in real time | 13:57 |
| Wizzup | I think this is beyond something I can just solve right now | 13:57 |
| Wizzup | (as in, I am going to take a break) | 13:57 |
| Wizzup | I think it might be best to check with freemangordon when he gets back, since he's most knowledgeable about clutter | 13:57 |
| Wizzup | It's been about 8 years since I made my last opengl program in uni ;) | 13:57 |
| rafael2k | Wizzup: ok | 13:58 |
| uvos | i have never touched any code in a professional or academic capacity - dont look at me :P | 13:58 |
| Wizzup | uvos: yeah so there are only three places that at least cause the error/invalid enum | 13:59 |
| Wizzup | $ grep -r GL_TEXTURE_2D . | grep glEnable | 13:59 |
| Wizzup | grep: ./.git/objects/pack/pack-829b37b8f8e1f79230c4ad5ee45798bf4de51ebb.pack: binary file matches | 13:59 |
| uvos | link? | 13:59 |
| Wizzup | ./clutter/cogl/common/cogl-pvr-texture-gl.c: GE( glEnable(GL_TEXTURE_2D) ); | 13:59 |
| Wizzup | ./clutter/eglx/clutter-eglx-texture-pixmap.c: glEnable (GL_TEXTURE_2D); | 13:59 |
| Wizzup | ./debian/patches/02-eglx-backend-tfp.patch:+ glEnable (GL_TEXTURE_2D); | 13:59 |
| Wizzup | well, it's clutter 0.8 repo | 13:59 |
| Wizzup | rafael2k: I can maybe do a build later today or tomorrow, esp if you suggest the config changes, but let's see | 13:59 |
| Wizzup | uvos: https://github.com/maemo-leste-upstream-forks/clutter-0.8 | 13:59 |
| Wizzup | uvos: probably not this: https://github.com/maemo-leste-upstream-forks/clutter-0.8/commit/e66ff577333ed34329c5289838c2139c6cbd26ea | 14:00 |
| Wizzup | uvos: so it looks like some of the commits depends on a specific extension being present | 14:01 |
| uvos | mhm | 14:02 |
| Wizzup | looking at https://github.com/maemo-leste-upstream-forks/clutter-0.8/commit/64c3f7a96d29effc5910331d57822d99b970d433 in particular | 14:02 |
| Wizzup | it could be that we just take the wrong unsupported path and that causes the enum issue perhaps | 14:02 |
| uvos | yes seams likely | 14:03 |
| Wizzup | although the glEnable is before that decision | 14:03 |
| Wizzup | I think the clutter 0.8 patches might not get applied at all | 14:04 |
| Wizzup | there doesn't seem to be a series file | 14:04 |
| Wizzup | bbiab | 14:05 |
| uvos | it also renders wrong on intel btw | 14:06 |
| Wizzup | so the lima guy said | 14:06 |
| Wizzup | 13:42 < enunes> Wizzup: hmm I played it but I'm still not sure what am I looking at | 14:06 |
| Wizzup | 13:43 < enunes> best case would be if a single trace reproduces the bug when played on the lima device and does not reproduce it on e.g. intel | 14:06 |
| Wizzup | which is why I wanted to try powervr | 14:07 |
| Wizzup | but imho the llvmpipe trace should suffice | 14:07 |
| Wizzup | I guess I could try to replay that on lima | 14:07 |
| uvos | its wrong on i965 too | 14:10 |
| uvos | so a bug in mesa is pretty unlikely | 14:10 |
| uvos | (i965 is a mesa classic dirver that shares very little with the gallium drivers radionsi/lima) | 14:11 |
| Wizzup | so this on the pp: | 14:12 |
| Wizzup | apitrace replay maemo-summoner-hildon-desktop-llvmpipe.trace | 14:12 |
| Wizzup | shows the same problems | 14:12 |
| Wizzup | this does not: | 14:12 |
| Wizzup | LIBGL_ALWAYS_SOFTWARE=1 apitrace replay maemo-summoner-hildon-desktop-llvmpipe.trace | 14:12 |
| Wizzup | and actually the replay looks ok speed wise | 14:12 |
| Wizzup | ish | 14:12 |
| uvos | heh | 14:12 |
| Wizzup | probably because the gpu is slow :) | 14:13 |
| uvos | well inky_ and rafael2k use hildon on llvmpipe on pp | 14:13 |
| uvos | so it must be okish sorta | 14:13 |
| uvos | certenly llvmpipe hildon on d4 is more than painfull | 14:13 |
| Wizzup | it's all painful imho | 14:14 |
| Wizzup | but ok | 14:14 |
| Wizzup | if you see just how butter smooth portrait h-d is with lima when it works :) | 14:14 |
| Wizzup | it's quite a sight | 14:14 |
| Wizzup | ok now actually brb | 14:14 |
| Wizzup | so lima supports EGL_KHR_image_pixmap but llvmpipe does not | 14:52 |
| uvos | k | 14:53 |
| Wizzup | so perhaps the way we do EGL_KHR_image_pixmap is broken | 14:53 |
| uvos | yes | 14:53 |
| Wizzup | (even though it clearly works for pvr) | 14:53 |
| uvos | sounds very possible | 14:53 |
| uvos | i would not count on pvr to enforce spec :P | 14:53 |
| uvos | so comment that path out and try on lima | 14:54 |
| Wizzup | it seemed to be more like mesa not following spec if I recall fmg correctly | 14:54 |
| uvos | yes what glamor did with khr image was ub | 14:54 |
| uvos | mesa just worked in this case | 14:55 |
| Wizzup | ok | 14:55 |
| Wizzup | btw lima has EGL_NOK_texture_from_pixmap not we search for something else | 14:55 |
| Wizzup | we search for EGL_NOKIA_texture_from_pixmap | 14:55 |
| Wizzup | freemangordon: ^^^ | 14:56 |
| Wizzup | pvr also as EGL_NOK_texture_from_pixmap it seems | 14:57 |
| Wizzup | ddk 1.17 at least | 14:57 |
| Wizzup | probably need to update that check too then | 14:57 |
| Wizzup | wondering if the call to eglCreateImageKHR perhaps needs updated img attribs | 14:59 |
| Wizzup | well hang on, why does the llvmpipe path still fail for lima then | 14:59 |
| Wizzup | maybe they interpret the KHR properties differently | 14:59 |
| Wizzup | EGL_KHR_partial_update seems to be in lima but not in pvr | 15:00 |
| Wizzup | so setting use_fallback=1 I think helps with firefox corruption, but not at all with osso-xterm problems I was tracing | 15:11 |
| Wizzup | but it does make vkb just work I think | 15:11 |
| Wizzup | we're onto something :) | 15:12 |
| Wizzup | checking for EGL_NOK_texture_from_pixmap instead of EGL_NOKIA_texture_from_pixmap has different behavious as well, the status area looks odd/off, and the other problems remain | 15:14 |
| Wizzup | so the current workaround is to set use_fallback to TRUE | 15:14 |
| Wizzup | there seems to be more problems still though | 15:17 |
| Wizzup | yeah no this is not the fix for some of the other problems at least | 15:19 |
| Wizzup | uvos: do you recall the obnoxious glib variable to print g_debug messages? | 15:24 |
| Wizzup | G_MESSAGES_DEBUG=all it is | 15:25 |
| Wizzup | maybe the problem is in clutter_eglx_texture_pixmap_update_area | 15:27 |
| Wizzup | this is beyond me for now | 15:38 |
| freemangordon | hmm? | 15:58 |
| freemangordon | seems I am missing the party :) | 15:58 |
| freemangordon | Wizzup: did you apply "glamor: add missing GL_TEXTURE_WRAP_X parameters"? | 15:59 |
| freemangordon | hmm, where do you see EGL_NOK_texture_from_pixmap? | 16:01 |
| Wizzup | freemangordon: hi! | 16:01 |
| Wizzup | let's take a step back a for a moment | 16:02 |
| freemangordon | sorry, I was too busy, I have some 30 minutes maybe now and I'll have to run (GF has birthday :) ) | 16:02 |
| freemangordon | ok | 16:02 |
| Wizzup | ok | 16:02 |
| Wizzup | congrats :) | 16:02 |
| freemangordon | thanks! | 16:02 |
| Wizzup | so we're seeing lots of flickering and drawing of old and invalid content on the pinephone | 16:02 |
| freemangordon | so, if I can help, go ahead | 16:02 |
| Wizzup | this manifests itself in a few ways: | 16:02 |
| Wizzup | 1. firefox flickers badly | 16:02 |
| Wizzup | 2. osso-xterm selection (with finger) renders wrongly and flickers intensely | 16:03 |
| Wizzup | 3. vkb doesn't render most of its content | 16:03 |
| Wizzup | there are a few more, like scrolling in most windows is SNAFU | 16:03 |
| freemangordon | ..and this gets fixed with no compositing | 16:03 |
| freemangordon | (I have read the backscroll) | 16:03 |
| freemangordon | so, it seems we suspect TFP now, correct? | 16:04 |
| Wizzup | I am not sure if this is entirely true wrt compositing | 16:04 |
| Wizzup | there might be several problems | 16:04 |
| Wizzup | just to add a few more bugs/problems: | 16:04 |
| freemangordon | BTW, if we misuse TFP, that might explain tearing we see on d4 with pvr | 16:04 |
| Wizzup | 4. title bars also often switch back and forth and even get some weird rotation angle | 16:04 |
| freemangordon | ught | 16:05 |
| freemangordon | *ugh | 16:05 |
| Wizzup | this is all gone when we use llvmpipe | 16:05 |
| Wizzup | all of the problems just disappear | 16:05 |
| Wizzup | llvmpipe however doesn't support TFP so it uses the fallback x11 path | 16:05 |
| freemangordon | mhm | 16:05 |
| Wizzup | this is replay with llvmpipe: https://wizzup.org/dirlist/maemo-leste/lima/dump-images/llvmpipe-trace-llvmpipe-redraw0000003542.png | 16:05 |
| Wizzup | this is with my laptop amd mesa: https://wizzup.org/dirlist/maemo-leste/lima/dump-images/llvmpipe-trace-amdgpu-redraw0000003542.png | 16:06 |
| freemangordon | one note re TFP - it is supported in VMs, so I doublt we misuse it | 16:06 |
| Wizzup | VMs are mostly llvmpipe | 16:06 |
| Wizzup | but well noted | 16:06 |
| freemangordon | not really | 16:06 |
| Wizzup | you can see the amd mesa one is clearly wrong | 16:06 |
| freemangordon | at least vmware and virtualbox provide 3d accell | 16:06 |
| freemangordon | right | 16:06 |
| freemangordon | but doesn;t seem like bad texture to me | 16:07 |
| Wizzup | there seem to be a pattern to it when I look at it in apitrace, the regions that were previously rendered black get turned white again in later frames | 16:07 |
| freemangordon | soemthing doesn;t get flushed? | 16:07 |
| Wizzup | possible | 16:07 |
| Wizzup | but note that X renders with glamor | 16:07 |
| Wizzup | and it works just fine when h-d is llvmpipe but X is lima | 16:07 |
| Wizzup | as far as I can tell | 16:08 |
| Wizzup | I haven't tested the opposite (glamor with llvmpipe and h-d with lima) | 16:08 |
| freemangordon | right, but then buffers are not allocated by lima driver | 16:08 |
| freemangordon | BOs that is | 16:08 |
| Wizzup | ok | 16:08 |
| Wizzup | so there are a few other things to note: | 16:08 |
| Wizzup | 1. not super relevant but the NOKIA extension we search for is present in mesa as NOK not NOKIA | 16:09 |
| Wizzup | 2. mesa complains about invalid enums in glEnable(GL_TEXTURE_2D) and some texture param calls | 16:09 |
| freemangordon | (this is new to me, was not there few months ago) | 16:09 |
| freemangordon | (16,59,40) freemangordon: Wizzup: did you apply "glamor: add missing GL_TEXTURE_WRAP_X parameters"? | 16:09 |
| Wizzup | 3. if I set use_fallback = TRUE with lima ( so the TFP checks are ommitted), some things work fine, but not all problems are solved, suggesting there are problems beyond TFP | 16:10 |
| freemangordon | so, did you apply that patch? | 16:10 |
| Wizzup | freemangordon: yes, looks like I have those applied | 16:10 |
| freemangordon | this is the 3rd one | 16:10 |
| Wizzup | yes | 16:10 |
| freemangordon | ok | 16:10 |
| Wizzup | this is basically where I am at now | 16:11 |
| freemangordon | I doubt we break TFP, clutter just issues 2 or 3 EGL calls | 16:11 |
| Wizzup | I am going to check how it goes with h-d using lima, but tfp hard disabled, I want to see if the osso-xterm selection bug is still there then | 16:11 |
| freemangordon | ok | 16:12 |
| Wizzup | so no, with TFP fallback in place, that redrawing bug is still there | 16:12 |
| freemangordon | as expected | 16:13 |
| Wizzup | but some bugs are fixed (like virtual keyboard rendering) | 16:13 |
| freemangordon | maybe because of the changed timing | 16:13 |
| Wizzup | could be | 16:13 |
| Wizzup | firefox also doesn't flicker as much anymore | 16:13 |
| Wizzup | in any case there is where I am stuck | 16:13 |
| freemangordon | so, what I think is - some fence is missing | 16:13 |
| Wizzup | the traces clearly render wrong on mesa | 16:14 |
| freemangordon | hmm | 16:14 |
| freemangordon | with llvmpipe? | 16:14 |
| freemangordon | on PC? | 16:14 |
| freemangordon | do we have some errors in retrace? | 16:15 |
| freemangordon | Wizzup: also, IIUC, we use GLES2 in clutter and OGL in glamor | 16:15 |
| Wizzup | freemangordon: no, llvmpipe renders fine | 16:15 |
| Wizzup | freemangordon: but if I render it on my PC it is also wrong with amdgpu | 16:15 |
| freemangordon | so, what is "mesa" then? | 16:16 |
| Wizzup | my amd radeon mesa driver | 16:16 |
| freemangordon | ah | 16:16 |
| uvos | we can totaly retire the idea that its glamor in any way | 16:16 |
| freemangordon | ok | 16:16 |
| uvos | this was proven in mulitple ways - not least of witch is i just tried the trace on amdgpu with acellMethod=none and dri2 | 16:16 |
| uvos | and it has the same problem | 16:16 |
| freemangordon | ok, but then there seems to be some issue in GL calls | 16:17 |
| Wizzup | in general I think if you look in qapitrace you will see the textures are wrong | 16:17 |
| Wizzup | so whatever flings the texture to the display ultimately is not at fault | 16:17 |
| freemangordon | but ofc they are wrong | 16:17 |
| Wizzup | yes, mostly saying that's probably not glamor as well | 16:17 |
| freemangordon | ah | 16:17 |
| freemangordon | I mean - retrace just displays those textures, like, the content was captured on the device | 16:18 |
| Wizzup | no | 16:18 |
| freemangordon | yes | 16:18 |
| Wizzup | on llvmpipe the same trace looks fine | 16:18 |
| freemangordon | omg | 16:18 |
| Wizzup | yup | 16:18 |
| freemangordon | ok, then some gl state is wrong | 16:18 |
| Wizzup | https://wizzup.org/dirlist/maemo-leste/lima/ | 16:18 |
| Wizzup | if you take maemo-summoner-hildon-desktop-llvmpipe.trace and run it through apitrace | 16:19 |
| freemangordon | *lima* is the bad one, right? | 16:19 |
| Wizzup | hang on | 16:19 |
| freemangordon | I am going to run that on my nvidia | 16:19 |
| Wizzup | you will see it's wrong even on amdgpu or on lima or etc | 16:19 |
| uvos | its just where the trace was recorded | 16:19 |
| Wizzup | BUT | 16:19 |
| Wizzup | if you set LIBGL_ALWAYS_SOFTWARE=1, then it renders fine | 16:19 |
| uvos | if it displays the problem depends on where it plays back | 16:19 |
| Wizzup | so: | 16:19 |
| freemangordon | ok, but I want to render it here | 16:19 |
| freemangordon | on PC with NVidia | 16:19 |
| Wizzup | right | 16:19 |
| Wizzup | so: | 16:19 |
| Wizzup | qapitrace /tmp/maemo-summoner-hildon-desktop-llvmpipe.trace | 16:19 |
| uvos | so it renders bad on gallium drivers (except llvmpipe) | 16:19 |
| Wizzup | vs | 16:20 |
| uvos | and on i965 | 16:20 |
| Wizzup | LIBGL_ALWAYS_SOFTWARE=1 qapitrace /tmp/maemo-summoner-hildon-desktop-llvmpipe.trace | 16:20 |
| Wizzup | will render differently | 16:20 |
| freemangordon | ok, but I could see some issue in GL state | 16:20 |
| Wizzup | I haven't tried it with the lima trace since I don't think it matters | 16:20 |
| Wizzup | (it just makes things more complicated) | 16:20 |
| Wizzup | freemangordon: yes, glEnable(GL_TEXTURE_2D) fails with invalid enum iirc | 16:21 |
| freemangordon | ugh: | 16:21 |
| freemangordon | error: unsupported trace format version 5 | 16:21 |
| freemangordon | and what is the current texture unit? | 16:21 |
| freemangordon | sorry, the current texture | 16:21 |
| Wizzup | I just use apitrace from beowulf repo | 16:22 |
| freemangordon | on my ubuntu? | 16:22 |
| freemangordon | hang on, I have built it | 16:22 |
| Wizzup | actually that glEnable error doesn't occur in the llvmpipe trace I think, only in the lima trace | 16:23 |
| Wizzup | yeah | 16:23 |
| Wizzup | (the llvmpipe trace probably doesn't even use TFP because clutter decides not to use it) | 16:23 |
| Wizzup | fwiw the lima trace renders fine using llvmpipe as well | 16:24 |
| freemangordon | which frame to look at? | 16:24 |
| freemangordon | Wizzup: also, this is capture of hildon-desktop, correct? | 16:25 |
| Wizzup | freemangordon: yes | 16:26 |
| Wizzup | freemangordon: in the lima or llvmpipe trace? | 16:26 |
| freemangordon | lima | 16:26 |
| Wizzup | sec | 16:26 |
| freemangordon | hmm, weird | 16:27 |
| freemangordon | I see nothing wrong with that glEnable(GL_TEXTURE_2D) call | 16:27 |
| Wizzup | I think around frame 20 things get a bit weird | 16:28 |
| Wizzup | where the framebuffers look different | 16:28 |
| Wizzup | at least in frame 24 | 16:28 |
| Wizzup | I think in frame 23 the framebuffer is wrong for the first time | 16:29 |
| Wizzup | it looks like in frame 23, after the glDrawArrays, the framebuffer is different | 16:31 |
| Wizzup | so maybe the glVertexAttribPointer stuff messes things up | 16:32 |
| freemangordon | nope | 16:32 |
| freemangordon | it looks fine here | 16:33 |
| Wizzup | you're not using mesa | 16:33 |
| Wizzup | and that's right before the glEnable(GL_TEXTURE_2D) call | 16:33 |
| freemangordon | no idea what I am using :) | 16:33 |
| Wizzup | which fails with | 16:33 |
| Wizzup | warning: GL_INVALID_OPERATION while reading framebuffer | 16:33 |
| Wizzup | freemangordon: well, does eglinfo say NVIDIA ? | 16:34 |
| freemangordon | sek | 16:35 |
| freemangordon | sec | 16:35 |
| freemangordon | https://pastebin.com/3mrpsCQs | 16:37 |
| freemangordon | Wizzup: ^^^ | 16:37 |
| Wizzup | yeah that is proprietary and binary driver | 16:37 |
| Wizzup | not mesa | 16:37 |
| freemangordon | but, it works :) | 16:38 |
| Wizzup | yes, which points towards differences in gl implementation, i.e. maybe mesa bug | 16:38 |
| freemangordon | hmm, wait | 16:38 |
| Wizzup | btw, when you wrote 'it works', I assume you also dumped all images | 16:38 |
| freemangordon | how to do that? | 16:39 |
| freemangordon | I am using UI | 16:39 |
| freemangordon | Wizzup: we should not have white stripe between black stripes, right? | 16:39 |
| Wizzup | right | 16:39 |
| freemangordon | ok | 16:39 |
| Wizzup | freemangordon: apitrace dump-images tracefile fileprefix | 16:39 |
| Wizzup | err | 16:39 |
| Wizzup | freemangordon: apitrace dump-images tracefile -o fileprefix | 16:40 |
| Wizzup | freemangordon: also see cmd.txt file if you want only one image | 16:40 |
| Wizzup | https://wizzup.org/dirlist/maemo-leste/lima/dump-images/cmd.txt | 16:40 |
| Wizzup | so in this case | 16:40 |
| Wizzup | apitrace dump-images maemo-summoner-hildon-desktop-lima.trace -o lima-trace-amdgpu-redraw --calls=2357 | 16:40 |
| Wizzup | you can change lima-trace-amdgpu-redraw to lima-trace-nvidia-redraw | 16:40 |
| freemangordon | ok, it is broken here as well | 16:40 |
| Wizzup | ok | 16:40 |
| Wizzup | this doesn't /have/ to mean it is not a mesa bug | 16:41 |
| freemangordon | in frame 30 | 16:41 |
| Wizzup | as in, it could be the case that the lima trace has other bugs | 16:41 |
| Wizzup | or rather, the bugs were somehow trace induced I would say | 16:41 |
| Wizzup | the cmd.txt has the other one to run the llvmpipe one as well | 16:42 |
| Wizzup | apitrace dump-images maemo-summoner-hildon-desktop-llvmpipe.trace -o llvmpipe-trace-amdgpu-redraw --calls=3542 | 16:42 |
| Wizzup | which should be: https://wizzup.org/dirlist/maemo-leste/lima/dump-images/llvmpipe-trace-llvmpipe-redraw0000003542.png | 16:42 |
| Wizzup | my amd gpu with mesa makes it: https://wizzup.org/dirlist/maemo-leste/lima/dump-images/llvmpipe-trace-amdgpu-redraw0000003542.png | 16:43 |
| freemangordon | hmm | 16:43 |
| Wizzup | maybe check that as well just to be sure | 16:43 |
| Wizzup | (i.e. what does nvidia make of that) | 16:43 |
| freemangordon | the same | 16:44 |
| Wizzup | the same - as whatr | 16:45 |
| freemangordon | yep, exactly the same | 16:45 |
| freemangordon | like amd redraw | 16:45 |
| Wizzup | ok | 16:45 |
| Wizzup | fwiw I think uvos say something else with his mesa | 16:45 |
| Wizzup | s/say/saw/ | 16:45 |
| Wizzup | I am going for a quick walk and maybe try to make sense of this later today | 16:46 |
| freemangordon | I am going on a party, laters (or rather tomorrow) :) | 16:47 |
| Wizzup | yep, enjoy | 16:48 |
| freemangordon | Wizzup: wait, wait | 16:49 |
| Wizzup | ? | 16:50 |
| freemangordon | what we see here is actually the texture imported by glEGLImageTargetTexture2DOES | 16:51 |
| Wizzup | what is 'here'? | 16:51 |
| freemangordon | in apr retrace | 16:51 |
| freemangordon | *apiretrace | 16:51 |
| Wizzup | so in qapitrace, or in dump images? | 16:51 |
| freemangordon | this *is* what has been recorded on the device | 16:51 |
| freemangordon | both | 16:51 |
| Wizzup | yes, but they render fine in llvmpipe still | 16:52 |
| Wizzup | and you can see the frame buffer gets wrong in the non-llvmpipe trace | 16:52 |
| Wizzup | qapitrace has a thing for the separate textures and framebuffers | 16:52 |
| freemangordon | sure | 16:52 |
| freemangordon | "surfaces" | 16:53 |
| Wizzup | https://wizzup.org/check.png for example the lima trace already looks different here | 16:53 |
| Wizzup | later on the framebuffers also become different | 16:53 |
| Wizzup | probably because a different texture is drawn | 16:54 |
| Wizzup | nvm my screenshot has different calls selected | 16:54 |
| Wizzup | anyway you get the diea | 16:54 |
| freemangordon | the point is - texture content gets recorded in the trace | 16:55 |
| Wizzup | updated the screenshot | 16:55 |
| Wizzup | freemangordon: then how come they are different in the same trace and different drivers? | 16:55 |
| Wizzup | otherwise I am not arguing with you | 16:55 |
| Wizzup | see https://wizzup.org/check.png (refresh) | 16:55 |
| freemangordon | yes, refreshed | 16:55 |
| freemangordon | so, framebuffers differ | 16:55 |
| Wizzup | yes, this is where they start to differ | 16:55 |
| freemangordon | and that could be a result of bad GL calls | 16:56 |
| freemangordon | but, textures cannot differ | 16:56 |
| Wizzup | yes, but the llvmpipe results ends up being correct still | 16:56 |
| Wizzup | ok | 16:56 |
| Wizzup | sure | 16:56 |
| freemangordon | because their contents comes from the trace | 16:56 |
| Wizzup | that's why I suggested to use the llvmpipe trace :) | 16:56 |
| freemangordon | ah | 16:56 |
| freemangordon | ok | 16:56 |
| freemangordon | :) | 16:56 |
| Wizzup | but it has the same problems | 16:56 |
| freemangordon | hmm, something 64bit related? | 16:57 |
| Wizzup | in clutter you mean? | 16:57 |
| freemangordon | it is possible that clutter has issues calculating vertex buffer contents | 16:57 |
| freemangordon | yes, in clutter | 16:57 |
| Wizzup | could be, but aren't our VMs 64 bit? | 16:58 |
| freemangordon | or uniforms | 16:58 |
| freemangordon | yes, they are | 16:58 |
| freemangordon | but FP has different representation in intel and ARM | 16:58 |
| Wizzup | it is possible, but I'd like to first understand where the problem comes from | 16:59 |
| freemangordon | so on intel we might not have issues simple because of the way FP values are represented in memory | 16:59 |
| Wizzup | again, llvmpipe does not show problems | 16:59 |
| freemangordon | I understand taht | 16:59 |
| Wizzup | doesn't that use the same fp calc? | 16:59 |
| Wizzup | and also disabling TFP and forcing fallback has the same problems | 16:59 |
| Wizzup | but I suppose vbo's are still in play somehow | 17:00 |
| Wizzup | <--- not expert on gl | 17:00 |
| freemangordon | could you compare uniforms betwee llvmpipe and amd? | 17:00 |
| Wizzup | compare at which step? | 17:00 |
| freemangordon | glUniformMatrix... | 17:01 |
| freemangordon | hmm, why vertex buffers data is not avalable :( | 17:02 |
| Wizzup | they look the same to be | 17:03 |
| Wizzup | to me* | 17:03 |
| freemangordon | Wizzup: hmm, in llvmpipe capture there are no (visible)textures | 17:05 |
| Wizzup | freemangordon: there is no tfp | 17:06 |
| Wizzup | it's x11 fallback | 17:06 |
| freemangordon | ah, right :) | 17:06 |
| * Wizzup actually afk for ~15 mins now | 17:08 | |
| freemangordon | ok | 17:08 |
| freemangordon | for me it is broken with LIBGL_ALWAYS_SOFTWARE=1 too | 17:15 |
| freemangordon | lima trace that is | 17:15 |
| uvos | you use nvidia gl | 17:15 |
| uvos | that dosen suport that envvar no? | 17:15 |
| freemangordon | no idea | 17:16 |
| freemangordon | lemme check | 17:16 |
| uvos | it dosent | 17:16 |
| uvos | its implemendted by mesa | 17:16 |
| freemangordon | yeah | 17:16 |
| freemangordon | ok, my gut feeling tells me we have some issues in clutter because of 64 bits | 17:17 |
| freemangordon | but, will continue tomorrow. | 17:18 |
| freemangordon | night! | 17:18 |
| Wizzup | so the gl invalid enum could be because of this: https://community.khronos.org/t/getting-gl-invalid-enum-when-calling-glenable-gl-texture-2d/72631/2 | 17:44 |
| Wizzup | looks like gles doesn't support it (obviously I guess) | 17:46 |
| uvos | gles2 dosent have ff | 17:47 |
| uvos | so probubly not | 17:47 |
| Wizzup | yeah | 17:48 |
| Wizzup | btw: https://github.com/apitrace/apitrace/issues/180#issuecomment-27319122 | 17:56 |
| Wizzup | doesn't look like we do that though | 17:56 |
| Wizzup | freemangordon: btw it doesn't look like the debian patches are applied at all | 17:58 |
| Wizzup | of clutter | 17:58 |
| Wizzup | looks like we have them in git, to nvm | 17:59 |
| lel | Dastan-glitch synchronize a pull request: https://github.com/maemo-leste/liblocation/pull/1 (More readable code + factors) | 19:45 |
| rafael2k | https://gitlab.com/debian-pm/devices/sunxi-mali | 19:50 |
| lel | parazyd closed a pull request: https://github.com/maemo-leste/liblocation/pull/1 (More readable code + factors) | 19:54 |
| Wizzup | parazyd: maybe the code can mention why the measuring math was changed, and to what | 19:57 |
| Wizzup | I see it in the PR but not in the code | 19:57 |
| parazyd | *shrug* | 19:59 |
| parazyd | I don't want to scare off people contributing by being super pedantic | 19:59 |
| Wizzup | he mentions a better algorithm but then we don't actually use it | 19:59 |
| Wizzup | parazyd: I committed the comments to liblocation | 20:03 |
| Wizzup | if this breaks it would be nice to know where it came from, so I added the guys remark | 20:04 |
| Wizzup | as in I don't think we test this code at all yet (distance from p1 to p2) so we probably don't know if it works even | 20:04 |
| parazyd | ok, thanks | 20:05 |
| parazyd | It's a textbook algorithm | 20:05 |
| Wizzup | right but we're swapping one textbook one out for another | 20:07 |
| Wizzup | I don't know if there's a reason one is more accurate for small distances than others, or why nokia went for one that's more accurate for longer distances | 20:07 |
| Wizzup | as in why not go for the 'king' algorithm | 20:08 |
| parazyd | This new one is faster | 20:11 |
| parazyd | And my algorithm was also from a textbook, not from the binary. | 20:11 |
| Wizzup | oh | 20:12 |
| Wizzup | uvos: I added nvidia renders here: https://wizzup.org/dirlist/maemo-leste/lima/dump-images/ | 20:19 |
| rafael2k | I forked | 20:21 |
| rafael2k | pine64-kernel | 20:21 |
| rafael2k | will go for mobian 5.15.x with pp patches, which is pretty decent | 20:21 |
| Wizzup | sounds great | 20:21 |
| Wizzup | please add the battery patch | 20:21 |
| rafael2k | yeap, that will be the only "extra" patch | 20:22 |
| rafael2k | I will just take some days, as testing each different setup takes some time to compile natively | 20:23 |
| rafael2k | but I have no rush | 20:23 |
| rafael2k | :P | 20:23 |
| Wizzup | hmm ok | 20:23 |
| Wizzup | why compile natively? | 20:23 |
| Wizzup | cross compiling the kernel is probably the easiest cross compile ever imho | 20:24 |
| rafael2k | why not? | 20:24 |
| Wizzup | because your laptop can probably do it in ~3 mins :P | 20:24 |
| rafael2k | if the pp does not make it or take way too much, I'll cross | 20:24 |
| Wizzup | *shrug* up to you :P | 20:25 |
| rafael2k | I even connected it to a powerfull wall adapter, hopefully it will not turn off... eheheheh | 20:26 |
| rafael2k | but after I managed to compile mozilla with -j1, I think anything will be possible | 20:26 |
| rafael2k | the PR should go to beowulf-devel right (the debian dir)? | 20:28 |
| Wizzup | right, well, also the actual code needs to go the repo and also a tag | 20:28 |
| Wizzup | so probably you don't want to do it in a pr and rather tell me or parazyd 'pull this code in' | 20:30 |
| rafael2k | right... importing sunxi64-linux to github... it is taking some time | 20:31 |
| Wizzup | yes, usually the right way to do it is just merge it stuff into the existing tree | 20:31 |
| Wizzup | since 99.99999% of the tree is shared | 20:31 |
| rafael2k | ok, but mobian keeps the debian/ dir already inside the repo... I will kick it out (and may be borrow some stuff) | 20:32 |
| rafael2k | hum, I could just have forked torvals/linux... just realized mobian git basically is the linux kernel + debian dir | 20:33 |
| rafael2k | :/ | 20:33 |
| Wizzup | it doesn't really matter, you can keep the debian dir in there | 20:33 |
| Wizzup | yes | 20:33 |
| rafael2k | ok | 20:33 |
| parazyd | You can't push a whole kernel tree at once to github btw | 20:34 |
| parazyd | https://parazyd.org/pub/dev/random/push-in-increments.sh | 20:35 |
| Wizzup | you can just have a linux repo with many remotes | 20:35 |
| Wizzup | I do that for n9xx-linux, droid4-linux, pine64-linux, etc | 20:35 |
| parazyd | Yeah I mean pushing to an empty gh repo | 20:35 |
| Wizzup | git is clever enough to sort everything else out | 20:35 |
| rafael2k | how I miss subversion... | 20:37 |
| rafael2k | :P | 20:37 |
| Wizzup | let me be blunt | 20:38 |
| Wizzup | you only miss it because you don't understand the power of git yet | 20:38 |
| Wizzup | <--- coming from someone who used to like svn | 20:38 |
| rafael2k | eheheheh | 20:38 |
| rafael2k | so good the r1234... knew by heart the commit numbers | 20:40 |
| rafael2k | I understand the power... I just don't need it | 20:41 |
| rafael2k | tarballs, patch and diff are good | 20:41 |
| rafael2k | anyway, I use git everywhere... | 20:42 |
| rafael2k | lemme focus here on this kernel not to forget upower lines | 20:42 |
| Wizzup | :) | 20:42 |
| rafael2k | yay, checking the patches for the 5.15, we'll have already the pinephone keyboard support, when it hit the streets | 21:09 |
| rafael2k | these ubuntu-touch guys are really annoyng.. a patch to config just to remove sysrq support... I like it so much | 21:10 |
| uvos | we do that too | 21:11 |
| rafael2k | :( | 21:11 |
| uvos | its because uart devices | 21:11 |
| rafael2k | any reason? | 21:11 |
| uvos | can be noisy so sometimes they broadcast sysrq randomly | 21:11 |
| rafael2k | right, did not know | 21:11 |
| uvos | mapphones have this problem for instance they would just spontainously reboot | 21:12 |
| uvos | because of sysreq being pressed by pluging in a charger :P | 21:12 |
| rafael2k | so cool to alt+sysrq+O and the computer just instantly shuts down | 21:12 |
| rafael2k | shit | 21:12 |
| rafael2k | right, sysrq stays N then | 21:12 |
| uvos | well we dont disable sysrq in kernel | 21:13 |
| uvos | but we do so early in the boot proccess via init | 21:13 |
| rafael2k | this is more elegant... | 21:13 |
| uvos | so that it still works if you need it to debug the phone | 21:13 |
| rafael2k | I'll not touch the mobian config to start, as it is working fine, just add the patch we need to make battery leve appear, and we should be fine | 21:16 |
| rafael2k | crypto modules are there already, all good | 21:18 |
| Wizzup | :) | 21:19 |
| rafael2k | https://github.com/rafael2k/pine64-kernel/tree/maemo/beowulf-devel | 22:02 |
| Wizzup | ok so now we need a branch with the kernel code and a tag that points to it | 22:04 |
| Wizzup | in this case the tag needs to be: https://github.com/rafael2k/pine64-kernel/blob/maemo/beowulf-devel/debian/gbp.conf | 22:04 |
| Wizzup | maemo-kernel-5.15 | 22:04 |
| rafael2k | ok | 22:07 |
| rafael2k | should I change anything? | 22:08 |
| rafael2k | ah ok, the tag in the git... | 22:08 |
| rafael2k | shit, I put the kernel in another repo | 22:09 |
| rafael2k | it will be here (still creating): https://github.com/rafael2k/sunxi64-linux | 22:10 |
| rafael2k | git is powerfull, I will find a way | 22:11 |
| Wizzup | what branch is the kernel at? | 22:15 |
| Wizzup | I can try to pull it in | 22:15 |
| Wizzup | yeah ok it's still empty :( | 22:15 |
| Wizzup | you really ought to just add it to the pine64-kernel repo | 22:16 |
| Wizzup | rafael2k: did you know git remotes can just be filesystems? | 22:16 |
| Wizzup | rafael2k: rather, paths on the filesystem | 22:16 |
| Wizzup | rafael2k: so from pine64-kernel you can probably do something like | 22:17 |
| Wizzup | git add remote sunxi64 /path/to/sunxi-kernel/.git (or so) | 22:18 |
| Wizzup | and then git checkout -t sunxi64/kernel-branch-yeah from pine64-kernel | 22:18 |
| Wizzup | and then just git push that | 22:18 |
| Wizzup | (this is untested but I think it can work) | 22:18 |
| rafael2k | tks! | 22:22 |
| rafael2k | if kernel works fine and debian package build finish successfully, I'll shout for help on how to use git | 22:26 |
| rafael2k | ; ) | 22:26 |
| Wizzup | k | 22:27 |
| Wizzup | meanwhile new mesa is hitting beowulf-devel finally | 22:27 |
| Wizzup | sicelo: now I think you should be able to apt-get dist-upgrade (well, in a few minutes) | 22:28 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
