| freemangordon | uvos: are you sure modesetting uses double-buffering? | 07:41 |
|---|---|---|
| freemangordon | as I see nowhere in the code (and also in the traces of the calls to glamor replacement) a back-buffer to be created | 07:42 |
| freemangordon | and yes, reading through internet confirms that modesetting/glamor use only one front buffer | 07:46 |
| freemangordon | *only one buffer - front buffer | 07:46 |
| freemangordon | and they should prevent tearing "by using DRI page flipping", whatever this is supposed to mean | 07:47 |
| freemangordon | so, either this page flipping is broken on ms (which I doubt) ot it is broken in omapdrm | 07:48 |
| freemangordon | ..or, ms expects draws to happen during VBLANK only, which may work on destop, but I don;t see how it can work in our case | 08:08 |
| Wizzup | freemangordon: did you see the patches online that added 'tearfree' to modesetting (not for rotated displays) | 08:33 |
| freemangordon | no, but all around internet they say modestiing is tear-free | 08:34 |
| freemangordon | bu, let me check those | 08:34 |
| Wizzup | modesetting is not tear free, also on my ryzen laptop | 08:36 |
| Wizzup | I have to do this, which also hurts perf: xrandr --output eDP --set TearFree on | 08:36 |
| Wizzup | heh my laptop seems to use intel xorg module, not radeon or modesetting, will need to look into that... | 08:38 |
| freemangordon | so, basically we don't have double-buffering? | 08:38 |
| freemangordon | and without that I would say MS is useless | 08:39 |
| freemangordon | in our use-case that is | 08:39 |
| freemangordon | not only id doesn't support double-buffer, but it supports SW rotation only | 08:40 |
| freemangordon | s/id/it | 08:40 |
| freemangordon | hmm, is it possible I am getting this wrong and the actual issue to be in either clutter or hildon-desktop or in pvr drivers | 09:08 |
| freemangordon | because I don;t see how MS can repeat the last 3 frames given it uses only one FB | 09:09 |
| freemangordon | so it should be something in clutte | 09:09 |
| freemangordon | *clutter | 09:09 |
| freemangordon | or, glReadPixels is broken | 09:10 |
| freemangordon | ok, I will have to trace mesa calls | 09:11 |
| uvos | freemangordon: no i have no idea if ms has a back buffer | 10:30 |
| uvos | dident you assert that (maybe i missunderstood) | 10:30 |
| uvos | sphone update: evolution support, external scripting, more modularisation etc | 10:40 |
| uvos | anyone know a good tool to explore evolution stores? | 10:40 |
| uvos | for some reason on my device there are multiple address books and the right one is not the default | 10:41 |
| uvos | also i have a empty store called system-address-book thats not even marked as an adressbook... | 10:41 |
| uvos | anyhow if you have the same problem you can point sphone to the right source: https://github.com/maemo-leste/sphone/blob/d117a99a16e4c9f943df1c240b9a46de81498421/config/sphone.ini#L62 | 10:42 |
| Wizzup | uvos: maybe look at the syncevolution stuff | 11:02 |
| Wizzup | not sure if it helps somehow | 11:02 |
| uvos | Wizzup: i think the syncevolution ui is what broke my setup like this | 11:03 |
| uvos | Wizzup: buy yeah we should fix it | 11:03 |
| Wizzup | what do you mean broke your setup | 11:03 |
| uvos | it added a bounch of stores | 11:03 |
| uvos | that dont work | 11:03 |
| uvos | and made them default i think | 11:03 |
| uvos | since i tried to use it several times before setting up evolution by hand | 11:04 |
| uvos | and it crashes out when you do that before finishing | 11:04 |
| Wizzup | weird, I did not have problems with syncevo and it did seem to sync the right rhings | 11:04 |
| uvos | you also setup the stores by hand | 11:05 |
| Wizzup | maybe you need more osso-abook support | 11:05 |
| uvos | and then just used syncevo ui to sync | 11:05 |
| uvos | osso-abook has exatcly the same problem on my device | 11:05 |
| uvos | (as it allso uses the default address book) | 11:05 |
| uvos | (as provided by evolution) | 11:06 |
| Wizzup | uvos: upgrading to latest sphone now :) | 11:48 |
| Wizzup | yeah so the contacts button doesn't do anything for me, but I don't think I tried to sync contacts yet | 11:54 |
| Wizzup | I could actually sync my fremantle contacts to this leste d4 using syncevo | 11:54 |
| uvos | it should not, that button just pushes to a datapipe thats supposed to open the contact in an external application (or implement a window itself). i have a tiny module that opens gnome-contacts, but there is nothing else behind there atm | 11:55 |
| uvos | the evolution contacts support is about displaying the right name etc | 11:56 |
| uvos | when a call comes in and sutch | 11:56 |
| Wizzup | aha | 11:56 |
| Wizzup | check | 11:56 |
| uvos | basicly this is placeholder for abook | 11:57 |
| uvos | on maemo | 11:57 |
| Wizzup | ok | 11:58 |
| uvos | upps | 12:00 |
| uvos | it built without contacts-evolution support on jenkins | 12:00 |
| uvos | sec | 12:00 |
| Wizzup | random note: if we turn on keyboard leds, let's also turn on ts buttons leds | 12:01 |
| Wizzup | (for als purposes) | 12:01 |
| sicelo | I think both you and I disabled that. Wasn't it that way before? :-) | 12:03 |
| Wizzup | hm, maybe yeah | 12:03 |
| Wizzup | or maybe before we had ts buttons | 12:03 |
| Wizzup | where it made less sense | 12:03 |
| sicelo | At least I found it distracting, and iirc I disabled it on my local install | 12:04 |
| uvos | Wizzup: yeah basicly it works that way by default in mce | 12:04 |
| Wizzup | oh | 12:04 |
| Wizzup | heh | 12:04 |
| uvos | there are some brigness values where the ts-buttons will be off but the kbd on | 12:05 |
| uvos | thats down to the fact that the ts-buttons are 1 bit | 12:05 |
| uvos | and the kbd is 8bit | 12:05 |
| Wizzup | I think I managed to send myself a zero char sms via sphone by accidenet | 12:05 |
| uvos | so mce can dim the kbd | 12:05 |
| Wizzup | then the window didn't really work anymore | 12:05 |
| uvos | but has to choose on or off for tsbuttons | 12:06 |
| Wizzup | doesn't really matter, just ran into it | 12:06 |
| uvos | Wizzup: hmm ok | 12:06 |
| Wizzup | right @ 1bit | 12:06 |
| Wizzup | uvos: I did receive the sms hehe | 12:06 |
| Wizzup | I regularly send myself smses to kick the modem for data connections | 12:06 |
| uvos | ok yeah the old backend might have stopped you from sending whithout text | 12:06 |
| uvos | so you want it to stay? i think its maybe not so great for most users. | 12:07 |
| Wizzup | it's not so great, but I plan to use the non existent conversations stuff | 12:07 |
| Wizzup | so it was more like a 'do not bother fixing it for me' | 12:07 |
| uvos | anyhow im rebuilding sphone hopfully with evolution module being built too | 12:08 |
| uvos | Hildon support enabled | 12:08 |
| uvos | Profiled support enabled | 12:08 |
| uvos | GStreamer support enabled | 12:08 |
| uvos | Pulseaudio support enabled | 12:08 |
| uvos | Evolution address book support enabled | 12:09 |
| uvos | looks like it worked now | 12:09 |
| uvos | ok so sphone in repos should be ok now | 12:18 |
| Wizzup | will update | 12:19 |
| uvos | i dident update the version number | 12:20 |
| uvos | so you have to reinstall | 12:20 |
| Wizzup | I think it would be nice to give it the x-maemo-icon and stuff, then ham will also show it | 12:20 |
| Wizzup | ow | 12:20 |
| Wizzup | I think we auto bump the epoch no? | 12:20 |
| uvos | no idea | 12:20 |
| uvos | i do we? | 12:20 |
| Wizzup | yup | 12:20 |
| uvos | mhh | 12:20 |
| uvos | ok | 12:21 |
| Wizzup | apt upgrade pulls it | 12:21 |
| uvos | wrt x-maemo-icon | 12:21 |
| uvos | its not in extras | 12:21 |
| uvos | so that wont work | 12:21 |
| uvos | also surely the intention is to have it in the metapackage as soon as n900 stops crashing with it | 12:22 |
| Wizzup | I think it should still work | 12:22 |
| Wizzup | for update purposes | 12:22 |
| Wizzup | as in, I do not think only happens for -extras | 12:22 |
| Wizzup | as far as ham knows it is just another repo | 12:22 |
| uvos | i thought it only read from hildon-application-manager.list | 12:22 |
| Wizzup | not sure... | 12:23 |
| uvos | which contains only deb https://maedevu.maemo.org/extras beowulf main contrib non-free | 12:23 |
| Wizzup | contacts button still does not open anything but I might not have the evo ui installed | 12:29 |
| uvos | thats correct behavior as mentioned before | 12:29 |
| uvos | there is no module that provides contactui in mainline sphone | 12:29 |
| uvos | atm | 12:29 |
| uvos | there is also no sutch thing as evo ui:P | 12:30 |
| Wizzup | ah check | 12:36 |
| freemangordon | uvos: well, I was *expecting* ms to have back buffer | 14:34 |
| freemangordon | but, obviously it doesnt | 14:34 |
| freemangordon | so, those 'repeating frames' in the video are because of something else | 14:35 |
| uvos | yeah | 14:35 |
| uvos | but it tearing is no supprise | 14:35 |
| freemangordon | actually h-d scrolling does not tear | 14:36 |
| freemangordon | on fremantle it does | 14:36 |
| uvos | (altho with cm-mode display you could avoid taring by only updating it when your done with the front buffer) | 14:36 |
| freemangordon | but, it suffers from the same "frame repeat" | 14:36 |
| uvos | effectively using the display as the front bufer | 14:36 |
| uvos | what freemantle? | 14:36 |
| freemangordon | no | 14:36 |
| uvos | ok | 14:36 |
| freemangordon | on fremantle there is tearing | 14:36 |
| uvos | right | 14:36 |
| freemangordon | but no "frame repeat" | 14:37 |
| uvos | right | 14:37 |
| freemangordon | on 1.17 there is no tearing | 14:37 |
| freemangordon | as far as I can see | 14:37 |
| uvos | you should not expect tearing in compositing wm | 14:37 |
| uvos | if it vsyncs its gl buffers | 14:37 |
| uvos | anyhow | 14:37 |
| uvos | is there some other gles 2 compositing wm | 14:38 |
| uvos | ? | 14:38 |
| uvos | to eleminate clutter/hildon having a bug | 14:38 |
| uvos | (tho i still mostly suspect the kernel) | 14:38 |
| uvos | looks like kwin has gles support | 14:39 |
| freemangordon | mutter? | 14:39 |
| uvos | no idea | 14:40 |
| freemangordon | yep, it uses clutter | 14:41 |
| freemangordon | but maybe it is no longer available | 14:42 |
| freemangordon | I wonder if it makes sense to RE the missing parts from pvr_dri | 14:43 |
| uvos | well we would want something that _dosent_ use clutter | 14:43 |
| Wizzup | freemangordon: could it be the flush behaviour you set to 2 somehow/ | 14:43 |
| freemangordon | it will use clutter 1 anyways | 14:43 |
| freemangordon | Wizzup: I tried with different settngs for that, makes no difference | 14:43 |
| Wizzup | ok | 14:44 |
| freemangordon | actually this flush behavior tells PRV blobs what to do on glFlush()/glFinish() | 14:44 |
| freemangordon | by default they do nothing ;) | 14:44 |
| uvos | freemangordon: so do twm or x with built in wm have issuse on gles surfaces created by clients | 14:44 |
| uvos | ? | 14:45 |
| freemangordon | lemme try twm | 14:45 |
| freemangordon | oh, I have to do that on n900 :( | 14:45 |
| freemangordon | btw, pvr-dri in blobs reports egl 1.5, chromeos 1.4 | 14:46 |
| uvos | would make some sense if chromeos is based on older tree then ti blobs | 14:47 |
| freemangordon | mhm | 14:48 |
| freemangordon | for sure it is | 14:48 |
| freemangordon | there are differences in the code | 14:48 |
| freemangordon | that's why I think I shall RE the missing stuff | 14:49 |
| freemangordon | that way we will have working clmark on d4 | 14:49 |
| freemangordon | *glmark | 14:49 |
| freemangordon | twm: unable to open fontset "-adobe-helvetica-bold-r-normal--*-120-*-*-*-*-*-*" | 14:51 |
| freemangordon | :( | 14:51 |
| Wizzup | compton can make things compositing | 14:52 |
| uvos | on gles? | 14:53 |
| Wizzup | oh, yeah.. | 14:53 |
| uvos | i dont think there is any modern gles 2 compositing wm besides kwin | 14:54 |
| uvos | (from googling around the last couple of min( | 14:54 |
| freemangordon | running es2gears on d4 with twm, hxorg hangs as soon as I try to move the window | 14:56 |
| uvos | hmm :( | 14:57 |
| freemangordon | hangs == uses 100% cpu and is not responding | 14:57 |
| freemangordon | last frame in gdb is: | 14:58 |
| freemangordon | #3 0xb5bf0fbc in ?? () from /usr/lib/arm-linux-gnueabihf/libsrv_um.so.1 | 14:58 |
| freemangordon | let me try on n900 | 15:00 |
| freemangordon | same happens with closed blobs, on both d4 and n900 | 15:24 |
| uvos | weeee bugs | 15:27 |
| uvos | dose the calls stack involve deleating or creating surfaces by anny chance? | 15:27 |
| freemangordon | I doubt, but I can check waht is the last call in 'my' ddx | 15:32 |
| freemangordon | well, in glamor replacement | 15:33 |
| freemangordon | ok, when I use 'slow path' to copy PRESENT textures, Xorg does not hang | 15:41 |
| freemangordon | with twm when moving es2gears that is | 15:44 |
| tmlind | i've seen few small gray squares not getting updated still, much smaller than earlier and rarer | 17:08 |
| freemangordon | uvos: after all, it is modesetting driver causing those repeating frames, after disabling PageFlip it looks fine | 18:11 |
| freemangordon | I have to understand what this option is supposed to do | 18:12 |
| freemangordon | also, any hint how to fix font sizes? | 18:12 |
| uvos | freemangordon: pageflip was added for vrr | 18:22 |
| uvos | freemangordon: it changes the way x waits for vsync | 18:22 |
| uvos | i dont know how really | 18:22 |
| uvos | wrt font sizes | 18:22 |
| uvos | you need to break the dpi setting again | 18:22 |
| uvos | x as a commandline option for dpi | 18:22 |
| uvos | or you can override the size of the display | 18:22 |
| freemangordon | 96x96? | 18:23 |
| uvos | yes | 18:23 |
| freemangordon | ok, thanks | 18:23 |
| uvos | esaiest way is to add DisplaySize to Section "Monitor" in xorg.conf | 18:24 |
| uvos | just caluclate what size the display would be at 96dpi | 18:24 |
| uvos | droid 4 would be 250 x 140mm | 18:25 |
| freemangordon | ok | 18:27 |
| uvos | so page flip not working suggests something is wrong in omapdrm | 18:27 |
| uvos | btw | 18:27 |
| uvos | since this is all about adding a new path that was added to drm at a later iirc | 18:28 |
| uvos | *later date | 18:29 |
| freemangordon | not sure, because I am still to understand what exactly it tries to flip | 18:36 |
| uvos | ok | 18:36 |
| uvos | if the "legacy" path works | 18:36 |
| uvos | i would ignore this for now and work on the other bugs | 18:36 |
| uvos | unless you belive it intersects ofc | 18:37 |
| freemangordon | it lowers the performance for fulscreen applications it seems | 18:38 |
| freemangordon | though, I am not sure | 18:38 |
| freemangordon | but yeah, I am goingt o ignore this for now | 18:38 |
| freemangordon | I have another low-hanging fruit first, in terms of performance - 16 bpp | 18:39 |
| uvos | 16 bpp will likely never be viable | 18:39 |
| uvos | i know you like it | 18:39 |
| freemangordon | Xorg starts and everything besides hildon-desktop works fine | 18:39 |
| uvos | but i belive its a waste of time | 18:39 |
| uvos | yeah but lots of x applications just assume 32bit | 18:39 |
| freemangordon | not in fremantle :p | 18:39 |
| uvos | and all they have as a fallback is converting 32bit to 16 to output the surface to x | 18:40 |
| uvos | so that absolutly kills perf | 18:40 |
| freemangordon | but, we have FPS doubling for 3d | 18:40 |
| freemangordon | have to cook, ttyl | 18:41 |
| uvos | ttyl | 18:41 |
| bencoh | fps doubling? what the heck | 18:41 |
| uvos | bencoh: well on ddk1.9 gears runs at 25fps | 18:41 |
| bencoh | ah, I see | 18:41 |
| uvos | fps doubling just means running ok :P | 18:41 |
| bencoh | nevermind :) | 18:41 |
| uvos | yeah its on ddk1.9 its 26fps with hildon running and 50 without and 28 on llvmpipe :P | 18:45 |
| uvos | also dosent matter if you run gears or if you run something like neverball | 18:46 |
| uvos | everything gets the same fps | 18:46 |
| uvos | (ie its not related to render complexity its just how fast the cpu can copy the buffer to display in sw) | 18:47 |
| Wizzup | freemangordon: so if this is solved, the weird reverts, and the x11pers problems do not show in h-d, that's quite an achievement | 19:05 |
| Wizzup | x11perf | 19:05 |
| freemangordon | uvos: this is on d4? | 19:26 |
| freemangordon | Wizzup: yeah, seems x11perf problems are solved when it runs in h-d | 19:27 |
| freemangordon | but performance is low | 19:27 |
| uvos | freemangordon: YES | 19:27 |
| freemangordon | oh, that's nasty | 19:28 |
| freemangordon | something has to be fixed on d4, as h-d doesn;t render | 19:28 |
| Wizzup | freemangordon: how low? | 19:28 |
| Wizzup | oh | 19:29 |
| uvos | maybe because you disabled xorgs vrr support? try with hdmi... | 19:29 |
| freemangordon | on N900: | 19:29 |
| freemangordon | x11perf -comppixwin500: | 19:29 |
| freemangordon | 120 reps @ 44.8331 msec ( 22.3/sec): Composite 500x500 from pixmap to window | 19:29 |
| freemangordon | gtkperf, n900: | 19:30 |
| freemangordon | Total time: 185.47 | 19:30 |
| freemangordon | this is with every pixmap backed by a mmap-ed BO | 19:30 |
| freemangordon | and without any PVR 2D rendering | 19:31 |
| Wizzup | ok | 19:32 |
| Wizzup | I mean, it doesn't sound too bad, right? | 19:32 |
| * Wizzup needs to find the old perf numbers | 19:32 | |
| freemangordon | uvos: no matter what I do, h-d does not render on d4 | 19:32 |
| freemangordon | but I suspect pvr_dri | 19:32 |
| Wizzup | is this a new problem? | 19:32 |
| freemangordon | no | 19:32 |
| Wizzup | ok | 19:33 |
| freemangordon | I mean - not from today :) | 19:33 |
| Wizzup | right | 19:33 |
| Wizzup | yeah I was asking when/if you recalled it working on ddk 1.17 | 19:33 |
| Wizzup | meanwhile, I got to a place in sofia, and I need to find some food before things close | 19:33 |
| freemangordon | I don;t think it ever worked, because we didn;t have support for x11 in blobs | 19:34 |
| Wizzup | ok | 19:34 |
| freemangordon | and my shim is still missing some functions needed by glmar/h-d to run | 19:34 |
| freemangordon | also, I don;t think I should invest more time in shim, no? | 19:34 |
| freemangordon | I'd rather fix chromeos mesa | 19:35 |
| Wizzup | probably makes sense yeah, but I don't know I know enough to give an informed opinion | 19:35 |
| freemangordon | well, no matter how good my shim is, it will never be as good as native support in mesa | 19:36 |
| Wizzup | agreed | 19:36 |
| freemangordon | the situation was desperate back then, that's why I started writing it | 19:38 |
| Wizzup | freemangordon: does it make sense for me to look at if we can package this for n900? | 20:01 |
| freemangordon | too early I guess | 20:02 |
| freemangordon | lets have something that works most of the time | 20:02 |
| tmlind | freemangordon: +1 for fixing the chromeos mesa | 20:03 |
| freemangordon | yeah, I am on it | 20:04 |
| freemangordon | hmm, seems blobg provide GL support too | 20:04 |
| freemangordon | *blobs | 20:04 |
| tmlind | so i'm getting PVR:(Error): PVRDisplayBufferCreate: Failed to create display buffer (err=13) [0, ] but can't find where PVRDisplayBufferCreate is | 20:04 |
| tmlind | not in mesa, not in blobs, not in kernel.. is that some generated name for PVRDisplayBufferCreate? | 20:05 |
| freemangordon | it should be in pvr_dri | 20:05 |
| tmlind | should | 20:05 |
| freemangordon | sec, my d4 needs some time to boot, I'll verify in a minute | 20:06 |
| tmlind | ah it is | 20:06 |
| freemangordon | no, it is not :) | 20:08 |
| freemangordon | at least not in the source code | 20:08 |
| freemangordon | tmlind: PVRDRIBufferCreate is imported by pvr_dri | 20:08 |
| freemangordon | maybe it is exported by libpvr_dri_support.so | 20:09 |
| tmlind | ok | 20:11 |
| freemangordon | oh, pvr_dri in blobs has mutex per drawable, this one is missing in chomeos mesa | 20:57 |
| freemangordon | hmm, actually it seems chromeos mesa pvr to be newer than the one in the blobs | 21:39 |
| uvos | idk where it comes from | 21:40 |
| uvos | (well the google repo) | 21:40 |
| uvos | but i mean what chome device | 21:40 |
| uvos | maybe we can get the newer blobs somewhere to examine? | 21:40 |
| uvos | they likely will be for the wrong core revision so we cant use them | 21:40 |
| uvos | bus still | 21:40 |
| uvos | looks like modern (ish) chomeos devices with pvr are MTK devices | 21:52 |
| uvos | that makes sense i dont think imtek has any customers left except mtk and sort of apple at least large scale | 21:53 |
| uvos | https://pcsupport.lenovo.com/de/en/products/laptops-and-netbooks/lenovo-chromebooks-series/lenovo-chromebook-c330/solutions/ht103653-lenovo-digital-download-recovery-service-ddrs-download-the-files-needed-to-create-a-lenovo-usb-recovery-key | 22:01 |
| uvos | ugh | 22:01 |
| uvos | (loop0p3): couldn't mount as ext2 due to feature incompatibilities | 22:16 |
| uvos | lovely | 22:17 |
| uvos | whats google doing | 22:17 |
| uvos | usr/lib/libpvr_dri_support.so.1.13.5824814: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, BuildID[xxHash]=69767606493c2acc, stripped | 22:18 |
| uvos | :( | 22:18 |
| uvos | thats pvr blobs from chomeos 93.0.4577.107 | 22:22 |
| uvos | for lenovo Hana | 22:22 |
| freemangordon | hmm, seems older | 22:23 |
| uvos | yeah | 22:23 |
| uvos | and that version was released on 2021-08-31 | 22:23 |
| uvos | according to wikipedia | 22:23 |
| uvos | https://en.wikipedia.org/wiki/Google_Chrome_version_history | 22:23 |
| uvos | so this must be what current chomeos source corrisponds to too | 22:23 |
| freemangordon | the only major difference so far I see is mutexes protecting screen and drawable structures | 22:24 |
| freemangordon | which kinda makes sense | 22:24 |
| uvos | maybe PVR GX dosent need those | 22:24 |
| uvos | for some reason | 22:24 |
| freemangordon | no multithreading? | 22:24 |
| uvos | heh no | 22:25 |
| freemangordon | :) | 22:26 |
| freemangordon | well, if it is sort of android :P | 22:26 |
| uvos | not really | 22:27 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!