| Wizzup | uvos: I see yourt new patches for hp detect using new apis, mabye we should go for new kernel in -devel ? | 09:23 |
|---|---|---|
| Wizzup | btw, if any anyone has any idea what is failing in parazyd's arm-sdk or image-builder, I'd appreciate it: https://phoenix.maemo.org/view/Images/job/leste-image-bionic/lastFailedBuild/console | 09:59 |
| Wizzup | all image builds seem to fail like this: | 09:59 |
| Wizzup | I: Base system installed successfully. | 09:59 |
| Wizzup | blend_bootstrap_setup:3: number expected | 09:59 |
| Wizzup | seems to maybe be this? [[ -n "$armsdk_version" ]] && req +=(device_name) | 10:02 |
| Wizzup | maybe it's related to the key expiry somehow | 10:03 |
| Wizzup | trying now | 10:08 |
| Wizzup | looks like that was it | 10:15 |
| Wizzup | good | 10:21 |
| freemangordon | :) | 10:26 |
| Wizzup | freemangordon: which pkgs do I install to check out the rtcom work? | 10:28 |
| Wizzup | rtcom-accounts-ui ? | 10:29 |
| Wizzup | and librtcom-accounts-ui-client0 ? | 10:29 |
| Wizzup | ah, the my information was from abook | 10:34 |
| freemangordon | umm, yes | 10:35 |
| freemangordon | otherwise installing rtcom-accounts-ui will pull everything needed (in theory) | 10:35 |
| Wizzup | what should I see once I install that | 10:37 |
| Wizzup | no cpa plugin, right? | 10:37 |
| freemangordon | a new entry in cpl | 10:37 |
| freemangordon | yes, there is | 10:37 |
| freemangordon | "voip and im accounts" | 10:37 |
| Wizzup | ok | 10:38 |
| Wizzup | I see it now | 10:38 |
| Wizzup | I guess I was so used to it on my n900 | 10:38 |
| Wizzup | :) | 10:38 |
| Wizzup | it shows an empty wizard atm | 10:38 |
| Wizzup | as expected I guess | 10:38 |
| freemangordon | yeah, I know | 10:38 |
| freemangordon | mhm | 10:38 |
| Wizzup | :) | 10:38 |
| Wizzup | man, so much changed for the news post, going to take some hours to finish this | 10:39 |
| Wizzup | I'll make a pdf out of it when I am done and invite some comment | 10:40 |
| Wizzup | (I won't push it to a hidden url like last time, since people picked it up with rss) | 10:40 |
| freemangordon | :) | 10:40 |
| Wizzup | Err:1 https://maedevu.maemo.org/leste beowulf InRelease Temporary failure resolving 'maedevu.maemo.org' | 10:49 |
| Wizzup | *sigh* | 10:49 |
| bencoh | DNS seems fine from here (?) | 10:54 |
| Wizzup | bencoh: yeah it is the temporary failure in the image build (which also doesn't cause a fatal error) that's annoying | 11:01 |
| Wizzup | there are some things in arm-sdk that just don't cause fatal errors and it's really annoying | 11:01 |
| Wizzup | I don't have the zsh knowhow to fix it | 11:01 |
| bencoh | is there a reason why it would temporarily fail to resolve though? | 11:08 |
| Wizzup | no idea | 11:08 |
| bencoh | ah | 11:08 |
| bencoh | you could add set -e at the top of the script btw | 11:09 |
| bencoh | you'll get a lot of false positives at first, but at least it should catch everything | 11:09 |
| Wizzup | does that work with zsh? | 11:09 |
| bencoh | hmm | 11:10 |
| bencoh | (damn, bash: zsh: command not found :D lemme check) | 11:10 |
| bencoh | looks like it works, yeah | 11:11 |
| uvos | Wizzup: the newer code is only different in implementation, functionally its the same | 12:04 |
| uvos | Wizzup: but yes we should update the kernel as allways | 12:04 |
| Wizzup | mhm | 12:06 |
| lel | MerlijnWajer created a repository: https://github.com/maemo-leste-extras/cssufeatures | 12:24 |
| uvos | why do we have this terrible hack in af-services that sets the dbus session bus to be the one thats owned by the user user even in other users? | 12:39 |
| uvos | this breaks quite a few things | 12:39 |
| Wizzup | probably because without it, everything breaks :) | 12:41 |
| uvos | right but what is everything | 12:41 |
| uvos | because this is really broken | 12:41 |
| Wizzup | what does it break for you? | 12:42 |
| uvos | it breaks pulse if not in system mode | 12:42 |
| uvos | and it breaks gsettings | 12:42 |
| uvos | gesettings particually is impossible to use with this hack | 12:42 |
| uvos | in a fairly sublte way: | 12:42 |
| uvos | glib reads dconf keys directly, only writing goes thugh the deamon via dbus. | 12:43 |
| uvos | so with this hack | 12:43 |
| uvos | any application using gesettings writes values to the store of the user user | 12:43 |
| uvos | but reads its settings from whatever user its running as | 12:43 |
| Wizzup | what other user do you run the apps as, if not 'user'? | 12:44 |
| uvos | well lots of stuff runs as root, plenty of stuff also drops privilages to nobody or whatever | 12:45 |
| uvos | experiamenting: it also breaks all kde applications | 12:46 |
| uvos | they read settings from ~ ini files | 12:47 |
| uvos | and inform eatch other of settings changes via dbus | 12:47 |
| Wizzup | bencoh: looks like the dns problem might be a real problem in the image generation | 12:47 |
| Wizzup | uvos: and they don't get the dbus address somehow? | 12:48 |
| uvos | they get get the bus from the evvars | 12:48 |
| uvos | which af services sets to user | 12:48 |
| Wizzup | so how does that break them? | 12:49 |
| Wizzup | I don't understand | 12:49 |
| uvos | they read from ~/.config | 12:49 |
| uvos | but then they inform eatch other via dbus | 12:49 |
| Wizzup | what insane behaviour | 12:49 |
| uvos | gesettings works the same | 12:49 |
| uvos | its not really insane | 12:49 |
| Wizzup | probably to work around slowness in dbus? | 12:49 |
| uvos | no because in kde there is no central settings repo | 12:50 |
| uvos | so eg kwrite owns its ini file | 12:50 |
| Wizzup | it looks like the dns problem shouldn't be too serious at least | 12:50 |
| uvos | and if some other app wants to know when the settings changes | 12:50 |
| uvos | it registers a dbus listener | 12:50 |
| uvos | for gsettings yeah i think its for paralellisum | 12:51 |
| uvos | anyhow it also breaks pulse | 12:51 |
| uvos | btw osso-af-startup is extream mess in other ways too | 12:53 |
| uvos | it dose lots of stuff thats not applicable and some stuff thats damageing | 12:53 |
| sicelo | k-apps :-p | 13:53 |
| Wizzup | + ssh amprolla@maedevu.maemo.org -- mkdir -p images/droid4/20220403 | 14:17 |
| Wizzup | Host key verification failed. | 14:17 |
| Wizzup | + exit 1 | 14:17 |
| Wizzup | oh well | 14:17 |
| Wizzup | will fix that in a little bit | 14:17 |
| Wizzup | sicelo and others, I pushed some wip news post here https://github.com/maemo-leste/maemo-leste.github.io/blob/source/content/maemo-leste-update-april-2022.rst | 14:31 |
| uvos | what happend with parazyd anyhow? | 14:50 |
| uvos | not to pry | 14:50 |
| uvos | idk about stability wrt omap drivers :P | 14:51 |
| mighty17[m] | freemangordon: http://muru.com/linux/d4/0001-egl-dri2-Workaround-for-EGL_EXT_image_dma_buf_import.patch going thru logs, what is this ? | 14:51 |
| freemangordon | mighty17[m]: ummm.... "Signed-off-by: Tony Lindgren <tony@atomide.com>" | 14:59 |
| mighty17[m] | freemangordon: oh my bad, also why did you revert https://github.com/maemo-leste-upstream-forks/mesa/commit/a673ae59b0edd281a20060080554f96331978aa3 | 14:59 |
| freemangordon | because of "if (dri2_dpy->image->base.version >= 8" | 15:00 |
| freemangordon | well, because at that time it was working without that patch | 15:01 |
| freemangordon | because tehre are more checks nad this patch alone is just a hack | 15:02 |
| freemangordon | but later it got broken by upstream mesa | 15:02 |
| freemangordon | so now it insists on having that extension which was not like that back then | 15:03 |
| mighty17[m] | <mighty17[m]> "freemangordon: http://muru.com/..." <- wouldnt this work here | 15:04 |
| mighty17[m] | ` if (dri2_dpy->image->base.version >= 15 &&` | 15:04 |
| freemangordon | sorry, I don;t understand what you are asking | 15:05 |
| mighty17[m] | freemangordon: now it can be applied (as a hack) and it should fix it....? | 15:05 |
| freemangordon | maybe | 15:05 |
| freemangordon | but rather not | 15:05 |
| mighty17[m] | freemangordon: tmlind's patch.. instead of reverting why not apply that | 15:05 |
| freemangordon | becasue it is a hack too | 15:05 |
| freemangordon | the correct thing is to implement callback in PVR driver to return the supported buffer formats | 15:06 |
| mighty17[m] | oh :( | 15:06 |
| freemangordon | otherwise the applications will just get an emopty list | 15:06 |
| freemangordon | *empty | 15:06 |
| freemangordon | or incorrect | 15:06 |
| mighty17[m] | or we just tell applications we dont support it? | 15:06 |
| freemangordon | we cannot tell that as it is mandated by mesa | 15:06 |
| freemangordon | we must support it | 15:07 |
| mighty17[m] | but our blobs dont do it right... | 15:07 |
| freemangordon | blobs? why blobs? | 15:07 |
| mighty17[m] | powervr...? | 15:07 |
| freemangordon | it is not about the blobs | 15:08 |
| freemangordon | it is about mesa pvr driver | 15:08 |
| freemangordon | it must implement that missing piece, even by returning hardcoded data | 15:08 |
| mighty17[m] | oh this is pretty complicated for me :o | 15:08 |
| freemangordon | sec | 15:09 |
| mighty17[m] | freemangordon: so basically, what pvr mesa we use (from chromium) is so old it doesnt support that extension | 15:09 |
| freemangordon | yes | 15:09 |
| freemangordon | see https://github.com/maemo-leste/sgx-ddk-um/blob/master/dbm/dbm.c#L476 | 15:10 |
| freemangordon | this is REed pvr blobs libdbm | 15:10 |
| mighty17[m] | but https://github.com/maemo-leste-upstream-forks/mesa/commit/6719e058d6b8a38cc66accf1609fcabb66571e86 was added in 18.x and chromium mesa was 19.x? | 15:10 |
| freemangordon | so? | 15:10 |
| freemangordon | the driver itself implements v8 | 15:10 |
| freemangordon | of base_image | 15:11 |
| mighty17[m] | freemangordon: oh wait when did this happen :o | 15:11 |
| freemangordon | umm, what you mean? | 15:11 |
| freemangordon | see the commit log | 15:11 |
| mighty17[m] | ie RE of sgx-ddk-um :P | 15:11 |
| freemangordon | see the commit log | 15:11 |
| freemangordon | only this is lib REed | 15:12 |
| mighty17[m] | right right, so we gotta implement v9 and so on? | 15:12 |
| freemangordon | no, we need to implement queryDmaBufFormats (IIRC) | 15:12 |
| freemangordon | but it was a while, it could have been something else we must implement | 15:13 |
| freemangordon | it is just one function | 15:13 |
| mighty17[m] | `.queryDmaBufFormats= PVRDRIQueryDmaBufFormats,` we already have it... maybe something else | 15:14 |
| freemangordon | yeah, we must implement eglQueryDmaBufFormats as now it returns NULL formats | 15:14 |
| freemangordon | yeah, maybe something else, I don;t remember | 15:14 |
| mighty17[m] | yes correct | 15:14 |
| mighty17[m] | https://github.com/xc-racer99/mesa-pvr/blob/mesa-20.3.2-pvr-musl-2/src/mesa/drivers/dri/pvr/pvrext.c#L224 xc-racer has it | 15:15 |
| freemangordon | but it calls in the blobs | 15:16 |
| freemangordon | na dthis is not supported in our blobs | 15:16 |
| mighty17[m] | riight i am getting it slowly | 15:16 |
| freemangordon | *and this | 15:16 |
| freemangordon | so we return EGL_SUCCESS and empty list | 15:16 |
| freemangordon | or somesuch | 15:16 |
| mighty17[m] | thats a hack :P | 15:16 |
| mighty17[m] | freemangordon: our blobs ie the one you RE'd? | 15:16 |
| freemangordon | no | 15:17 |
| freemangordon | the real blobc | 15:17 |
| freemangordon | pvr_dri_support.so | 15:17 |
| freemangordon | (IIRC) | 15:17 |
| mighty17[m] | so his mesa is broken? | 15:17 |
| freemangordon | it doesn't have the needed function exported | 15:17 |
| freemangordon | no idea | 15:17 |
| mighty17[m] | im confused, if blobs dont support it why'd it be in mesa | 15:17 |
| freemangordon | becasue this is crhomioumos mesa | 15:18 |
| freemangordon | for different driver | 15:18 |
| freemangordon | not for ours | 15:18 |
| freemangordon | thats why I REed pvr_dri.so that came with our blobs | 15:19 |
| mighty17[m] | ohhh damn | 15:19 |
| mighty17[m] | freemangordon: so atleast we know what func we have :D | 15:19 |
| freemangordon | so what we have in *our* mesa is exactly what comes with DDK 1.17 blobs | 15:19 |
| mighty17[m] | so basically we need to implement what chromiumos mesa had but with funcs in our blobs | 15:19 |
| freemangordon | exactly | 15:19 |
| freemangordon | or just hardcode | 15:20 |
| Wizzup | uvos: @ what happened, your guess is a good as mine | 15:20 |
| uvos | Wizzup: ok | 15:20 |
| * freemangordon is afk | 15:20 | |
| uvos | Wizzup: newspost looks correct otherwise | 15:20 |
| mighty17[m] | freemangordon: oooh thanks for the guide! | 15:21 |
| Wizzup | in another month or so I'll remove his ssh keys | 15:21 |
| Wizzup | uvos: ok, if you have more things you think should be added lmk | 15:21 |
| uvos | salutem maybe? | 15:21 |
| uvos | maybe distobute the newspost via salutem :P | 15:22 |
| Wizzup | was thinking about that | 15:27 |
| Wizzup | yeah | 15:27 |
| sicelo | I can somewhat confirm parazyd is fine where he is. I dropped him a message on Facebook a couple of weeks ago | 15:29 |
| bencoh | sicelo: oh, that's a good start, if you received some kind of answer | 15:40 |
| sicelo | When charging, wouldn't it be a good idea to use a different LED color while charging and when full? Anything that prevents this? (Referring to Droid 4) | 18:45 |
| Wizzup | droid4 has the led override still | 18:48 |
| Wizzup | so it always shows the green one | 18:49 |
| uvos | charge led is forced by hardware | 19:15 |
| uvos | theres a register bit thats called disable_charge_led in moto kernel sources | 19:16 |
| uvos | but changing it stops charging entirely for some resaon | 19:16 |
| uvos | so maybe its misslabled | 19:16 |
| uvos | clearly charging with the led is disabled is possible, as android dose so, so really you would just have to diff the registers between android and mainline chargeing | 19:17 |
| uvos | should not be hard to figure out, but its not a priority | 19:17 |
| mighty17[m] | freemangordon: my try on adding support https://paste.debian.net/1236679/ (old code in comments to refer) basically we do not have `bool *pbHasFormat` and `int iNumFormats;` anymore after your RE, using intel as reference as well https://github.com/xc-racer99/mesa-pvr/blob/mesa-20.3.2-pvr-musl-2/src/mesa/drivers/dri/i965/intel_screen.c#L1348 which basically sets `int *formats` and `int *count` according to the supported extensions | 20:22 |
| mighty17[m] | (intel_image_formats/g_asFormats for us) | 20:22 |
| freemangordon | mighty17[m]: sorry, cannot help further without spending some time I don;t have now | 20:23 |
| mighty17[m] | oh alrighty, feel free to have a look once you're free and ping me, its my first time doing it so 😅 | 20:26 |
| freemangordon | well, better do not wait for me, I am not sure I will have time for that soon | 20:27 |
| mighty17[m] | i am unsure if what im doing is correct anyways :P | 20:33 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!