| Wizzup | hm | 00:00 |
|---|---|---|
| Wizzup | I am not sure, I don't think the usual files exists | 00:00 |
| Wizzup | exist* | 00:00 |
| uvos | something like qmicli -d /dev/cdc-wdm1 --device-open-qmi --uim-get-card-status | 00:01 |
| Wizzup | yeah there is no /dev/cdc* anything | 00:01 |
| uvos | ok | 00:01 |
| uvos | well at least its there | 00:01 |
| Wizzup | https://news.ycombinator.com/item?id=29373106 | 00:01 |
| Wizzup | nobody mentions the droid 4 even | 00:01 |
| Wizzup | I don't have a HN account but it would be worth mentioning https://leste.maemo.org/Motorola_Droid_4 at least | 00:02 |
| uvos | how many other well supported devices have dts in mainline even :P | 00:02 |
| Wizzup | mhm | 00:03 |
| uvos | maybe it also goes unmentioned because this strange guy Wizzup owns all of them :P | 00:05 |
| uvos | btw did you ask around wrt recycleing? | 00:05 |
| uvos | anyhow | 00:06 |
| * uvos zzzz | 00:06 | |
| Wizzup | yes tony did | 00:08 |
| Wizzup | uvos: http://index-of.es/Magazines/Android%20Hacker's%20Handbook.pdf search for ANDROID_RAM_CONSOLE | 00:16 |
| Wizzup | seems to suggest solana should work | 00:17 |
| Wizzup | or maybe just bad luck | 00:18 |
| Wizzup | hm: | 00:46 |
| Wizzup | Broken xserver-xorg-video-omap:armhf Depends on sgx-ddk-um-libs:armhf < none @un H > Considering sgx-ddk-um-ti443x:armhf -2 as a solution to xserver-xorg-video-omap:armhf 0 Holding Back xserver-xorg-video-omap:armhf rather than change sgx-ddk-um-libs:armhf | 00:46 |
| Wizzup | ah; | 00:46 |
| Wizzup | Broken sgx-ddk-um-ti443x:armhf Conflicts on libegl1-sgx-omap4:armhf < 1.9.0.8.1.3-1+2m7.4 @ii mK > Considering libegl1-sgx-omap4:armhf -1 as a solution to sgx-ddk-um-ti443x:armhf -2 Holding Back sgx-ddk-um-ti443x:armhf rather than change libegl1-sgx-omap4:armhf | 00:46 |
| Wizzup | uvos: freemangordon: parazyd: jfyi I've been experimenting in -experimental with upgrade path | 01:50 |
| Wizzup | I'm mostly there | 01:51 |
| Wizzup | It now wants to pull mesa, sgx-ddk stuff, but it doesn't want to remove the pvr-omap4 stuff yet, but I think I can fix with parazyd tomorrow | 01:51 |
| Wizzup | if only the CI wasn't this slow I'd be able to sleep already ;D | 01:52 |
| Wizzup | I think we can also change the package priority from optional to standard or important | 01:55 |
| Wizzup | yes... :-) | 02:16 |
| Wizzup | https://dpaste.com/EJJWPTYXW | 02:16 |
| Wizzup | Priority: was the solution | 02:16 |
| Wizzup | this is just 'apt dist-upgrade' | 02:17 |
| * Wizzup apt dist-upgraded his droid3 to powervr ddk 1.17 and linux 5.15 :) | 02:33 | |
| Wizzup | no resets to far as well, fingers crossed | 02:38 |
| * Wizzup zzz | 02:43 | |
| sicelo | Wizzup: i wrote on HN. check, and suggest edits if necessary | 07:28 |
| sicelo | https://news.ycombinator.com/item?id=29377001 | 07:28 |
| sicelo | that looks like a nice Android book! thanks for linking | 07:36 |
| uvos | Wizzup: not sure what im supposed to see in that book | 11:40 |
| uvos | Wizzup: yeah many android phones have ramconsole enabled | 11:40 |
| uvos | but that dosent realy tell us anything about what moto chose to do/ configure on the xt860 | 11:40 |
| uvos | Wizzup: mind if i combine rtcom-eventlogger-plugins and rtcom-eventlogger ? | 11:41 |
| uvos | eventlogger cant really be used without its plugins | 11:41 |
| uvos | and its easier to have it in one repo | 11:41 |
| mighty17[m] | uvos tmlind using the droid4 pm script on tab2 i get the following status `d=2021-11-29|t=12:58:16|i=OFF:0,RET:0|p=-442|c=16|b=none` i had to change https://github.com/maemo-leste/droid4-pm/blob/master/scripts/openrc/droid4-pm#L160 to current_avg as max170xx_battery doesnt have power_avg | 11:42 |
| mighty17[m] | how do i check if pm is working | 11:44 |
| uvos | its not | 11:44 |
| uvos | on omap4 i would really recommend omapconf | 11:44 |
| uvos | so i=OFF:0,RET:0 means that your device dosent hit any idle states | 11:45 |
| uvos | b=none suggests nothing is blocking idle states | 11:45 |
| uvos | thes 2 together suggest the script aint working right really | 11:45 |
| uvos | check_clkctrl() in the script probubly dosent work right | 11:46 |
| uvos | there are several versions of rwmem | 11:46 |
| uvos | that behave differently | 11:46 |
| uvos | pobbly you have something the script dosent expect | 11:46 |
| uvos | but omapconf can tell you in way more detail what is going on | 11:46 |
| uvos | also the device is using 1.6W of power | 11:47 |
| uvos | thats absolutly terrible | 11:48 |
| uvos | like the d4 uses that while _loaded_ | 11:48 |
| mighty17[m] | uvos: its 4430 | 11:48 |
| mighty17[m] | uvos: its -ve | 11:49 |
| Wizzup | uvos: not sure @ rtcom, lemme wake up | 11:49 |
| mighty17[m] | oh my bad, c=16 means 1.6W? | 11:49 |
| uvos | no | 11:49 |
| uvos | your current_avg is 400mA | 11:50 |
| uvos | @3.7 ish volts presumably | 11:50 |
| uvos | so 1.6W | 11:50 |
| mighty17[m] | thats the issue, it is -ve somehow??? | 11:51 |
| mighty17[m] | not connected to any charger/usb | 11:51 |
| uvos | your shunt might be wired up backwards | 11:51 |
| uvos | i dont think the sign is important | 11:51 |
| uvos | besides the problem isent your device reporting to mutch power usage | 11:52 |
| uvos | its not ideling | 11:52 |
| mighty17[m] | both, its using a lot of power and its not idleing :( | 11:53 |
| mighty17[m] | uvos: i've gotten cases where its positive as well, but that not the point ig | 11:53 |
| mighty17[m] | I'll build omapconf and check thanks for the lead | 11:54 |
| Wizzup | uvos: btw if he changes power_avg to current_avg he should get it in W already | 11:55 |
| mighty17[m] | Wizzup: well i do not have power_avg :v | 11:56 |
| uvos | Wizzup: ? you have that backwards | 11:56 |
| uvos | and yes his pmic dosent support it | 11:56 |
| mighty17[m] | https://paste.debian.net/1221216/ | 11:56 |
| Wizzup | uvos: right | 11:56 |
| Wizzup | sicelo: ty | 12:09 |
| Wizzup | freemangordon: uvos: parazyd: I think it's time to try to figure out the components thing for our repos | 12:27 |
| Wizzup | I'm adding droid3 now, and I am not sure if we -really- want a droid3 component | 12:27 |
| Wizzup | like I am not sure if we really want a bionic component as well (even though we have it) | 12:27 |
| bencoh | I guess it's nice, but I wonder how many users we would have for those | 12:28 |
| bencoh | (not much I suppose?) | 12:28 |
| bencoh | not many* | 12:29 |
| Wizzup | well the point is mostly that I don't think we need the separate components | 12:31 |
| Wizzup | or if we do have them, we will also want some shared component(s) | 12:31 |
| parazyd | We should have a component for every device IMO. | 12:31 |
| Wizzup | like - where do the powervr packages go, now that they work for the n900,droid3,droid4,bionic and potentially more | 12:31 |
| Wizzup | can't be mapphone | 12:31 |
| Wizzup | so then what? powervr? | 12:31 |
| parazyd | And then have common components that can be shared between devices. | 12:31 |
| Wizzup | and how do those make it to the apt.sources | 12:31 |
| parazyd | Wizzup: I'd just rework the entire repos | 12:32 |
| parazyd | Just inform users to change it manually. It's not a big deal. | 12:32 |
| parazyd | And it's a one-time-thing. | 12:33 |
| parazyd | Otherwise we'll be constrained by providing some seamless update and hacking sources.list | 12:33 |
| Wizzup | I don't think we really have a way to reach out users mostly | 12:33 |
| parazyd | So in the end we won't be satisfied with the result | 12:33 |
| Wizzup | well, yes, or we just move for example powervr to main component | 12:33 |
| uvos | Wizzup: we want a hierachy | 12:33 |
| Wizzup | and then we don't need to change anything | 12:33 |
| uvos | so a device componant we want for sure | 12:34 |
| parazyd | main -> omap -> mapphone -> droid4 | 12:34 |
| parazyd | main -> omap -> n900 | 12:34 |
| parazyd | etc. | 12:34 |
| Wizzup | powervr isn't even omap specific | 12:34 |
| uvos | Wizzup: yes it is | 12:34 |
| Wizzup | I don't think so, we can easily add another arch from the ddk there | 12:35 |
| Wizzup | there is at least some exynos | 12:35 |
| Wizzup | if we put that in main now, we don't need to make these changes either | 12:35 |
| uvos | no | 12:35 |
| uvos | the um ddk needs to be the exact version used in the soc | 12:35 |
| uvos | it checks everything about the km module | 12:35 |
| Wizzup | the n900 was never supposed to be on this version | 12:35 |
| Wizzup | uvos: so, we can just add more to sgx-ddk-um ? | 12:35 |
| uvos | more blobs? | 12:36 |
| uvos | sure | 12:36 |
| Wizzup | for other tarets | 12:36 |
| uvos | sure but that dosent change that these blob packages are omap specific | 12:36 |
| Wizzup | the *files* currently in the package, yes | 12:36 |
| uvos | i think something like this: | 12:36 |
| Wizzup | but that won't have to stay that way | 12:36 |
| Wizzup | and then we would have to change the component again | 12:36 |
| uvos | leste->soc_family->soc->(optional device family)->device makes the most sense | 12:37 |
| uvos | i think | 12:37 |
| uvos | Wizzup: i not sure what you mean | 12:37 |
| uvos | Wizzup: if we add some other pvr soc, you need to add new blobs and the repo needs to build another pacakge for this soc no? | 12:38 |
| uvos | then that new soc pvr package can go into the soc componant | 12:38 |
| uvos | im not sure where the problem is | 12:38 |
| Wizzup | uvos: I am saying that (1) sgx-ddk-um can be used for things other than omap if we add more blob files (2) if we put in leste/main we don't need to f*ck around for n900 and other devices, manually having users change the components | 12:39 |
| Wizzup | so the problem is (2) | 12:39 |
| uvos | how would you have multiple versions of the same libs in the same package? | 12:39 |
| uvos | i dont follow | 12:40 |
| uvos | or do you want to have omap3-ddk-um and omap4-ddk-um and whatever-ddk-um packages in main? | 12:40 |
| Wizzup | https://github.com/maemo-leste/sgx-ddk-um/blob/master/debian/control | 12:41 |
| uvos | Wizzup: yeah so that works ok for the blobs | 12:41 |
| Wizzup | see sgx-ddk-um-$arch there? I think we can just add more, potentially non0-omap ones | 12:41 |
| Wizzup | ok | 12:42 |
| uvos | but it falls apart if its something that lots of stuff depends on, yeah you could have lots of "provides some virtual package" but really thats way more of a mess than haveing a sane tree of componants | 12:42 |
| Wizzup | can we put a package in multiple components? I guess not | 12:42 |
| Wizzup | btw I think the hierarchy is great idea | 12:43 |
| Wizzup | I am just thinking about how to make this work here and now without requiring people to mess around too much | 12:43 |
| Wizzup | for beowulf+1 we already decided we would rework it | 12:43 |
| Wizzup | (and we can decide on that structure now, too) | 12:43 |
| uvos | [12:27] <Wizzup> I'm adding droid3 now, and I am not sure if we -really- want a droid3 component | 12:44 |
| uvos | not sure what this is about then | 12:44 |
| Wizzup | I changed my mind about it | 12:44 |
| uvos | ok | 12:44 |
| Wizzup | :) | 12:44 |
| Wizzup | so it's ok to put sgx-ddk-um in leste component? | 12:48 |
| Wizzup | and also the xf86-video-omap one | 12:48 |
| uvos | yeah sure as a temporary soultion | 12:48 |
| Wizzup | and then maybe we draft up a ticket on the components on the github issue tracker | 12:48 |
| uvos | Wizzup: any idea why this https://github.com/maemo-leste/sphone/blob/75920a12fc1d13cd537ed7bed6797eac2a7f2775/src/gui/gtk-gui-thread-view.c#L67 is called with wierd parameters? | 13:20 |
| uvos | signal is connected here https://github.com/maemo-leste/sphone/blob/75920a12fc1d13cd537ed7bed6797eac2a7f2775/src/gui/gtk-gui-thread-view.c#L147 | 13:21 |
| uvos | prints: | 13:21 |
| uvos | er https://github.com/maemo-leste/sphone/blob/b058f0c5bd658e24aef4efe8d6e3f13dcb9af163/src/gui/gtk-gui-thread-view.c#L149 | 13:23 |
| uvos | prints sphone: adding window 0x5598200e15f0, text_view 0x5598200e87d0 | 13:24 |
| uvos | sphone: removeing widget 0x5598200e15f0, data 0x5598201c25c0 | 13:24 |
| uvos | no sure why data isent passed | 13:24 |
| Wizzup | will check in a few hrs | 14:14 |
| uvos | ok | 14:18 |
| uvos | in the mean time sphone now has a commtest module, its a communications backend that mocks calles and sutch | 14:19 |
| uvos | any sms you send to anyone it will echo back at you. if you call someone it will pick up after a time and then call you back once you hangup etc | 14:20 |
| uvos | any sms you send to anyone it will echo back at you. if you call someone it will pick up after a time and then call you back once you hangup etc | 14:20 |
| bencoh | fun | 14:22 |
| sicelo | call you from? :-/ | 14:22 |
| bencoh | sicelo: *x-files theme* | 14:23 |
| * sicelo doesn't know x-files, besides the name | 14:23 | |
| bencoh | oh, nevermind then, I was just joking :) | 14:24 |
| uvos | sicelo: nowhere the point is just that sphone goes though the motions of getting a call, like ringing, setting up audio routing, negotating machine state with mce, loging the event to rtcom-eventlogger, asking evoltion who the hell this is who is calling, and so on | 14:26 |
| uvos | without constanly haveing to call yourself :P | 14:26 |
| sicelo | ok | 14:31 |
| freemangordon | uvos: did you see Xorg logs of DDK 1.9 Wizzup provided? | 16:56 |
| freemangordon | it does triple-buffering ;) | 16:56 |
| uvos | yeah i see | 16:59 |
| freemangordon | so, I guess I shall teach MESA (pvr dri?) to request 3 buffers | 16:59 |
| uvos | sure | 17:00 |
| Wizzup | uvos: still want me to look at the code you linked? | 17:00 |
| uvos | Wizzup: yeah sure | 17:00 |
| uvos | Wizzup: i must not undersand something about gtk | 17:00 |
| uvos | even though i just went a different option | 17:01 |
| uvos | id like to know whats wront with that | 17:01 |
| Wizzup | is this relevant? https://stackoverflow.com/questions/52362012/callback-function-for-delete-event-signal-passes-incorrect-values-of-variables | 17:02 |
| uvos | Wizzup: no the signature of the signal is correct ofc | 17:03 |
| uvos | the pointer data points to is just trash | 17:04 |
| uvos | its not allocated on the heap | 17:04 |
| Wizzup | and it should be text-view? | 17:05 |
| uvos | it should be whatever i pass as user data yeah | 17:05 |
| uvos | makes no difference if you pass NULL there | 17:05 |
| uvos | the data pointer is still trash no NULL then | 17:05 |
| uvos | valgrind dosent complain about anything | 17:05 |
| uvos | (untill you dereferance data ofc) | 17:05 |
| uvos | so its not general heap corruption either | 17:05 |
| Wizzup | could it be that it's on the stack only? | 17:06 |
| uvos | none of this is on the stack | 17:07 |
| Wizzup | well the pointer is but the value is not yeah | 17:07 |
| uvos | yeah ofc | 17:07 |
| Wizzup | sorry, don't really know from looking at this | 17:08 |
| uvos | ok | 17:08 |
| Wizzup | should the gdkevent be a pointer? | 17:08 |
| Wizzup | yes | 17:09 |
| Wizzup | uvos: ^ | 17:09 |
| Wizzup | that's the problem | 17:09 |
| Wizzup | make that GdkEvent* event | 17:09 |
| uvos | yeah | 17:09 |
| uvos | ok yeah | 17:09 |
| Wizzup | :) | 17:09 |
| uvos | thx :) | 17:10 |
| Wizzup | np | 17:10 |
| uvos | gtk somehow type checking signals would be nice apearantly :P | 17:11 |
| Wizzup | we should just all switch to rust ;-) | 17:11 |
| uvos | hehe | 17:11 |
| Wizzup | I can't over how smooth maep is on the d3 too | 17:13 |
| uvos | yeah | 17:14 |
| uvos | its acceptable now | 17:15 |
| uvos | would be nice if someone could fix the search :) | 17:15 |
| Wizzup | hehe | 17:19 |
| uvos | Wizzup: btw would be neat if you could check how the example ui behavies with sphone events atm. | 18:00 |
| uvos | Wizzup: you can make sphone create some events using by placing this file as something.ini into ~/.sphone | 18:01 |
| uvos | [Modules] | 18:01 |
| uvos | Modules=rtconf-libprofile;test;route-pulseaudio;playback-gstreamer;sphone-mce;comm-ofono;manager;external-exec;contacts-evolution;comm-error-gtk;contacts-ui-exec;store-rtcom;commtest | 18:01 |
| uvos | and then call/message someone using the commtest backend | 18:01 |
| Wizzup | ok, I'd like to do it after we have 5.15 for -devel and droid3 stuff in -devel, and I did a bit of TP stuff... | 18:03 |
| Wizzup | so maybe not tonight | 18:03 |
| uvos | Wizzup: no rush | 18:03 |
| uvos | btw | 18:04 |
| uvos | what happend to cloudgps? | 18:05 |
| Wizzup | also, if you could help, I would appreciate it if you can find the modem gpio setup or the i2c setup in the stock-dts.bin for x860, but I fear it might be non trivial | 18:05 |
| Wizzup | hm, what about it? | 18:05 |
| uvos | i apears to be missing in repo | 18:05 |
| Wizzup | really? hm | 18:05 |
| uvos | yeah i dont have it installed i cant apt install cloudgps and its not in ham either | 18:06 |
| uvos | (i had to remove it for the ddk upgrade) | 18:06 |
| Wizzup | it looks like it's not in the repo | 18:06 |
| Wizzup | I'll look at that in a bit | 18:07 |
| Wizzup | btw now you can apt dist-upgrade and it should just work | 18:07 |
| Wizzup | in case you missed that | 18:07 |
| uvos | yeah i did read taht | 18:07 |
| Wizzup | ok | 18:07 |
| uvos | but i had allready upgraded all devices manually | 18:07 |
| uvos | i can take a look at the dtb sure | 18:08 |
| uvos | that stuff is not in the dtb tho | 18:08 |
| uvos | its in the gpiomap or what its called | 18:08 |
| Wizzup | ah, right | 18:09 |
| Wizzup | you emailed me that script | 18:10 |
| Wizzup | uvos: cloudgps is avail in repos now | 18:28 |
| freemangordon | uvos: implementing 3-buffering was a matter of implementing SwapLimitValidate and calling DRI2SwapLimit | 19:13 |
| freemangordon | FPS increase to 53, which is sill not ok, but better than 40 | 19:14 |
| freemangordon | I am going to push that, but please, have a look when you have some time | 19:14 |
| bencoh | 3-buffering gives beter fps? | 19:14 |
| freemangordon | sure | 19:14 |
| bencoh | better* | 19:14 |
| freemangordon | that's the point of it | 19:14 |
| bencoh | is that because otherwise it waits for the frame to be pushed to screen before starting to render another one? | 19:15 |
| freemangordon | yes | 19:15 |
| bencoh | so basically we have a buffer for display and another one for rendering? | 19:16 |
| freemangordon | one to display, one waiting for vsync and one for rendering | 19:17 |
| bencoh | vsync from gpu you mean? | 19:17 |
| freemangordon | vsync as 'vertical blank' I mean :) | 19:17 |
| freemangordon | or 'vertical blanking period' | 19:18 |
| bencoh | yeah but ... | 19:18 |
| freemangordon | hmm? | 19:18 |
| bencoh | vertical blanking sync should be the "display" sync | 19:18 |
| bencoh | hence me asking if the one you referred to was from gpu | 19:18 |
| freemangordon | yes, 'display' sync | 19:19 |
| freemangordon | GPU has no idea of 'vsync' | 19:19 |
| freemangordon | bencoh: if we want tear-free, then we cannot render on the front buffer, obviously | 19:19 |
| freemangordon | in the same time, when back buffer is ready to be displayed, we wait for vblank | 19:20 |
| freemangordon | the time we wait for vblank, is 'wasted' GPU time, as there is not free buffer GPU can render on | 19:21 |
| freemangordon | thus the 3rd buffer | 19:21 |
| freemangordon | though I was hoping to hit at least 60fps, but seems there is some issue in omapdrm with page flips | 19:22 |
| freemangordon | it should not take 6 ms to queue a flip | 19:22 |
| freemangordon | tmlind_: ^^^ any idea? | 19:22 |
| uvos | that only happens when the render time is greater than the display vblank period ofc | 19:23 |
| freemangordon | yeah | 19:23 |
| uvos | btw can we drop to double buffering when vblank_mode is 0? | 19:23 |
| uvos | ie no vsync? | 19:23 |
| freemangordon | not sure | 19:24 |
| uvos | ok its not a big deal | 19:24 |
| ruleh | does it even react to vblank_mode ? | 19:24 |
| uvos | but some games might want this | 19:24 |
| uvos | ruleh: we control the bit that would have to react | 19:25 |
| freemangordon | please, whoever might have an idea: | 19:26 |
| freemangordon | https://github.com/maemo-leste/xf86-video-omap/commit/8e94994eea24e6797e495d47c9ac8ec699608c0a | 19:26 |
| freemangordon | maybe fps is low because I don't implement that correctly | 19:26 |
| ruleh | I mean at least es2gears didn't seem to care what vblank_mode was set to. I would have expected it to stay at 60 with vblank_mode=1 | 19:27 |
| uvos | vblank_mode=1 | 19:28 |
| uvos | is tripple bufferein iirc | 19:28 |
| uvos | you want mode=2 | 19:28 |
| uvos | (speaking of gallium3d drivers here) | 19:28 |
| ruleh | it still goes to 75 with it set to 2 | 19:29 |
| uvos | on what | 19:29 |
| ruleh | (same as 0 and 1) | 19:29 |
| uvos | it works fine on radionsi | 19:29 |
| ruleh | pvr on droid4 | 19:29 |
| uvos | yeah sure its not implemented there | 19:30 |
| uvos | it dosent do anything | 19:30 |
| ruleh | ah ok | 19:30 |
| uvos | btw i 75fps looks like its less than the d4s maximum refresh rate | 19:31 |
| uvos | that seams to be about 80 | 19:31 |
| uvos | (d4 is really wierd what this is concerned it dosent have a refresh rate as sutch) | 19:32 |
| ruleh | on another droid running arch I get >120 | 19:32 |
| uvos | yeah thats about normal for wayland | 19:33 |
| ruleh | on xorg :) | 19:33 |
| uvos | no composing? | 19:33 |
| ruleh | none | 19:33 |
| uvos | right | 19:34 |
| uvos | composing causes an extra copy | 19:34 |
| uvos | you can suspend it in hildon with ctrl shift n btw | 19:34 |
| ruleh | es2gears without composing on leste goes to 145 :D | 19:35 |
| freemangordon | ruleh: ddk 1.9? | 19:36 |
| ruleh | 1.17 | 19:36 |
| uvos | no way | 19:36 |
| uvos | ddk1.9 manages 30fps on a good day :P | 19:36 |
| uvos | with no composing | 19:36 |
| uvos | Wizzup: or freemangordon can we build this for experiamental then: https://github.com/maemo-leste/xf86-video-omap/tree/maemo/beowulf-experimental | 19:38 |
| uvos | i dont fancy building it on d4 | 19:38 |
| freemangordon | ok | 19:38 |
| freemangordon | please, do changelog and tag | 19:39 |
| freemangordon | ttyl | 19:39 |
| Wizzup | uvos: I'll do it after dinner | 19:39 |
| uvos | Wizzup: thank you :) | 19:39 |
| ruleh | is there a way to limit the fps of hildo-desktop? | 19:40 |
| uvos | not atm | 19:40 |
| uvos | but yeah | 19:40 |
| uvos | we should add | 19:40 |
| Wizzup | why would we want to, just curious? | 19:40 |
| uvos | Wizzup: battery life ofc | 19:41 |
| uvos | esp. on more powerfull hardware | 19:41 |
| Wizzup | right | 19:41 |
| Wizzup | I mean if the gpu is clocked high all the time when it's active, does it matter? | 19:41 |
| uvos | no need to spin up 32cores and 4 gpus on some wizbang 2022 soc to render hildon at 500fps | 19:42 |
| uvos | yeah | 19:42 |
| uvos | Wizzup: no on our current hardware it dosent matter mutch since pm is broken while the display is on | 19:44 |
| uvos | ofc the cpu gets to sleep a bit more if you limit it lower | 19:44 |
| uvos | but thats not the point | 19:44 |
| uvos | also the pinephone also exists | 19:44 |
| Wizzup | right | 19:44 |
| Wizzup | and a lot more hw to come :p | 19:44 |
| freemangordon | I think it doesn't make sense | 19:45 |
| freemangordon | as h-d is vsync-ed either ways | 19:45 |
| uvos | sure it dose. even with vsync | 19:45 |
| uvos | you can have 240hz pannels these days | 19:45 |
| freemangordon | well, yeah | 19:46 |
| uvos | really you want the user to be able to choose 120, 60 or even 30 fps caps | 19:46 |
| uvos | depending on his prioritys | 19:46 |
| ruleh | is the fps counter of CLUTTER_SHOW_FPS always accurate? | 19:49 |
| freemangordon | should be | 19:50 |
| uvos | its at least wrong in the sense that sometimes pushing the frame to the pannel fails on d4 | 19:51 |
| uvos | which is something you can see as stuttering thats absent on bionic for instance. | 19:51 |
| ruleh | hmm... it shows up to 80fps when scrolling but it certainly doesn't feel like 80 | 19:53 |
| freemangordon | on d4 with ddk 1.17? | 19:55 |
| ruleh | yeah | 19:55 |
| freemangordon | hmm, how's that possible? | 19:55 |
| freemangordon | I can't get anything above 40 (with double-buffering) | 19:55 |
| ruleh | I think it is something in xf86-video-omap | 19:56 |
| freemangordon | you use the one in experimental? | 19:56 |
| ruleh | no | 19:56 |
| freemangordon | ah | 19:56 |
| ruleh | well kinda | 19:56 |
| freemangordon | don't understand | 19:56 |
| ruleh | I use af94325a24bc3a3f4f8ba89ff9cbbf2cd39d6652 with some patches | 19:57 |
| uvos | *** FPS: 91 *** | 19:57 |
| uvos | i get 91 | 19:57 |
| uvos | (just checked) | 19:57 |
| uvos | so hmm | 19:57 |
| uvos | i AM on regular experiamental | 19:57 |
| freemangordon | hmm, hmmm | 19:57 |
| uvos | not sure why that is impossible freemangordon | 19:57 |
| uvos | if it renders in less than frametime | 19:57 |
| freemangordon | sure, but here it renders 2 times slower | 19:58 |
| uvos | freemangordon: oh if i scrol to a hildon home screen with lots of icons | 19:58 |
| uvos | it drops abrouply to 40 | 19:58 |
| uvos | this seams to check out | 19:58 |
| freemangordon | my desktop is empty | 19:58 |
| uvos | hmm | 19:58 |
| uvos | thats wierd | 19:58 |
| freemangordon | yeah | 19:58 |
| freemangordon | what I am missing? | 19:58 |
| uvos | what do you get with es2gears showing? | 19:59 |
| freemangordon | in h-d? | 20:00 |
| uvos | to eliminate differences in hildon home | 20:00 |
| uvos | yeah | 20:00 |
| uvos | run es2gears in forground | 20:00 |
| freemangordon | sec, to disable 3-buffer | 20:00 |
| uvos | and record hildon fps | 20:00 |
| freemangordon | hmm, wait | 20:02 |
| freemangordon | I am hittin 66 now | 20:02 |
| freemangordon | with 3-buffer that is | 20:02 |
| freemangordon | uvos: how do you start h-d? | 20:02 |
| uvos | about the same here with stock | 20:02 |
| uvos | freemangordon: for this expierament just hildon-desktop in ssh | 20:03 |
| freemangordon | ok | 20:03 |
| freemangordon | hmm, just hit 83 fps | 20:03 |
| freemangordon | this is crazy :( | 20:03 |
| freemangordon | 268 frames in 5.0 seconds = 53.461 FPS | 20:04 |
| ruleh | meanwhile I get max 39fps with xorg-video-omap 0.5.0+2m7.4 when desktop scrolling | 20:04 |
| uvos | ruleh: empty desktop? | 20:04 |
| ruleh | yeah | 20:04 |
| uvos | have any windows open? | 20:05 |
| ruleh | gears is happy at 69 though | 20:05 |
| uvos | if i have gears open i get max 40 fps on desktop | 20:05 |
| uvos | that makes sense ofc | 20:05 |
| uvos | gpu is busy | 20:05 |
| freemangordon | I get 53 fith 3-buffer | 20:05 |
| freemangordon | lemme disable it | 20:05 |
| ruleh | the 39 is when nothing else is running | 20:05 |
| uvos | wierd | 20:05 |
| freemangordon | yes | 20:06 |
| ruleh | interestingly gears makes hildon fps jump up to 43 | 20:06 |
| uvos | so i get 90 on empty desktop 40 on full desktop of with gears or firefox-esr open, gears showing makes it 60 fps in hildon and 70 in gears own counter | 20:07 |
| uvos | s/of/or | 20:07 |
| freemangordon | hmm, seems this fps I get is with driver from -experimentl | 20:08 |
| freemangordon | I mean - I just upgraded | 20:08 |
| freemangordon | but not with the one I complie here | 20:08 |
| uvos | optimiziation flags different? | 20:09 |
| freemangordon | in ddx? | 20:09 |
| freemangordon | how's that supposed to matter? | 20:09 |
| uvos | in mesa, but really mesa should be doing no work | 20:09 |
| uvos | freemangordon: no idea grasping at straws | 20:09 |
| freemangordon | yeah | 20:09 |
| uvos | is your device using the same ti-ddk-um commit? | 20:10 |
| uvos | -next vs latest stable ddk release? | 20:10 |
| freemangordon | hmm, I just restarted Xorg and fps dropped to 40 | 20:11 |
| freemangordon | wth? | 20:11 |
| uvos | hmm should scrolling on hildon-desktop not also depend on how often xorg desicdes to update input events | 20:13 |
| freemangordon | sure | 20:13 |
| uvos | so a better test would be to change transition.ini | 20:14 |
| uvos | to make some animation take really long | 20:14 |
| uvos | and base fps off of the | 20:14 |
| uvos | animation | 20:14 |
| uvos | [launcher_in] | 20:16 |
| uvos | duration = 2500 | 20:16 |
| uvos | *** FPS: 55 *** | 20:17 |
| freemangordon | with 3-buffer fps is 53 | 20:17 |
| freemangordon | hmm, I am doing something wrong | 20:18 |
| freemangordon | but don't understand what | 20:18 |
| freemangordon | uvos: with 2-buffer fps is ~30 | 20:19 |
| ruleh | hmm restarting xorg disconnects wifi. is it supposed to do that? | 20:20 |
| uvos | freemangordon: wait a minute | 20:20 |
| freemangordon | ruleh: no | 20:20 |
| ruleh | is there a way to find out why it's doing that? | 20:22 |
| ruleh | hmm it didn't do it this time, maybe I messed something up before | 20:23 |
| uvos | hm ok | 20:24 |
| uvos | wasent it | 20:24 |
| uvos | (i had a powervr.ini) | 20:24 |
| freemangordon | oh | 20:25 |
| freemangordon | me too | 20:25 |
| freemangordon | didn;t chage anything | 20:25 |
| uvos | yeah same here | 20:26 |
| freemangordon | but I'll reboot, just in case | 20:26 |
| uvos | really no idea why yours underperformes | 20:26 |
| freemangordon | what is weird is that it was hitting 83 fps | 20:26 |
| freemangordon | until I restarted Xorg | 20:26 |
| uvos | but i have to second ruleh here in that it dosent look like 80fps | 20:26 |
| freemangordon | I would say omapdrm misbehaves | 20:27 |
| uvos | you can also clearly see tearing btw | 20:27 |
| freemangordon | mhm | 20:28 |
| freemangordon | which is impossible in theory :D | 20:28 |
| ruleh | yeah it tears quite a bit | 20:28 |
| freemangordon | Wizzup: is it safe to dist-upgrade n900? | 20:41 |
| Wizzup | freemangordon: no | 20:55 |
| freemangordon | ok | 20:55 |
| Wizzup | freemangordon: well, wait, on what repos | 20:55 |
| freemangordon | experimental :) | 20:55 |
| Wizzup | if you have your own kernel and u-boot it should be mostly | 20:55 |
| freemangordon | ok | 20:55 |
| Wizzup | (if I dist upgrade mine it will break since it will downgrade droid4-linux on my n900 and make it not boot) | 20:55 |
| Wizzup | you should be ok | 20:55 |
| freemangordon | ok | 20:56 |
| Wizzup | uvos: shall I build it now? | 20:57 |
| uvos | Wizzup: not sure anymore | 20:57 |
| uvos | Wizzup: its behavior dosent add up | 20:58 |
| freemangordon | hmm, it seems something is tottaly wring in DDX in regards to page flip | 21:00 |
| freemangordon | *wrong | 21:00 |
| freemangordon | enabling 3-buffer on n900 increased fps to 25, from 21 | 21:01 |
| freemangordon | hmm, maybe tearing is because I invalidate framebuffer too often | 21:16 |
| ruleh | do you mean with drmmode_flush_scanout? | 21:19 |
| freemangordon | mhm | 21:20 |
| ruleh | I removed all those calls and it still tears | 21:21 |
| freemangordon | on d4? | 21:21 |
| ruleh | yeah | 21:21 |
| freemangordon | but, it does not update without that whn no compositing | 21:21 |
| ruleh | also reverted " use drmModeDirtyFB instead of drmModePageFlip to flush scanout changes" and added dirtyfb to the block handler or whatever that was called | 21:22 |
| freemangordon | how that helps? | 21:22 |
| ruleh | it makes the display update correctly but doesn't fix the tearing | 21:23 |
| freemangordon | why drmModeDirtyFB is not ok? | 21:23 |
| ruleh | since I called it from OMAPBlockHandler i felt that I didn't need it somewhere else | 21:24 |
| ruleh | It also seemed a bit more reliable there in case dri2 is disabled | 21:25 |
| freemangordon | hmm | 21:25 |
| ruleh | I think modesetting also calls it from a similar place | 21:27 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!