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/!