| uvos | dsc_: well depends on the hardware | 00:11 |
|---|---|---|
| dsc_ | pretty sure QML will run better than embedding a QWebEngineView (chromium) | 00:13 |
| dsc_ | im doing some UIs currently, think ill go with QML right now | 00:13 |
| dsc_ | for practical reasons :P | 00:13 |
| dsc_ | we'll have to see how well it performs on hardware | 00:13 |
| dsc_ | I think it'll be fine tbh | 00:14 |
| dsc_ | I'm not doing crazy shit | 00:14 |
| uvos | Currently qml perfoms farily bad on droid 4 | 00:14 |
| freemangordon | YAY!!! | 00:14 |
| freemangordon | it works :) | 00:14 |
| uvos | because it renders in gl and the cpu ends up copying the buffer to the display | 00:15 |
| dsc_ | uvos: But ... QWebEngineView worse ;) ? | 00:15 |
| uvos | freemangordon: what works? | 00:15 |
| dsc_ | ah ok | 00:15 |
| freemangordon | landscape 2D PVR accelleration :) | 00:15 |
| uvos | dsc_: sure probubly, but a qwidgets app will work mutch better | 00:15 |
| uvos | freemangordon: YAY!!! :P | 00:15 |
| uvos | freemangordon: so everything works now? | 00:15 |
| freemangordon | noo | 00:15 |
| uvos | freemangordon: or what remains? | 00:15 |
| freemangordon | but we are one step closer | 00:15 |
| uvos | ok | 00:15 |
| freemangordon | well, I had to patch both omapdrm and pvr driver | 00:16 |
| dsc_ | uvos: for sure, but I'm time limited I suppose. But it is easy to swap out QtQuick for QtWidgets at a later point | 00:16 |
| uvos | not a big deal or? better than how we patch ddk1.9 in... | 00:16 |
| freemangordon | in ddx I ahve to implement accel for copy and composite | 00:16 |
| uvos | ok | 00:16 |
| uvos | copy what? | 00:16 |
| freemangordon | and we need dri3 | 00:16 |
| uvos | blit | 00:16 |
| freemangordon | yes | 00:16 |
| uvos | ok | 00:16 |
| freemangordon | blit | 00:16 |
| freemangordon | copy == blit | 00:17 |
| uvos | well for images :P | 00:17 |
| freemangordon | also, XV needs blit accel too | 00:17 |
| uvos | ok great :) | 00:17 |
| freemangordon | oh, lemme see if h-d works now | 00:17 |
| uvos | w/o dri3? | 00:18 |
| freemangordon | sure, we have dri2 | 00:18 |
| uvos | that works? | 00:18 |
| uvos | thats suprising to mo | 00:18 |
| freemangordon | yes, it works | 00:18 |
| freemangordon | because of pvr_dri ;) | 00:18 |
| freemangordon | actually, if I implement blit accel it may turn out we don't need dri3 | 00:19 |
| uvos | *me | 00:19 |
| uvos | ok hmm i thought mesa needed some special stuff for dri2 in the dri plugins | 00:19 |
| uvos | but maybe im mistaken/out of date | 00:19 |
| freemangordon | omap driver supports dri2 | 00:20 |
| freemangordon | well, no idea but it works | 00:20 |
| uvos | no i mean on the mesa side | 00:20 |
| uvos | but its fine | 00:20 |
| uvos | if it works :) | 00:20 |
| freemangordon | hmm, h-d still does not work in landscape | 00:20 |
| freemangordon | PVRRenderBufferInitFromFd: Failed to import device memory for render buffer (PVRSRV_ERROR_INVALID_PARAMS) | 00:21 |
| freemangordon | which is weird, given that glmark-es2 works | 00:21 |
| freemangordon | maybe clutter 0.8 misbehaves | 00:21 |
| uvos | or maybe not glmark-es2 allocates few buffers, a compositor holds a buffer for eatch window | 00:29 |
| uvos | so it exercises the interface way more | 00:29 |
| uvos | anyhow sounds like good progress | 00:29 |
| * uvos zzzz | 00:29 | |
| * freemangordon too | 00:49 | |
| calebtheythem[m] | haha | 01:22 |
| calebtheythem[m] | I got UART on the photon q :D | 01:22 |
| calebtheythem[m] | the JTAG header pinout from the moto X was close enough, found the TX pin and it spits out bootloader logs | 01:23 |
| calebtheythem[m] | omg, the cheeky bootloader finds any `console=` args on the kernel cmdline and replaces it with `console=null` | 01:25 |
| calebtheythem[m] | aha and we have 5.15 booting! | 01:57 |
| zmatt | freemangordon: oh if it's of interest, I also found this bit of documentation/code I wrote to explain how exactly TILER swizzles addresses: https://pastebin.com/raw/pWWtEiXc | 02:03 |
| dreamer | hmm, want to try some gl4es on droid4 soon. have it working on pandora 1ghz now with pure data and Gem :] | 03:47 |
| joerg | *crickets* | 05:12 |
| tmlind | calebtheythem[m]: nice to hear your got it working, got some link for the jtag header pinout for reference? | 06:18 |
| * calebtheythem[m] uploaded an image: (104KiB) < https://libera.ems.host/_matrix/media/r0/download/connolly.tech/vywfbjfkhdzfoIXnKYZyrIxl/IMG_20211113_010422.jpg > | 06:20 | |
| calebtheythem[m] | tmlind: not sure if pictures from matrix will send to IRC | 06:20 |
| tmlind | the link works fine | 06:21 |
| tmlind | what's the pmic on that one then? | 06:21 |
| calebtheythem[m] | Tx is the 3rd pin from the top on the right side of the header in this image. I'll document it properly on https://wiki.postmarketos.org/wiki/Serial_debugging:Cable_schematics and reference it from the maemo wiki too | 06:22 |
| tmlind | ok | 06:22 |
| calebtheythem[m] | tmlind: its the qcom pm8921 pmic, similar ti the pm8941 i think, it has quite good support in mainline | 06:22 |
| tmlind | ok nice | 06:22 |
| calebtheythem[m] | the emmc works already with no configuration from what i can tell, USB and display will be trickier | 06:23 |
| tmlind | ok what's the usb controller then? | 06:23 |
| * tmlind at least not musb hopefully | 06:24 | |
| tmlind | dwc2 maybe? | 06:24 |
| calebtheythem[m] | probably dwc2 | 06:25 |
| calebtheythem[m] | theres no dt for it yet, and downstream is uhhh pretty useless. im not very familiar with board files so it will be a learning experience | 06:25 |
| calebtheythem[m] | currently it seems the watchdog driver fails to probe with some clock error, so i have that to resolve first otherwise it reboots after ~30 seconds or so | 06:26 |
| tmlind | ok yeah the old downstream kernels can be mostly used as some kind of register documentation :) | 06:29 |
| tmlind | zmatt: hi, so there are now open sourced mesa patches from chromeos so the situation is a little bit better than last time around | 06:35 |
| sicelo | Nice work calebtheythem[m] | 07:45 |
| Danct12 | calebtheythem[m], GIVE ME YOUR PHOTON Q | 08:24 |
| Danct12 | *angry face* | 08:24 |
| freemangordon | zmatt: going to send SG patch for upstreaming, what name/email to use for Suggested-by: tag? | 10:13 |
| zmatt | see pm. how much fudging was required in the end to make it work? :) | 10:17 |
| zmatt | tmlind: hmm? | 10:17 |
| freemangordon | this https://github.com/freemangordon/mesa/tree/mesa-pvr-ti | 10:18 |
| zmatt | I'll admit I don't know much about how mesa works... like, where does this fit in in the big picture? | 10:22 |
| freemangordon | we have a couple of blobs replaced with FOSS stuff | 10:22 |
| freemangordon | zmatt: RE fudging - not that much | 10:23 |
| zmatt | which? this still links to the closed source libs right? | 10:23 |
| freemangordon | basically your patch re fine, IIUC, and I have to teach SGX driver to not assume it receives scatterlist that describes a single block of contiguous memory | 10:24 |
| freemangordon | zmatt: pvr_dri.so, for example | 10:24 |
| freemangordon | yes, it still links to the closed blobs | 10:25 |
| zmatt | what exactly does this do/provide? like, I noticed the structural changes between the 1.14 and 1.17 drivers, and the introduction of mesa stuff such as its libgbm instead of the custom one used in 1.14, but I don't know what exactly the significance/impact is of these changes | 10:28 |
| freemangordon | I was able to get xorg working in 1,17 ;) | 10:29 |
| zmatt | ah | 10:29 |
| zmatt | because x11 depends (for 3d accel) on mesa, and the sgx libs now function as a plugin into that? | 10:30 |
| freemangordon | well, my work is based on top of chromeos driver, which allowed us to have xorg support | 10:30 |
| freemangordon | but, I REed pvr_dri that comes with 1.17 blobs, so we now have 100% match | 10:30 |
| freemangordon | chromeos mesa was crashing SGX with glmark-es2-drm. Also, IIRC it has issues with wayland | 10:31 |
| freemangordon | x11 3d support depends on dri2/dri3 support in mesa | 10:32 |
| freemangordon | or rather EGL_PLATFORM_X11 and the was compiled out in MESA coming with the blobs | 10:32 |
| Wizzup | should we start looking at packaging this? | 10:45 |
| freemangordon | not yet | 10:45 |
| freemangordon | well, "start looking", yes | 10:45 |
| freemangordon | :) | 10:45 |
| Wizzup | ok | 10:45 |
| freemangordon | oh, send a bad patch | 10:45 |
| freemangordon | :* | 10:45 |
| freemangordon | :( | 10:45 |
| Wizzup | happens | 10:46 |
| freemangordon | yeah | 10:46 |
| Wizzup | so apart from kernel, mesa, and new userspace, we need the omap ddx? | 10:46 |
| freemangordon | yes | 10:46 |
| freemangordon | so far I have SolidFill accelerated | 10:46 |
| Wizzup | do we care which mesa we use in particular? i.e. do we go the extra mile and somehow get new meson working in our CI to build recent mesa release? | 10:46 |
| Wizzup | or do we stick to some older release with your work on top | 10:46 |
| freemangordon | I think this makes sense | 10:47 |
| freemangordon | (get lates) | 10:47 |
| freemangordon | *latest | 10:47 |
| freemangordon | sec, to re-send the patch | 10:47 |
| Wizzup | makes sense - older release or latest mesa? | 10:54 |
| zmatt | freemangordon: hmm, https://lore.kernel.org/dri-devel/ee9f6526-3050-9624-f9ba-e39bacceb19e@samsung.com/ | 10:57 |
| zmatt | freemangordon: I have no idea about this anymore though, I don't remember the issue at all and would need to dig into how scatterlists work again, which I don't think I am going to since I have other stuff that needs my attention | 10:59 |
| freemangordon | yeah, sure | 11:00 |
| freemangordon | I am not going to send that nents/orig_nents patch anyway | 11:00 |
| freemangordon | tmlind: do you plan to upstream your prm fixes? | 11:03 |
| freemangordon | also, it seems we have 5.15 released, are you goingt o rebase? | 11:04 |
| freemangordon | ok, all patches were send :) | 11:17 |
| zmatt | freemangordon: looks like this would be a case for using for_each_sgtable_dma_sg() ? | 11:17 |
| freemangordon | I don;t understand | 11:18 |
| freemangordon | you mean in PVR code? | 11:19 |
| zmatt | yeah, your sgx patch uses for_each_sg() in a way that looks like it's repeating the implementation of for_each_sgtable_dma_sg: https://elixir.bootlin.com/linux/latest/source/include/linux/scatterlist.h#L165 | 11:19 |
| freemangordon | yeah, I know it is ugly, but basically I copied what was already there | 11:19 |
| freemangordon | but yeah, I may look into that | 11:20 |
| freemangordon | ah, it is one-line change | 11:20 |
| freemangordon | well... | 11:20 |
| freemangordon | will fix if nikolaus asks me to do so | 11:21 |
| freemangordon | VRFB suppot in omapdrm is of higher prio | 11:24 |
| freemangordon | *support | 11:24 |
| zmatt | so what happens here if any scatterlist element is not actually page-aligned? | 11:26 |
| freemangordon | no idea | 11:29 |
| freemangordon | also, don;t know how test that | 11:30 |
| freemangordon | I can only hope PVR driver is smart enough to deal with that | 11:30 |
| zmatt | that seems highly unlikely | 11:30 |
| freemangordon | why not? | 11:30 |
| zmatt | because there's no way to handle that other than by failing or doing something bad | 11:31 |
| freemangordon | zmatt: I understand, lets see how Tomi will comment on the patch and I will propse TILER buffers to be PAGE aligned | 11:31 |
| freemangordon | or, maybe he will come up with another solution to that | 11:32 |
| zmatt | and it shouldn't be hard to test, if you allocate two buffers whose width (rounded up to a multiple of 32) is not a multiple of 1024 pixels you'll probably get a misaligned buffer | 11:33 |
| freemangordon | yes, but I would really want some comments from upstream first | 11:34 |
| dreamer | zmatt: remember you also noted some recent builds for sgx, except some missing SoCs right? | 12:01 |
| dreamer | noticed* | 12:01 |
| tmlind | freemangordon: ah right, i should send that omap3 prm patch out, will do after -rc1 | 15:05 |
| tmlind | will also merge or rebase the pending patches after -rc1 | 15:06 |
| tmlind | zmatt: yeah so less binary blobs, and nothing really stopping adding functions using standard drm functions that relate to kernel implementation like the 2d acceleration support done for gma500 pvr driver in kernel for example | 15:08 |
| tmlind | freemangordon: so if we fixed up the kernel module mmu support, and added something similar to gma500 2d functions, then xorg/mesa could just use those without any need to pipe the functions to the binary blobs? | 15:11 |
| freemangordon | no idea | 15:18 |
| freemangordon | I don't know what gma500 2d functions do | 15:18 |
| tmlind | accelerate 2d? | 15:20 |
| freemangordon | yes, but how? | 15:20 |
| freemangordon | by sending opcodes to 2d/3d engine? | 15:20 |
| tmlind | no it seems the 2d part is separate, there is some very limited blit function | 15:22 |
| freemangordon | blobs seem support all the solid ALU x11 ops | 15:23 |
| freemangordon | and also all composite ops | 15:23 |
| freemangordon | no idea how do the do it, but seems to be in HW | 15:24 |
| freemangordon | not to say that ultimately I want something that works so I will be able to get back to osso-abook | 15:25 |
| tmlind | heh, can't any longer find the accelerated 2d blit function in the gma500 driver | 15:27 |
| tmlind | looks like it got removed with commit 846939118270 ("drm/gma500: Remove 2D accel code") | 15:28 |
| tmlind | psb_accel_2d_copy() | 15:29 |
| freemangordon | hmm, looks similar to what blobs do | 15:31 |
| tmlind | oh | 15:31 |
| tmlind | just fyi, not saying there's any need to do anything about it, but seems kind of pointless piping everything to the blobs if the kernel sort of already knows about how to do it.. | 15:32 |
| freemangordon | https://code.woboq.org/linux/linux/drivers/gpu/drm/gma500/psb_reg.h.html#_M/PSB_2D_CLIP_BH | 15:32 |
| freemangordon | agree, but we don;t have enough info to implement more than what was already implemented | 15:33 |
| freemangordon | like pattern fills etc | 15:33 |
| freemangordon | but yeah, in theory someone could do it | 15:33 |
| freemangordon | not me, at least not soon :) | 15:33 |
| freemangordon | ok, copy acceleration is there, I expect glmark-results | 15:49 |
| freemangordon | glmark2 Score: 77 :) | 15:54 |
| freemangordon | let see what will be in landscape | 15:55 |
| freemangordon | glmark2 Score: 85 | 16:01 |
| freemangordon | uvos: ^^^ | 16:06 |
| Wizzup | wow | 16:06 |
| Wizzup | that runs circles around wayland too doesn't it | 16:06 |
| freemangordon | in landscape, yes | 16:07 |
| freemangordon | and there is acceleration also for composite | 16:07 |
| freemangordon | which is to be REed | 16:07 |
| freemangordon | have to see how will this behave on n900 | 16:07 |
| freemangordon | because now blit is done with PVR2DBlt3D | 16:08 |
| freemangordon | but, it may turn to be faster to use PVR2DBlt | 16:08 |
| Wizzup | ah | 16:08 |
| freemangordon | ok, lemme push what I have done so far | 16:09 |
| freemangordon | https://github.com/maemo-leste/xf86-video-omap/commit/a0a47a73599c41346a6402d1d303f39fc664aac2 | 16:17 |
| Wizzup | *nod* | 16:27 |
| Wizzup | does h-d also work in both orientations atm? | 16:27 |
| Wizzup | I saw some remark on that last night | 16:27 |
| freemangordon | no, it does not | 16:35 |
| freemangordon | that's the last issue remaining | 16:35 |
| Wizzup | ok | 16:37 |
| freemangordon | I will need help with packaging of the blobs | 16:47 |
| freemangordon | IOW - please somebody, package the blobs :) | 16:47 |
| Wizzup | do you have a list of what needs to be packaged | 17:01 |
| Wizzup | I have never really touched ddk 1.17 yet | 17:01 |
| freemangordon | blobs that contain the version in its name and headers | 17:02 |
| freemangordon | like libdbm.so.1.17.4948957 (and libdbm.so.1 and libdbm.so) | 17:03 |
| freemangordon | we dont; need binaries | 17:04 |
| freemangordon | like pvrsrvctl | 17:04 |
| Wizzup | ok | 17:04 |
| freemangordon | but, we need the headers from the kernel module that I pushed in the ^^^ comiit | 17:04 |
| freemangordon | those are neede to build the EXA | 17:04 |
| Wizzup | how do those need to be packaged (the headers) | 17:05 |
| freemangordon | in -dev package, with pkgconfig | 17:05 |
| freemangordon | I suggest to install in /usr/include/IMG/$version | 17:05 |
| freemangordon | or somesuch | 17:05 |
| freemangordon | also, I am not really sure where I gto pvr2d.h from | 17:06 |
| freemangordon | but it seems to match pvr2d.so in 1.17 blobs | 17:07 |
| freemangordon | also, we would need kernel. maybe all this shoudl go in -experimental as somone suggested few days ago | 17:08 |
| freemangordon | and MESA | 17:08 |
| freemangordon | tomorrow I will try to fix h-d not working in landscape | 17:08 |
| freemangordon | PR driver has some issue with importing the BO when in landscape | 17:09 |
| Wizzup | ok | 17:17 |
| Wizzup | parazyd: ping | 17:18 |
| tmlind | freemangordon: hehe quite a bit off headers added to xf86-video-omap :) | 17:42 |
| freemangordon | yeah | 17:42 |
| freemangordon | those should go to blobs -dev package | 17:43 |
| Wizzup | should it be in a separate git repo even? | 17:43 |
| Wizzup | yeah right | 17:43 |
| Wizzup | for the blobs | 17:43 |
| freemangordon | they are already in separate repo | 17:43 |
| freemangordon | https://git.ti.com/cgit/graphics/omap5-sgx-ddk-um-linux/ | 17:43 |
| freemangordon | maybe we shall clone that in leste, dunno | 17:44 |
| Wizzup | yeah we'd probably want to package a part of that I recon | 17:44 |
| Wizzup | maybe we can make a github issue for packaging this? | 17:44 |
| Wizzup | would make it easier to pick it up without back and forths | 17:45 |
| parazyd | Wizzup: pong | 18:15 |
| Wizzup | fmg asked for help packaging all the new 3d stuff which will bring n900 and droid4 to 5.15 and dk 1.17 | 18:15 |
| Wizzup | ddk 1.17 | 18:15 |
| Wizzup | I can help some, but maybe you can help some too | 18:16 |
| Wizzup | we'll probably want to use -experimental for a bit | 18:16 |
| parazyd | I can help tomorrow, sure. | 18:17 |
| parazyd | If you have a list of pkgs, it'd be helpful | 18:17 |
| Wizzup | I think that's a part we have to figure out | 18:19 |
| Wizzup | there's mesa with patches | 18:19 |
| Wizzup | and the ddk binary stuff, also a -dev header pkg for it | 18:20 |
| Wizzup | and omap ddx at least | 18:20 |
| Wizzup | not sure if there is more | 18:20 |
| parazyd | aha, ok | 18:21 |
| Wizzup | freemangordon: where is the kernel tree? | 18:21 |
| parazyd | Did you already play some with mesa packaging? | 18:21 |
| Wizzup | parazyd: no, but 4-5 folks built mesa on their d4, and I was thinking of toying with bencoh's cross compile thing to build it on my laptop first | 18:21 |
| Wizzup | it just seems to need meson from deb stable | 18:22 |
| parazyd | Alright | 18:22 |
| parazyd | From the mesa we currently build, we had to downgrade the meson dep to 0.49 | 18:22 |
| parazyd | And pull the rest from backports | 18:22 |
| parazyd | However backports is just build-dependency, not necessary for runtime. | 18:23 |
| Wizzup | right | 18:23 |
| Wizzup | what do you mean downgrade? | 18:23 |
| parazyd | And there's also glvnd and libdrm which we might want to try to update. | 18:23 |
| parazyd | By downgrade, I mean replacing the 0.52 with 0.49 in debian/control. | 18:23 |
| Wizzup | freemangordon: parazyd: https://github.com/maemo-leste/bugtracker/issues/524#issuecomment-968103934 | 18:24 |
| Wizzup | parazyd: I think we could just get newer meson .deb and dpkg -i on build | 18:24 |
| Wizzup | ugly but I think was the easier solution since there were some new features in use | 18:24 |
| parazyd | That doesn't sound convenient | 18:25 |
| dreamer | r3boot: o/ | 18:25 |
| Wizzup | parazyd: having mesa git is convenient though | 18:26 |
| Wizzup | we can't just downgrade the version anymore is what I mean | 18:26 |
| Wizzup | so we -need- another solution | 18:26 |
| parazyd | There's also 0.56 meson in backports | 18:27 |
| r3boot | .o/ | 18:27 |
| Wizzup | parazyd: oh, then that should be fine | 18:27 |
| Wizzup | if that's new enough | 18:27 |
| parazyd | I don't recall right now why it didn't work before, but we should revisit it | 18:27 |
| Wizzup | bencoh: care to share your mesa build setup so I can try it? | 18:27 |
| freemangordon | Wizzup: kernel tree is tmlind's one with few patches on top | 18:41 |
| freemangordon | the ones I sent for upstreaming | 18:41 |
| Wizzup | which patches? | 18:41 |
| Wizzup | it'll be good to know exactly what branch and what patches if we try to package it | 18:42 |
| Wizzup | also xorg.conf.d/ if required, etc | 18:43 |
| freemangordon | 27860954b45c5e1c2e86bf711808dde275eb3c47 (HEAD -> droid4-pending-pvr-omapdrm-v5.15) drm: pvrsgx: implement pvr_ioctl_unpriv | 18:43 |
| freemangordon | 011a660042e47be8351685164fba4e1c0a5f978c drm: pvrsgx: dmabuf import - Do not assume scatterlist memory is contiguous | 18:43 |
| freemangordon | 707b816498ba1f8e710704304078713fe9542a2c drm: omapdrm: Export correct scatterlist for TILER backed BOs | 18:43 |
| freemangordon | bf21000e617721048ff985630f779b01b41f5adc drm/omap: Fix omap_gem_dma_sync_buffer() when we already have a dma_addr | 18:43 |
| freemangordon | ea9a62c8777c7933962cbb613b3dd40ecabbd9fc drm/omap: Fix shmem write-combined buffer handling | 18:43 |
| freemangordon | a476f612571c0817cf0d744db4eee00c7468708d (tmlind/droid4-pending-pvr-omapdrm-v5.15) drm: pvrsgx: pvr-drv: Fix OCP handling with ioremap and reg access | 18:43 |
| Wizzup | any config changes? | 18:43 |
| freemangordon | umm, I don't think so | 18:43 |
| freemangordon | but, we'll have to do some I guess | 18:43 |
| Wizzup | which ones do we need? | 18:44 |
| freemangordon | hmm, wait | 18:44 |
| freemangordon | I just pulled from tmlind's repo | 18:44 |
| freemangordon | and it seems only : | 18:44 |
| freemangordon | 3455ec8297f37bacf965e2c23cd33c0e45b92aae (HEAD -> droid4-pending-pvr-omapdrm-v5.15) drm: pvrsgx: implement pvr_ioctl_unpriv | 18:44 |
| freemangordon | f1e11e600e07c19174d5a8c02a008b75120e1aa9 drm: pvrsgx: dmabuf import - Do not assume scatterlist memory is contiguous | 18:44 |
| freemangordon | 6947433922ec6f81967e6215c7f84e5bc1aef86b drm: omapdrm: Export correct scatterlist for TILER backed BOs | 18:44 |
| freemangordon | are needed | 18:44 |
| freemangordon | those I sent upstream | 18:44 |
| freemangordon | Wizzup: but, I'll take care of that once we have the other things in place | 18:45 |
| Wizzup | ok, so what do you want packaged then, mesa, ddx and the headers? | 18:45 |
| freemangordon | and kernel | 18:46 |
| freemangordon | but, ddx will be the last one | 18:46 |
| freemangordon | as I'll have to rework it to use blobs -dev headers | 18:46 |
| freemangordon | ah, there is one more change kernel wise here | 18:47 |
| freemangordon | PRM one | 18:47 |
| freemangordon | tmlind: promised to create a patch, IIRC | 18:47 |
| freemangordon | hmm, ddx is already packaged | 18:48 |
| freemangordon | it is xf86-video-omap | 18:49 |
| tmlind | how about i'll send it out tomorrow and then apply to droid4-pending-v5.15, also merge in v5.15? | 18:49 |
| freemangordon | would be great | 18:49 |
| tmlind | ok | 18:49 |
| freemangordon | 5.15.2 maybe? | 18:49 |
| tmlind | ok | 18:49 |
| freemangordon | afaik this is latest, no? | 18:49 |
| tmlind | i guess | 18:50 |
| freemangordon | thanks! | 18:50 |
| tmlind | uvos: got any other more up to date stuff to merge in tomorrow? | 18:50 |
| tmlind | hmm i can make the pvr black areas disappear with a patch to refresh the lcd, but i don't think it's the right fix | 18:52 |
| tmlind | it just hides the black squares with some extra refreshes | 18:52 |
| tmlind | but the black square problem will be there at least for one frame | 18:53 |
| tmlind | freemangordon: have you noticed the black squares on n900 between frames? | 18:53 |
| freemangordon | tmlind: didn;t test on n900 much, but I don;t thinks so | 18:54 |
| freemangordon | tmlind: see https://github.com/maemo-leste/xf86-video-omap/blob/pvr-exa/src/drmmode_display.c#L1575 | 18:54 |
| freemangordon | this is the hack I came up with on d4 | 18:54 |
| freemangordon | I call it every time scanout has been changed | 18:55 |
| tmlind | ok let me post some kind of version of what i did in omapdrm | 18:55 |
| freemangordon | for me this assures the latest change is always visible | 18:55 |
| freemangordon | tmlind: I think th issue is that omapdrm have no idea if sgx has rendered something so it never flushes framebuffer to the display unless forced | 18:56 |
| freemangordon | ttyl | 18:57 |
| tmlind | here you go, maybe give this a try and see if it might make sense: muru.com/linux/d4/omapdrm-flush-on-pin-unpin.patch | 18:59 |
| tmlind | later | 18:59 |
| freemangordon | tmlind: maybe do that for manually updated displays only | 19:14 |
| freemangordon | also, when this pin/unpin happens? | 19:14 |
| tmlind | not quite sure, but yeah only needed for manually updated displays | 19:19 |
| bencoh | Wizzup: do you want me to upload an uptodate version of that howto? | 19:21 |
| bencoh | Wizzup: http://muarf.org/~bencoh/maemo/leste/leste-lxc-crossbuilder | 19:29 |
| bencoh | Wizzup: I also fetched meson 0.56 from packages.debian.org and installed it in the armhf lxc container | 19:30 |
| Wizzup | bencoh: thanks, I will try to set it up momentarily | 19:35 |
| Wizzup | freemangordon: what branch here do we want packaged https://git.ti.com/cgit/graphics/omap5-sgx-ddk-um-linux/ ? | 20:45 |
| Wizzup | ti-img-sgx/zeus/1.17.4948957 ? | 20:45 |
| freemangordon | 1.17.4948957-next | 20:45 |
| Wizzup | ah, newer one even | 20:45 |
| freemangordon | mhm | 20:57 |
| Wizzup | ok | 20:58 |
| Wizzup | I updated this: https://github.com/maemo-leste/bugtracker/issues/524#issuecomment-968103934 | 20:58 |
| tmlind | freemangordon: omap_crtc_flush() already returns early if not manually_updated display. no idea if pin/unpin is the right place for the flush though | 21:03 |
| tmlind | it might be flushing way too often, i guess glmark would tell | 21:04 |
| freemangordon | TDB, I don;t think kernel has information about when a flush is needed | 21:04 |
| freemangordon | *TBH | 21:04 |
| tmlind | yeah might be | 21:05 |
| freemangordon | also pn/unpin is mmap/munmap, no? | 21:05 |
| tmlind | yup.. | 21:05 |
| freemangordon | I don't think this is the right place | 21:06 |
| tmlind | me neither | 21:06 |
| tmlind | testing with hdmi also shows the black squares flickering between the frames if you underclock sgx | 21:07 |
| tmlind | which means this has nothing to do with the refresh of the lcd | 21:07 |
| freemangordon | this is weston? | 21:07 |
| tmlind | yeah | 21:08 |
| tmlind | i also suspect you would see the same with xorg on hdmi when underclocked | 21:08 |
| freemangordon | did you try to change FlushBehaviour in powervr.ini? | 21:08 |
| tmlind | hmm no | 21:08 |
| Wizzup | bencoh: hm: W: Failure trying to run: chroot "/var/cache/lxc/devuan/partial-beowulf-armhf" /bin/true | 21:08 |
| freemangordon | tmlind: I doubt, pvr exa waits for blits to complete and then flushes the framebuffer | 21:09 |
| Wizzup | bencoh: maybe qemu binfmt was not set up | 21:09 |
| Wizzup | retrying | 21:09 |
| tmlind | freemangordon: should i try with 2 or what did you suggest earlier? | 21:09 |
| freemangordon | yes | 21:09 |
| freemangordon | 2 is the value | 21:09 |
| freemangordon | but, you also need glFinish() at the appropriate place(s) | 21:10 |
| tmlind | ok will try tomorrow, what's the difference between 1 and 2? one number is greater than the other? | 21:10 |
| Wizzup | bencoh: hm same problem | 21:10 |
| freemangordon | 2 makes glFlush() behave as expected | 21:10 |
| tmlind | ok | 21:10 |
| freemangordon | 1 just sends to SGX to start rendering, without actually witing for render to complete | 21:11 |
| freemangordon | IIUC | 21:11 |
| tmlind | ah ok that sounds like it would explain the black squares | 21:11 |
| tmlind | i guess no need to reload the kernel module hopefully? | 21:12 |
| freemangordon | no, this is userspace thing | 21:12 |
| tmlind | you never know with these blobs | 21:13 |
| freemangordon | tmlind: you need to add that in [default] section, IIUC | 21:13 |
| tmlind | ok | 21:13 |
| freemangordon | ttyl | 21:13 |
| tmlind | later | 21:14 |
| Wizzup | heh lxc-create deletes the subvolume right away so I can't see the log | 21:15 |
| tmlind | freemangordon: changing it to 2 did not make any difference alone, will try again just in case | 21:15 |
| tmlind | ttyl | 21:15 |
| Wizzup | bencoh: ah my qemu isn't static | 21:27 |
| bencoh | Wizzup: right you need a static qemu | 22:33 |
| bencoh | my bad | 22:33 |
| Wizzup | I think it is static, so there is something else going on | 22:34 |
| bencoh | any erro? | 22:35 |
| bencoh | (still the same?) | 22:35 |
| bencoh | assuming your host is debian/devuan based, installing qemu-static should be enough as it will also pull binfmt and set it properly in the postinst script | 22:36 |
| bencoh | (iirc) | 22:36 |
| * sicelo whispers systemd-nspawn :p | 22:37 | |
| Wizzup | bencoh: sorry, phone call | 22:39 |
| Wizzup | sicelo: how is this relevant? | 22:39 |
| dsc_ | Wizzup: hello, is this the droid4 helpdesk? My droid4 seems "dead-ish" - wont turn on, no blinking green light | 22:40 |
| dsc_ | 10sec power button + volume down does nothing | 22:40 |
| dsc_ | do I need an USB charger? | 22:40 |
| dsc_ | (I connect it straigh to my pc with the usb cable :P) | 22:41 |
| Wizzup | dsc_: might the battery be dead? | 22:46 |
| Wizzup | or very low | 22:46 |
| dsc_ | Wizzup: it has been connected directly to my PC for some time now | 22:47 |
| dsc_ | getting the impressino it might not be charging ... | 22:47 |
| dsc_ | do you use a dedicated USB charger? | 22:48 |
| Wizzup | in cases of low batteries, try wall/dedicated charger | 22:50 |
| Wizzup | bencoh: gentoo, but I'll go and figure it out | 22:54 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
