| uvos | i think we should think about defaults a bit more | 11:05 |
|---|---|---|
| uvos | like ppl i hand the bionic (which runs defaults) get confused with how the power button works | 11:05 |
| uvos | or how we all install simple-brigtness-applet because going into the settings to change the brigtness is pretty lame | 11:05 |
| Wizzup | mhm | 11:07 |
| freemangordon | uvos: what's wrong with how power button works? | 11:32 |
| sicelo | doesn't follow android standards | 11:39 |
| freemangordon | ah, I see | 11:40 |
| sicelo | short press = lock/unlock. long press = system/boot options | 11:40 |
| uvos | having to double click to turn the dsiplay off but click once to turn the dsiplay back on | 11:41 |
| uvos | messes with peoples muscel memory form android and ios yeah | 11:41 |
| uvos | theres nothing wrong with it per say | 11:41 |
| dsc_ | how does the automatic brightness works? | 11:41 |
| uvos | dsc_: wdym | 11:41 |
| sicelo | dsc_: ALS sensor, as always :-) | 11:42 |
| dsc_ | gotcha | 11:42 |
| Wizzup | uvos: I think eventually we will want to rework some of how the status applet works from UX pov, because eventually it just "fills up" with applets | 11:43 |
| Wizzup | but that is a 2022 or 2023 thing :P | 11:43 |
| sicelo | do they begin scrolling when you have many of them? i've never had a lot of them, so i never really noticed | 11:44 |
| Wizzup | even if they scroll it doesn't work | 11:44 |
| Wizzup | as in it's just not ok | 11:44 |
| Wizzup | I mean from usability pov | 11:45 |
| Wizzup | if you install wireguard and tor status applet you already get two more | 11:45 |
| Wizzup | it fills up | 11:45 |
| RedW | 7 | 11:48 |
| sicelo | 8 | 11:48 |
| sicelo | :) | 11:48 |
| RedW | oops, wrong window :) | 11:48 |
| dsc_ | how do I CTRL^D with a droid 4 :D | 11:54 |
| uvos | Wizzup: the status applet runs the applets in a hildon-pannable-area | 11:55 |
| uvos | thas why the slider is broken | 11:55 |
| dsc_ | got it | 11:55 |
| uvos | (hildon-pannable-area reports event coordinates wrong) | 11:55 |
| uvos | Wizzup: so id be suprised if it dosent start scrolling | 11:55 |
| uvos | aka its a bug if it dosent | 11:55 |
| uvos | wireguard and tor status applet should ony appear if they are configured really | 11:57 |
| uvos | btw | 11:57 |
| freemangordon | :nod: | 12:06 |
| Wizzup | uvos: no, because you can activate them in system mode at any time | 12:06 |
| Wizzup | I am talking about the status area button | 12:07 |
| freemangordon | not only configured, but active, no? | 12:07 |
| Wizzup | and the way to activate them is through that button | 12:07 |
| Wizzup | freemangordon: the icon in the status area, yes | 12:07 |
| uvos | no sure how having the status area button makes sense | 12:07 |
| uvos | if thereis no vpn configured | 12:08 |
| Wizzup | right so I was talking about that window with the buttons | 12:08 |
| freemangordon | ok, but I don;t think scrolling is that bad there | 12:08 |
| Wizzup | freemangordon: ok, I never tried | 12:08 |
| * uvos confused | 12:08 | |
| freemangordon | Wizzup: the point is that buttons should not be there unless those are active | 12:08 |
| uvos | what window with buttons? not hildon-status-menu? | 12:08 |
| Wizzup | uvos: I think we're on the same page, I do mean hildon-status-menu | 12:09 |
| uvos | right thos buttons shold only be there if activating the vpn is a possiblity | 12:09 |
| uvos | ie its configured | 12:09 |
| Wizzup | freemangordon: that is not true for internet connection, or profiles, clock, bluetooth | 12:09 |
| freemangordon | Wizzup: what is the functionlaity of those buttons? | 12:09 |
| Wizzup | freemangordon: to enable tor/wireguard system wide for an active connection | 12:09 |
| freemangordon | ah | 12:09 |
| Wizzup | there's also the openvpn one btw | 12:10 |
| freemangordon | well, yeah, ok | 12:10 |
| Wizzup | it might make sense to 'group' them eventually | 12:10 |
| freemangordon | I wonder if status menu supports groups | 12:10 |
| Wizzup | but that's a whole different thing | 12:10 |
| Wizzup | in any case 2022/2023 :P | 12:10 |
| freemangordon | I wouldn't be surprosed if groups are already supported | 12:10 |
| freemangordon | bu yeah, 2023 | 12:11 |
| freemangordon | :) | 12:11 |
| uvos | Wizzup: "uvos: no, because you can activate them in system mode at any time" yeah but what happens if i activate a vpn but there is no account configured? | 12:11 |
| uvos | ie just haveing the applet installed i have it in hildon-status-menu | 12:11 |
| uvos | ie the workflow that makes sense to me is: open settings -> configure a network -> now the button pops up in status-menu for me to enable or disable it. anyhow ttyl | 12:13 |
| Wizzup | uvos: I guess for tor you don't need an account | 13:08 |
| Wizzup | but yes for wg or openvpn this is true | 13:08 |
| * sicelo also doesn't see ux problem with scrolling in status area - android scrolls it too, ios too. it's unavoidable. and yes, best way to manage it is just to avoid having too many things there, especially inactive ones | 13:26 | |
| bencoh | well, to be fair on android you usually need to scroll for notifications | 13:27 |
| bencoh | not for always-displayed plugins | 13:27 |
| sicelo | at least on my android 8, when pulling down the notification drawer (which contains what is roughly hildon's status menu), i can only select among 5 items. then, as i continue pulling it down, more of them appear. in my case, 9 more appear | 13:29 |
| sicelo | so i guess if we take android as a benchmark for status menu, hildon problem is that our items individually take a lot of space, and thus two per column, so it fills up fast as a result | 13:30 |
| bencoh | yeah, a compact layout/mode would probably help here | 13:32 |
| freemangordon | hmm, one cannot allocate TILER BOs through dma_buf API | 13:40 |
| * bencoh headscratches | 13:40 | |
| bencoh | how are you supposed to allocate it then? | 13:40 |
| freemangordon | bencoh: omap_bo_new | 13:41 |
| freemangordon | which is omap specific | 13:41 |
| bencoh | uh | 13:41 |
| bencoh | sad | 13:41 |
| freemangordon | yeah | 13:41 |
| freemangordon | IIUC you can;t use gbm_bo_create and get a TILER BO | 13:41 |
| freemangordon | which leaves us with the only option to use xf86-video-omap if we and sane performance with rotated display | 13:43 |
| freemangordon | s/we and/we want | 13:43 |
| bencoh | or add full dmabuf support to the omap/tiler/whatever drivers galaxy | 13:46 |
| bencoh | (at least to the point where one can allocate tiler buffers) | 13:46 |
| freemangordon | I don't think I am the one to do that | 13:46 |
| freemangordon | not without some hints from the maintainers | 13:47 |
| freemangordon | I wrote a mail, still no answer | 13:47 |
| bencoh | I wonder if there is any reason notto default to tiler buffers on omap4/omap5 | 13:47 |
| freemangordon | no idea | 13:48 |
| freemangordon | but dma_buf defaults to CMA | 13:48 |
| bencoh | hmm | 13:48 |
| bencoh | don't you just mmap() on some fd to get buffers? | 13:49 |
| freemangordon | it is not that simple | 13:50 |
| bencoh | well, and/or use some ioctl before/after | 13:50 |
| bencoh | anyway, it should still be bound to some device | 13:50 |
| freemangordon | the point is that SGX(for example) should see the same memory correctly | 13:50 |
| freemangordon | but, there is a note that TILER memory is shmem memory | 13:52 |
| freemangordon | I don;t understand what is that supposed to mean | 13:52 |
| bencoh | yeah, I get that part, I'm just wondering what actually happens when you allocate a dmabuf-able buffer | 13:52 |
| freemangordon | I don;t | 13:52 |
| freemangordon | so please explain what "shmem" is | 13:52 |
| bencoh | shmem, as in /dev/shm, or as in "memory shared between cpu and sgx, and mapped at the same address"? | 13:53 |
| bencoh | (ah, I wrote that "I get that part" before you mentioned shmem btw) | 13:53 |
| freemangordon | but how it can be mapped at the same address, given that SGX has its own mmu? | 13:54 |
| bencoh | they could set it that way | 13:54 |
| freemangordon | see https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/omapdrm/omap_gem.c#L1300 | 13:54 |
| bencoh | no tiler there, right? | 13:54 |
| freemangordon | mhm | 13:55 |
| freemangordon | and no way to tell it to be | 13:55 |
| freemangordon | the only way to use the tiler is to pass flags through userspace API | 13:55 |
| freemangordon | omap_bo_new() | 13:56 |
| freemangordon | but, your question is absolutely valid - why all BOs are not allocated through the tiler? | 13:56 |
| bencoh | I guess it wouldn't make any sense on non-tiler platforms | 13:56 |
| bencoh | but still | 13:57 |
| freemangordon | this is omapdrm which supports TILER rotation only | 13:57 |
| freemangordon | lets forget about omap3 for a while | 13:57 |
| bencoh | ah :) | 13:57 |
| freemangordon | tmlind: any clue? ^^^ | 13:57 |
| bencoh | then yeah, I don't see why | 13:57 |
| freemangordon | for VRFB it is another story | 13:58 |
| freemangordon | because we have limited contexts (12 on omap3) so it makes sense to assign VRFB context to BO only when really needed | 13:58 |
| bencoh | unless ... if TILER has a limited number of "buffers" | 13:58 |
| freemangordon | yeah | 13:59 |
| freemangordon | but I was unable to find the TRM to see how this works | 13:59 |
| bencoh | hmm, I think I downloaded the TRM at some point, lemme check | 13:59 |
| bencoh | iirc TI removed some manuals from their website right? | 14:00 |
| freemangordon | and because my knowledge on DMA API and MMUs ends here (or rather has ended 200 meters before here) I don;t know if it is possible to somehow "migrate" non-tiler (or non-vrfb) BO to TILER one | 14:00 |
| buZz | zmatt used to be the TILER expert | 14:00 |
| bencoh | meh, I have the omap3530 one here, no omap4 | 14:00 |
| buZz | back in #dragonbox-pyra | 14:00 |
| sicelo | omap 4 trm? i have it | 14:01 |
| freemangordon | buZz: it is not about the TILER, but about how the rest of the system sees such a buffer | 14:01 |
| bencoh | right, zmatt had it work by kludging part of the driver(s), I don't think it ever got merged. and that was on omap5 | 14:01 |
| bencoh | oh, found it on the desktop I'm connected from, silly :) | 14:02 |
| bencoh | (uploading it ...( | 14:02 |
| freemangordon | like - we allocate a non-TILER BO that is send to SGX | 14:02 |
| freemangordon | SGX sets it MMU to access that BO | 14:02 |
| sicelo | ah, you'll be faster (bencoh). was sending it to dropbox just now | 14:02 |
| bencoh | sicelo: yeah I figured :) | 14:03 |
| freemangordon | now, if we want to transform this BO to a TILER one, how SGX knows this change has happened to re-program its MMU? | 14:03 |
| freemangordon | the same goes for VRFB though | 14:03 |
| bencoh | freemangordon: http://muarf.org/~bencoh/maemo/OMAP4430_ES2.x_Public_TRM_vK.pdf | 14:04 |
| freemangordon | ok, good to have that | 14:04 |
| freemangordon | but, IIUC, TILER is just a kind of iommu | 14:04 |
| freemangordon | like, it remaps memory accesses, no? | 14:05 |
| freemangordon | so, implementation details are not important | 14:05 |
| freemangordon | also, even if TILER has unlimited 'buffers', VRFB does not, so we are in the same situation | 14:05 |
| bencoh | looks like TILER is actually a rotation engine as well | 14:06 |
| freemangordon | like VRFB | 14:06 |
| freemangordon | and yes, R in tileR is for rotation :) | 14:06 |
| bencoh | but yeah, it's basically all about address transformation | 14:06 |
| bencoh | meaning that it doesn't really "perform" the rotation, it "just" translate addresses to effectively return the pixels that should be addressed after rotation | 14:07 |
| bencoh | or so I understand it | 14:07 |
| freemangordon | my understanding is the same | 14:08 |
| bencoh | which is kinda funny, because it means that any access to a "rotated" buffer will go through it | 14:08 |
| bencoh | I wonder how expensive (energy-wise) that thing is | 14:08 |
| bencoh | maybe that's the reason it's not enabled by default btw | 14:09 |
| bencoh | either that, or erratums that make it buggy | 14:09 |
| bencoh | errata* | 14:09 |
| freemangordon | as simple address translation should not be that expensive | 14:09 |
| bencoh | dunno, maybe you're right | 14:10 |
| buZz | freemangordon: ah well, just saying it might not hurt to ask him for things that lack in understanding | 14:10 |
| buZz | guy works with TI stuff a -lot- | 14:11 |
| bencoh | another thing is ... what happens when it tries to access memory .... | 14:12 |
| freemangordon | we have a page fault | 14:12 |
| freemangordon | :) | 14:12 |
| bencoh | no I mean ... let's say you access a "rotated" buffer | 14:13 |
| bencoh | so it goes and fetches the right pixels(bytes) for you | 14:13 |
| bencoh | but instead of fetching a full line from RAM, it needs to fetch a "column", ie a pixel from every actual line | 14:14 |
| bencoh | doesn't sound super efficient to me, unless it actually fetches the full lines and caches it | 14:14 |
| freemangordon | I doubt it can cache 540x960x4 even for non-rotated scenario | 14:15 |
| bencoh | maybe it only caches macroblocks then | 14:15 |
| bencoh | otherwise it really sounds like a pain | 14:16 |
| freemangordon | but, I don't know how this stuff works, so... | 14:16 |
| freemangordon | they say TILER works on pages only | 14:16 |
| bencoh | yeah, me neither ... I never brought myself to actually read the whole TILER chapter | 14:16 |
| freemangordon | also, there was some note of 'no caching for TILER' somewhere | 14:16 |
| freemangordon | lemme try to find it | 14:17 |
| bencoh | noncached access on ARM really doesn't sound like something we would want | 14:17 |
| freemangordon | hmm, here https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/omapdrm/omap_gem.c#L1207 | 14:17 |
| freemangordon | not sure what is that supposed to mean | 14:17 |
| bencoh | ~(OMAP_BO_CACHED|OMAP_BO_WC|OMAP_BO_UNCACHED) | 14:18 |
| bencoh | so, it disables cached *and* uncached? :] | 14:18 |
| freemangordon | exactly :) | 14:18 |
| freemangordon | well, there is a call to tiler_get_cpu_cache_flags() | 14:18 |
| bencoh | interestingah | 14:18 |
| bencoh | meh, so yeah, uncached | 14:18 |
| bencoh | cpu_cache_flags is set to uncached | 14:19 |
| freemangordon | hmm, on omap5 only | 14:19 |
| bencoh | drivers/gpu/drm/omapdrm/omap_dmm_tiler.c .cpu_cache_flags = OMAP_BO_UNCACHED | 14:19 |
| bencoh | oh, right | 14:19 |
| freemangordon | for omap4 it is WC | 14:19 |
| bencoh | yeah | 14:19 |
| bencoh | interesting | 14:19 |
| freemangordon | so, the same as for dma_buf BOs | 14:20 |
| freemangordon | IIUC | 14:20 |
| * freemangordon is afk for a while | 14:20 | |
| freemangordon | back | 14:26 |
| bencoh | so yeah basically nothing inside the kernel uses the OMAP_BO_TILED_* flags | 14:27 |
| bencoh | the only way to use it is to pass it from userspace as you said | 14:28 |
| freemangordon | mhm | 14:28 |
| bencoh | I dunno if it's just me, but I always get the same feeling everytime I need to look at kernel-side buffer/dma allocation code ... | 14:31 |
| bencoh | (ETOOMUCHABSTRACTION :( ) | 14:32 |
| freemangordon | :D | 14:32 |
| bencoh | especially caching stuff | 14:32 |
| tmlind | no idea how OMAP_BO_TILED is used, i think the old ddk-1.9 used it via some custom ioctl | 14:33 |
| freemangordon | tmlind: yes, it can be requested by userspace | 14:34 |
| freemangordon | the point is - do you know why it is not there by default, for dma-buf BOs? | 14:34 |
| bencoh | as far as I see it, the main difference between the two in _gem_new is a call to shmem_file_setup() | 14:35 |
| bencoh | (and setting a few flags) | 14:35 |
| tmlind | no idea, it could be just that omap5 had some issue for the tiler needing uncached configuration making it probably unusable | 14:35 |
| bencoh | shmem_file_setup - get an unlinked file living in tmpfs | 14:35 |
| bencoh | so it really comes from there | 14:35 |
| tmlind | if some parts are not implemented, it could be because of 7cb0d6c17b96 ("drm/omap: fix TILER on OMAP5") | 14:37 |
| mighty17[m] | do we have nothing for pvr crashes https://paste.debian.net/1218824/ its really annoying | 18:09 |
| freemangordon | mighty17[m]: did you try with https://github.com/freemangordon/mesa ? | 18:11 |
| freemangordon | this branch https://github.com/freemangordon/mesa/tree/mesa-pvr-ti | 18:11 |
| mighty17[m] | i've been using xc-racer's mesa till now | 18:12 |
| freemangordon | use this one | 18:12 |
| freemangordon | it is the same as TI blobs | 18:12 |
| mighty17[m] | freemangordon: musl friendly? | 18:12 |
| freemangordon | well, at least pvr_dri is | 18:12 |
| freemangordon | yes, it is based on top of xc-racer's one | 18:13 |
| freemangordon | look at commit log | 18:13 |
| mighty17[m] | oh nice, i think i'll package it for pmos as well then :D | 18:13 |
| mighty17[m] | https://gitlab.com/postmarketOS/pmaports/-/blob/master/main/mesa-pvr-dri-classic/APKBUILD | 18:13 |
| freemangordon | well, test it first a bit :) | 18:13 |
| mighty17[m] | is this the one with x working as well? :D | 18:14 |
| freemangordon | yes | 18:14 |
| uvos | *sortof | 18:14 |
| mighty17[m] | :D im amazed by your work | 18:14 |
| Wizzup | we all are ;) | 18:15 |
| freemangordon | uvos: hmm? | 18:15 |
| mighty17[m] | freemangordon: i wont be building mesa on cortex a9's xD, packaging is also safer to downgrade | 18:16 |
| uvos | just hinting at that pvr_dri with mainline mesa dose support x but there is no ddx you can just use | 18:16 |
| freemangordon | well, yeah | 18:16 |
| uvos | ie x dosent work in practice with stock x | 18:16 |
| freemangordon | rigth | 18:17 |
| freemangordon | but, omap_drv works | 18:17 |
| mighty17[m] | well its always blobs which are troublesome | 18:17 |
| freemangordon | so we have DDX | 18:17 |
| freemangordon | mighty17[m]: not this time | 18:17 |
| freemangordon | we have no issues with blobs, but with modesetting/glamor | 18:17 |
| uvos | i mean its the blobs too writ missing extensions | 18:18 |
| uvos | but yeah glamor is a bit buggy on gles | 18:18 |
| freemangordon | mighty17[m]: also, we all built mesa on omap4 | 18:18 |
| freemangordon | sure, it takes ages, but... | 18:18 |
| mighty17[m] | is this a tradition? :P | 18:18 |
| uvos | heh | 18:18 |
| uvos | i reccomend disabeling mesa building other drivers than pvr_dri if you do | 18:19 |
| freemangordon | no, this is how you become a mаn :p | 18:19 |
| uvos | particually gallium/radionsi | 18:19 |
| uvos | then its not so bad | 18:19 |
| freemangordon | (or woman if you prefer) | 18:19 |
| mighty17[m] | uvos: im pretty sure my tab will just randomly reboot in middle and kill all progress | 18:19 |
| uvos | qemu then | 18:20 |
| freemangordon | well, it is meson/ninja, so it will continue to where it was :). but yeah, you you have option to not build it on the device, go ahead | 18:20 |
| freemangordon | *from where | 18:20 |
| mighty17[m] | uvos: why not just cross compile? | 18:20 |
| uvos | should work too | 18:20 |
| uvos | just afaik pmos useses qemu for its dev env no? | 18:21 |
| mighty17[m] | yeah it dies | 18:21 |
| uvos | at least it used to | 18:21 |
| mighty17[m] | does* | 18:21 |
| mighty17[m] | well my laptop isnt powerful as well xD i5 3210m ivy league | 18:21 |
| bencoh | mighty17[m]: may I ask what do you do with musl on droid4/leste/devuan? | 18:35 |
| mighty17[m] | bencoh I'm using pmOS(alpine) | 18:38 |
| bencoh | ah, right, nevermind :) | 18:41 |
| buZz | https://www.ebay.nl/itm/185151583991 | 19:35 |
| buZz | ^ nokia n950 anyone? :P | 19:36 |
| Wizzup | last time I asked someone to donate one I got permabanned from ebay | 19:39 |
| buZz | :D :D | 19:40 |
| buZz | yeah 'plz donate your unobtainium to meeeee' | 19:40 |
| buZz | Wizzup: might have more success asking ppl in #maemo :) | 19:41 |
| Wizzup | I don't really need one | 19:41 |
| tmlind | droid4 has obsoleted n950 :) | 19:45 |
| tmlind | well at least for me | 19:45 |
| * tmlind used n950 for years until it started breaking for the lcd, then got busy with droid4 | 19:46 | |
| freemangordon | I have a working one, but I need PVR driver for it :) | 19:54 |
| tmlind | heh ok :) i'm pretty sure it was the 2016 elce in berlin when sre, pavel and i chatted about getting droid4 working as a n900 replacement hardware | 19:56 |
| tmlind | freemangordon: did your rubber pads melt away on n950 into sticky mess? | 19:57 |
| freemangordon | yes | 19:59 |
| tmlind | probably possible to replace with some fuzzy pieces of felt | 20:00 |
| freemangordon | yeah | 20:00 |
| freemangordon | but doesn;t make sence without having SW for it :) | 20:00 |
| tmlind | yeah maybe in few years | 20:01 |
| freemangordon | yeah | 20:02 |
| freemangordon | [ 31318.703] (II) OMAP(0): Successfully initialized the "omap_pvr" sub-module | 21:00 |
| freemangordon | :) | 21:00 |
| Wizzup | neat :-) | 21:01 |
| freemangordon | hmm, how to test solid fill? | 21:02 |
| freemangordon | ah −rect500 | 21:03 |
| freemangordon | hmm, seems omap_pvr_drv I found has solid acceleration removed :( | 21:10 |
| freemangordon | I'll haev to implement that | 21:10 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!