| lel | IMbackK synchronize a pull request: https://github.com/maemo-leste/hildon-status-menu/pull/3 (Add support for StatusNotifierItems) | 00:22 |
|---|---|---|
| uvos | whats acctually neat | 00:24 |
| uvos | is that even the context menus are simply defined as xml | 00:24 |
| uvos | so you could even have networkmanager-applet open a dialog that looks just like the icd2 one | 00:24 |
| uvos | generally formating the StatusNotifierItem menu into a hildon dialog should not be too mutch work. | 00:25 |
| uvos | same with cantata media controlls etc | 00:25 |
| lel | IMbackK synchronize a pull request: https://github.com/maemo-leste/hildon-status-menu/pull/3 (Add support for StatusNotifierItems) | 00:37 |
| freemangordon | Wizzup: where shall I push latest omapdrm/pvr patches? | 09:36 |
| freemangordon | ah, maybe here https://github.com/maemo-leste/droid4-linux/tree/droid4-pending-pvr-omapdrm-v5.15 | 09:46 |
| freemangordon | Wizzup: parazyd: pushed | 09:52 |
| freemangordon | tmlind: I send new versions of omapdrm/prv patches, I hope those are final | 09:53 |
| freemangordon | maybe you would like to use them to replace the old version and force-push maybe, dunno | 09:53 |
| tmlind | freemangordon: let's revert the old ones and reapply so it stays pullable | 10:12 |
| freemangordon | ok, I guess then you can just pull https://github.com/maemo-leste/droid4-linux/tree/droid4-pending-pvr-omapdrm-v5.15 | 10:44 |
| freemangordon | tmlind: also, it seems there is some issues with caching of BOs. Even without TILER and SGX rendering (so, pure 2D on non-rotated scanouts) I see wrongly rendered parts when doing x11perf | 10:46 |
| freemangordon | I wonder if I shall map/unmap on every start/end CPU access, but that seems like an overkill to me | 10:47 |
| freemangordon | I think WL has the same issue, at least by judging on your description | 10:47 |
| tmlind | freemangordon: sure i can pull, will need to catch train so not sure if i can do that before sunday night | 10:59 |
| tmlind | freemangordon: i'll also continue rewriting the interrupt handler stuff to get rid of the remaining ocp code as that probably won't work at all for other architectures | 11:00 |
| tmlind | yeah for sure there's some need to flush stuff somewhere, maybe give the patch i posted last week a try. if that helps, mabye we can optimize it some more | 11:01 |
| tmlind | that was the omapdrm-flush-on-pin-unpin.patch | 11:02 |
| tmlind | freemangordon: also, are you also seeing the wrongly rendered parts on n900, or only on d4? | 11:03 |
| Wizzup | freemangordon: ok, do we need anything else or can things somehow 'work' ? | 11:31 |
| freemangordon | tmlind: I think I see on n900 too | 11:39 |
| freemangordon | Wizzup: I don;t hink so | 11:39 |
| freemangordon | *think | 11:39 |
| freemangordon | but, we shall not enable PVR EXA as of now | 11:39 |
| freemangordon | as it gives rendering artifacts | 11:39 |
| freemangordon | some cache issues again | 11:39 |
| freemangordon | I'll investigate during the weekend | 11:40 |
| Wizzup | ok, so we can build latest kernel with ddk 1.17, mesa, and the ddx | 11:40 |
| freemangordon | yes | 11:40 |
| Wizzup | and I will have to work on the headers split, getting it from the kernel package somehow | 11:40 |
| freemangordon | yes | 11:40 |
| Wizzup | I am still not sure if it that makes more sense but ok | 11:40 |
| Wizzup | np | 11:40 |
| Wizzup | not enabling exa is probably the default in the config? | 11:41 |
| freemangordon | Wizzup: no | 11:41 |
| uvos | if you can see it on n900 at all but less its probubly the same as on d4 but with a hdmi display | 11:42 |
| uvos | on d4 its really obvious because sometimes the last frame that stays is wrong | 11:42 |
| uvos | if you plug in hdmi you can still see the errors flickering on animation, but it dosent stay | 11:43 |
| freemangordon | this is different issue | 11:43 |
| uvos | ok | 11:43 |
| freemangordon | 'flickering' is what I see on n900 | 11:43 |
| uvos | not sure its a differetn issue | 11:43 |
| uvos | if its in dss | 11:44 |
| uvos | the d4 just displays it differently on dsi because the dsiplay stops refeshing during the flicker | 11:44 |
| freemangordon | yeah | 11:44 |
| uvos | so whats a flicker on n900 and d4 hdmi becomse a constant black/wrong rectangle on d4 dsi | 11:44 |
| Wizzup | but fmg says it only happens with exa I think? | 11:45 |
| uvos | is that so fmg? | 11:45 |
| uvos | it happens on wayland too | 11:45 |
| uvos | and ddk1.9 ofc | 11:45 |
| freemangordon | no, it happens without exa too | 11:46 |
| freemangordon | sec (phone call) | 11:46 |
| uvos | ok so that would suggest dss is broken as the only difference between refreshes on d4 hdmi is that dss re reads the same buffer again. | 11:47 |
| freemangordon | so: | 11:47 |
| uvos | so that would suggest caheing | 11:47 |
| freemangordon | we have 3 different issues: | 11:47 |
| freemangordon | 1. d4 does not update correctly because of manual update dusplay. this is fixed by flushing after scanout has been changed | 11:48 |
| freemangordon | 2. n900 (and I guess d4 with hdmi) flickers - on n900 what flickers is the right 1/3 of the display. We have no clue what is this but tmlind has a patch for us to test | 11:49 |
| freemangordon | 3. with PVR EXA we have rendering artefacts when hildon-desktop runs. THis is something I sahll take care of | 11:50 |
| scops | hmm is it planed to support the n9 more actively? | 11:50 |
| scops | (i got one in the meantime) | 11:50 |
| uvos | we would be happy if someone picked it up | 11:51 |
| freemangordon | I guess yes, once we have SGX running | 11:51 |
| uvos | but atm no one works on it | 11:51 |
| freemangordon | and yes, ut needs someone to work on it | 11:51 |
| freemangordon | I plan to work on n950 | 11:51 |
| freemangordon | but it is different and also have no idea when I will start | 11:51 |
| freemangordon | too much on the plate already | 11:51 |
| scops | if there is an image sometime for testing... i'm here ;) | 11:52 |
| Wizzup | we had a n9 image a long time ago I think contributed by dderby | 11:52 |
| freemangordon | Wizzup: so, I think tmlind and uvos are talking about issue 2 | 11:52 |
| uvos | there was a bug that it dident boot some time ago i think | 11:52 |
| Wizzup | but we are trying to focus on a few devices and support those well before expanding to many more, but we'd love for others to take that up | 11:52 |
| Wizzup | freemangordon: right | 11:52 |
| uvos | freemangordon: yeah thats the only one that shows in sway | 11:52 |
| freemangordon | but, only when hdmi is connected, right? | 11:53 |
| uvos | no allways | 11:53 |
| freemangordon | ah | 11:53 |
| uvos | with hdmi its _harder_ to see | 11:53 |
| uvos | but it happens | 11:53 |
| uvos | this is why i suspect dss | 11:53 |
| freemangordon | well, I see no such flickering on d4 with omap-video | 11:53 |
| uvos | because when the display is merly re-refeshed (with same image) | 11:53 |
| uvos | freemangordon: even with slow or hevly loaded sgx? | 11:53 |
| freemangordon | yes | 11:54 |
| uvos | ok | 11:54 |
| uvos | wierd | 11:54 |
| freemangordon | I can run glmark2 within h-d and it will render corecctly (without pvr exa) | 11:54 |
| freemangordon | actually it renders correctly with pvr exa too | 11:54 |
| uvos | its mostly 2d on 3d engine stuff that shows it for me | 11:55 |
| uvos | ie sway windows | 11:55 |
| freemangordon | but some other things are rendered incorrectly (styatus menu for example) | 11:55 |
| uvos | ok | 11:55 |
| uvos | neat about you having exa working allready :) | 11:55 |
| uvos | well partally anyways | 11:55 |
| freemangordon | *almost* working :) | 11:55 |
| freemangordon | yeah | 11:55 |
| freemangordon | I need to fix CPU/GPU sync and to RE the composite part | 11:56 |
| freemangordon | ttyl, luch | 11:56 |
| tmlind | freemangordon: i agree on the 3 different issues you listed, except for issue 2 my test patch only hides the d4 command mode lcd issue so it too shows as flicker most likely | 12:01 |
| freemangordon | tmlind: ah, I see | 12:01 |
| tmlind | so my patch is likely wrong, just a workaround to force refresh the d4 command mode lcd, it does nothing on n900 or on hdmi | 12:02 |
| tmlind | afaik the flicker only shows with pvr, so likely it needs to flush somewhere | 12:04 |
| tmlind | or has anybody seen it without pvr in play? | 12:04 |
| uvos | freemangordon: claims so above lets | 12:05 |
| uvos | wait until he is back | 12:05 |
| tmlind | yeah gotta go soon, connection will be spotty over the weekend | 12:05 |
| uvos | "tmlind: also, it seems there is some issues with caching of BOs. Even without TILER and SGX rendering (so, pure 2D on non-rotated scanouts) I see wrongly rendered parts when doing x11perf" <--- unless he was using the pvr exa moudle that dosent touch pvr at all | 12:06 |
| tmlind | interesting, that test case might be easiest to trace | 12:07 |
| uvos | actually let me thy this on ddk1.9 without hildon | 12:07 |
| uvos | that uses the cpu to render too | 12:08 |
| tmlind | ok | 12:08 |
| freemangordon | yes, this doesn't involve SGX | 12:17 |
| freemangordon | it is like reading from a WC memory reads stale data | 12:17 |
| freemangordon | I don't know how's that possible | 12:17 |
| uvos | honestly x11perf is so flickery i cant tell if its wrong | 12:18 |
| uvos | i blacklisted pvr module on an otherwise usual leste 5.11 kernel | 12:18 |
| uvos | freemangordon: what test did you use | 12:18 |
| freemangordon | x11perf -copywinwin500 | 12:18 |
| uvos | indeed | 12:19 |
| uvos | its wrong on modesetting with no pvr and noAcell | 12:19 |
| freemangordon | mhm | 12:20 |
| uvos | it shows the top right missing rendering very well | 12:20 |
| freemangordon | yes | 12:20 |
| uvos | great find | 12:21 |
| freemangordon | lemme see if it happens on TILER BO | 12:21 |
| freemangordon | bottom-left part is affected | 12:22 |
| uvos | same thing on 5.14 sway droid 4 (on xorg noaccel modesetting) | 12:22 |
| freemangordon | also, this https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/omapdrm/omap_drv.c#L488 worries me | 12:24 |
| freemangordon | tmlind: have a look at p, li { white-space: pre-wrap; } d6f544f6b | 12:26 |
| freemangordon | "Now that the driver supports synchronization through fences..." | 12:27 |
| freemangordon | searching for "fence" in the driver doesn't result in anything useful | 12:31 |
| freemangordon | uvos: ok, but what potentially is not being flushed with CPU access only? | 13:09 |
| freemangordon | not enough pages being mapped should result in segfault, no? | 13:20 |
| freemangordon | ok, the same x11perf mis-rendering happens on n900 with modesetting and no acceleration | 14:06 |
| freemangordon | so, something is wrong with mmap()-ed memory. or with DSS | 14:06 |
| uvos | freemangordon: cpus cache would come to mind, but this allso seams to happen with pvr rendering into omapdrm buffers, so that leaves dss missbehaving really unless im missing something. | 14:31 |
| Wizzup | scops: are you up for doing development and testing, or just testing? | 14:32 |
| freemangordon | uvos: but, we have the issue when pvr renders too | 14:33 |
| scops | testing ... i dont have the time to development atm | 14:33 |
| scops | s/to/for | 14:33 |
| uvos | freemangordon: right thats why it leaves dss misbehaving | 14:34 |
| freemangordon | ah, you mean "dss behaves correctly" | 14:34 |
| freemangordon | yeah, agree | 14:34 |
| freemangordon | it is something with cache coherency I think | 14:34 |
| freemangordon | but I lack the details | 14:35 |
| freemangordon | gnome crashed :( | 14:36 |
| mighty17[m] | can we get openpvrsgx with 5.15 full release instead of the rc? (i'd be happy to do it myself as well but the last commit/MR from the tree is confusing) | 14:41 |
| mighty17[m] | also #2 can we trouble TI to get info about ducati to make it run in mainline? | 14:41 |
| uvos | https://github.com/tmlind/linux_openpvrsgx/tree/droid4-pending-pvr-omapdrm-v5.15 | 14:42 |
| uvos | unlikely | 14:42 |
| freemangordon | mighty17[m]: hmm, we are already on 5.15.2 | 14:42 |
| freemangordon | mighty17[m]: re 2 - feel free to do it, if you know who shall be pestered :) | 14:42 |
| mighty17[m] | uvos: Ah that's tmlind's tree, always forget to check it 😅 | 14:43 |
| mighty17[m] | freemangordon: I was going to make an account on their website but they need my zip code smh | 14:44 |
| uvos | mighty17[m]: i would pretty much just track droid4-pending-* with an omap4 device | 14:44 |
| uvos | there isent a reason not to | 14:44 |
| mighty17[m] | I keep forgetting that my bad | 14:46 |
| mighty17[m] | Will probably package it in pmos as well then | 14:46 |
| mighty17[m] | Esp coz tab uses 4430 like d4 | 14:47 |
| mighty17[m] | freemangordon: e2e.ti.com? | 14:47 |
| freemangordon | noidea | 14:47 |
| sicelo | mighty17[m]: i don't think you'll get anywhere with TI. if you want to test the waters, maybe ask in libera/#linux-ti | 14:56 |
| mighty17[m] | Ah I can ask in linux-omap mailing list as well? But I assume only tmlind is active | 14:57 |
| freemangordon | linux-omap ML is active | 14:58 |
| freemangordon | but this is in no way related to TI, AFAIK | 14:58 |
| mighty17[m] | Who else to pester than for ducati, it's TI who kept it a blob | 14:59 |
| uvos | the firmware for the dsp is a blob | 15:03 |
| uvos | but i mean thats fairly irelivant | 15:03 |
| uvos | the kernel space drvier is in ti's tree | 15:03 |
| uvos | the android userspace is a blob too | 15:04 |
| uvos | but i think there were sources for the gstreamer plugin? not sure tho | 15:04 |
| uvos | what parts are you missing? | 15:04 |
| uvos | also what are you trying to achive here | 15:05 |
| uvos | video playback or encoding and the alogrithums needed for dumb camera sensors? | 15:06 |
| freemangordon | we have gst-dsp for C64x | 15:06 |
| freemangordon | but, we lack drivers | 15:06 |
| uvos | sure but not sure what he wants from ti | 15:07 |
| freemangordon | though, I had that working with 4.9, iirc | 15:07 |
| uvos | they have drivers | 15:07 |
| freemangordon | yeah | 15:07 |
| uvos | they are just not in mainline | 15:07 |
| mighty17[m] | uvos: Preferably video playback, but in android that fw blob is needed | 15:08 |
| mighty17[m] | I thought it was the same case for mainline | 15:08 |
| uvos | the android userspace blob is just a translator for the kernel interfaces to the android hal | 15:08 |
| uvos | its not realy relevant | 15:08 |
| freemangordon | isn't that supported by remoteproc? | 15:09 |
| mighty17[m] | uvos: Ooooh didn't know that | 15:09 |
| uvos | freemangordon: on android vendors write closed source accelerator plugins for its hal, im not sure what kernel interfaces the motorola one ends up using. | 15:10 |
| uvos | yes it should use remoteproc if its sane | 15:10 |
| freemangordon | uvos: yes, it is the same on fremantle (closed source gst plugins), but interface was REed and gst-dsp came out | 15:11 |
| mighty17[m] | <freemangordon> "though, I had that working with..." <- So basically search ti's git for commits, add to my tree and magic? | 15:18 |
| Wizzup | scops: ok | 15:18 |
| uvos | i think magic is farily rare in this particular universe | 15:19 |
| Wizzup | hehehe | 15:20 |
| freemangordon | mighty17[m]: yeah, you need diskworld for that :) | 15:20 |
| freemangordon | is ducati C64x? | 15:20 |
| uvos | yes no | 15:20 |
| uvos | ducti is two extra arm cores | 15:21 |
| uvos | one has c64x attached | 15:21 |
| freemangordon | mighty17[m]: https://github.com/pali/linux-n900/tree/v4.9-n900/drivers/staging/tidspbridge | 15:24 |
| freemangordon | if this can be of any use for you | 15:24 |
| freemangordon | it is ported to use iommu api | 15:24 |
| freemangordon | keep in mind this wants COFF forma for firmware | 15:25 |
| freemangordon | if your firmware is in ELF, you should use remoteproc | 15:25 |
| uvos | on android d4 this is ab different iirc | 15:26 |
| uvos | they upload a firmware that runs on the m3 core | 15:26 |
| uvos | that uploads the fw for the dsp | 15:26 |
| uvos | not sure if you have to do this | 15:26 |
| mighty17[m] | <uvos> "they upload a firmware that runs..." <- Yeah, even omapzoom has info about android | 15:45 |
| mighty17[m] | But for linux there isn't much | 15:45 |
| mighty17[m] | <freemangordon> "if this can be of any use for..." <- Unsure about this, afaik it does use remoteproc on Android | 15:46 |
| freemangordon | ugh | 20:50 |
| freemangordon | I started Xephyr on my pc and executed x11perf on it and we have exactly the same artefacts | 20:51 |
| freemangordon | Xephyr is 544x960 | 20:54 |
| freemangordon | uvos: any clue why "end current task" button is missing in powerkey menu? | 22:31 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!