duuude is now known as netop
netop is now known as duuude
Pali has quit [Ping timeout: 260 seconds]
pagurus has quit [Ping timeout: 260 seconds]
pagurus has joined #maemo-leste
joerg has quit [Ping timeout: 246 seconds]
joerg has joined #maemo-leste
macros_2ndPC has quit [Ping timeout: 260 seconds]
macros_2ndPC has joined #maemo-leste
mardy has joined #maemo-leste
hexagonwin has joined #maemo-leste
hexagonwin has quit [Remote host closed the connection]
avoidr has joined #maemo-leste
<Wizzup> uvos: I see yourt new patches for hp detect using new apis, mabye we should go for new kernel in -devel ?
pere has quit [Ping timeout: 260 seconds]
pere has joined #maemo-leste
duuude has quit [Ping timeout: 260 seconds]
<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
<Wizzup> all image builds seem to fail like this:
<Wizzup> I: Base system installed successfully.
<Wizzup> blend_bootstrap_setup:3: number expected
<Wizzup> seems to maybe be this? [[ -n "$armsdk_version" ]] && req +=(device_name)
<Wizzup> maybe it's related to the key expiry somehow
<Wizzup> trying now
<Wizzup> looks like that was it
<Wizzup> good
<freemangordon> :)
<Wizzup> freemangordon: which pkgs do I install to check out the rtcom work?
<Wizzup> rtcom-accounts-ui ?
<Wizzup> and librtcom-accounts-ui-client0 ?
<Wizzup> ah, the my information was from abook
<freemangordon> umm, yes
<freemangordon> otherwise installing rtcom-accounts-ui will pull everything needed (in theory)
<Wizzup> what should I see once I install that
<Wizzup> no cpa plugin, right?
<freemangordon> a new entry in cpl
<freemangordon> yes, there is
<freemangordon> "voip and im accounts"
<Wizzup> ok
<Wizzup> I see it now
<Wizzup> I guess I was so used to it on my n900
<Wizzup> :)
<Wizzup> it shows an empty wizard atm
<Wizzup> as expected I guess
<freemangordon> yeah, I know
<freemangordon> mhm
<Wizzup> :)
<Wizzup> man, so much changed for the news post, going to take some hours to finish this
<Wizzup> I'll make a pdf out of it when I am done and invite some comment
<Wizzup> (I won't push it to a hidden url like last time, since people picked it up with rss)
<freemangordon> :)
<Wizzup> Err:1 https://maedevu.maemo.org/leste beowulf InRelease Temporary failure resolving 'maedevu.maemo.org'
<Wizzup> *sigh*
<bencoh> DNS seems fine from here (?)
<Wizzup> bencoh: yeah it is the temporary failure in the image build (which also doesn't cause a fatal error) that's annoying
<Wizzup> there are some things in arm-sdk that just don't cause fatal errors and it's really annoying
<Wizzup> I don't have the zsh knowhow to fix it
Twig has joined #maemo-leste
<bencoh> is there a reason why it would temporarily fail to resolve though?
<Wizzup> no idea
<bencoh> ah
<bencoh> you could add set -e at the top of the script btw
norayr has joined #maemo-leste
<bencoh> you'll get a lot of false positives at first, but at least it should catch everything
<Wizzup> does that work with zsh?
<bencoh> hmm
<bencoh> (damn, bash: zsh: command not found :D lemme check)
<bencoh> looks like it works, yeah
uvos has joined #maemo-leste
<uvos> Wizzup: the newer code is only different in implementation, functionally its the same
<uvos> Wizzup: but yes we should update the kernel as allways
<Wizzup> mhm
<lel> MerlijnWajer created a repository: https://github.com/maemo-leste-extras/cssufeatures
Pali has joined #maemo-leste
<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?
<uvos> this breaks quite a few things
<Wizzup> probably because without it, everything breaks :)
<uvos> right but what is everything
<uvos> because this is really broken
<Wizzup> what does it break for you?
<uvos> it breaks pulse if not in system mode
<uvos> and it breaks gsettings
<uvos> gesettings particually is impossible to use with this hack
<uvos> in a fairly sublte way:
<uvos> glib reads dconf keys directly, only writing goes thugh the deamon via dbus.
<uvos> so with this hack
<uvos> any application using gesettings writes values to the store of the user user
<uvos> but reads its settings from whatever user its running as
<Wizzup> what other user do you run the apps as, if not 'user'?
<uvos> well lots of stuff runs as root, plenty of stuff also drops privilages to nobody or whatever
<uvos> experiamenting: it also breaks all kde applications
<uvos> they read settings from ~ ini files
<uvos> and inform eatch other of settings changes via dbus
<Wizzup> bencoh: looks like the dns problem might be a real problem in the image generation
<Wizzup> uvos: and they don't get the dbus address somehow?
<uvos> they get get the bus from the evvars
<uvos> which af services sets to user
<Wizzup> so how does that break them?
<Wizzup> I don't understand
<uvos> they read from ~/.config
<uvos> but then they inform eatch other via dbus
<Wizzup> what insane behaviour
<uvos> gesettings works the same
<uvos> its not really insane
<Wizzup> probably to work around slowness in dbus?
<uvos> no because in kde there is no central settings repo
<uvos> so eg kwrite owns its ini file
<Wizzup> it looks like the dns problem shouldn't be too serious at least
<uvos> and if some other app wants to know when the settings changes
<uvos> it registers a dbus listener
<uvos> for gsettings yeah i think its for paralellisum
<uvos> anyhow it also breaks pulse
<uvos> btw osso-af-startup is extream mess in other ways too
<uvos> it dose lots of stuff thats not applicable and some stuff thats damageing
xmn has quit [Quit: ZZZzzz…]
<sicelo> k-apps :-p
Danct12 has joined #maemo-leste
<Wizzup> + ssh amprolla@maedevu.maemo.org -- mkdir -p images/droid4/20220403
<Wizzup> Host key verification failed.
<Wizzup> + exit 1
<Wizzup> oh well
<Wizzup> will fix that in a little bit
norayr has left #maemo-leste [Error from remote client]
<uvos> what happend with parazyd anyhow?
<uvos> not to pry
<uvos> idk about stability wrt omap drivers :P
<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 ?
<freemangordon> mighty17[m]: ummm.... "Signed-off-by: Tony Lindgren <tony@atomide.com>"
<freemangordon> because of "if (dri2_dpy->image->base.version >= 8"
<freemangordon> well, because at that time it was working without that patch
<freemangordon> because tehre are more checks nad this patch alone is just a hack
<freemangordon> but later it got broken by upstream mesa
<freemangordon> so now it insists on having that extension which was not like that back then
<mighty17[m]> <mighty17[m]> "freemangordon: http://muru.com/..."; <- wouldnt this work here
<mighty17[m]> ` if (dri2_dpy->image->base.version >= 15 &&`
<freemangordon> sorry, I don;t understand what you are asking
<mighty17[m]> freemangordon: now it can be applied (as a hack) and it should fix it....?
<freemangordon> maybe
<freemangordon> but rather not
<mighty17[m]> freemangordon: tmlind's patch.. instead of reverting why not apply that
<freemangordon> becasue it is a hack too
<freemangordon> the correct thing is to implement callback in PVR driver to return the supported buffer formats
<mighty17[m]> oh :(
<freemangordon> otherwise the applications will just get an emopty list
<freemangordon> *empty
<freemangordon> or incorrect
<mighty17[m]> or we just tell applications we dont support it?
<freemangordon> we cannot tell that as it is mandated by mesa
<freemangordon> we must support it
<mighty17[m]> but our blobs dont do it right...
<freemangordon> blobs? why blobs?
<mighty17[m]> powervr...?
<freemangordon> it is not about the blobs
<freemangordon> it is about mesa pvr driver
<freemangordon> it must implement that missing piece, even by returning hardcoded data
<mighty17[m]> oh this is pretty complicated for me :o
<freemangordon> sec
<mighty17[m]> freemangordon: so basically, what pvr mesa we use (from chromium) is so old it doesnt support that extension
<freemangordon> yes
<freemangordon> this is REed pvr blobs libdbm
<freemangordon> so?
<freemangordon> the driver itself implements v8
<freemangordon> of base_image
<mighty17[m]> freemangordon: oh wait when did this happen :o
<freemangordon> umm, what you mean?
<freemangordon> see the commit log
<mighty17[m]> ie RE of sgx-ddk-um :P
<freemangordon> see the commit log
<freemangordon> only this is lib REed
<mighty17[m]> right right, so we gotta implement v9 and so on?
<freemangordon> no, we need to implement queryDmaBufFormats (IIRC)
<freemangordon> but it was a while, it could have been something else we must implement
<freemangordon> it is just one function
<mighty17[m]> `.queryDmaBufFormats= PVRDRIQueryDmaBufFormats,` we already have it... maybe something else
<freemangordon> yeah, we must implement eglQueryDmaBufFormats as now it returns NULL formats
<freemangordon> yeah, maybe something else, I don;t remember
<mighty17[m]> yes correct
<freemangordon> but it calls in the blobs
<freemangordon> na dthis is not supported in our blobs
<mighty17[m]> riight i am getting it slowly
<freemangordon> *and this
<freemangordon> so we return EGL_SUCCESS and empty list
<freemangordon> or somesuch
<mighty17[m]> thats a hack :P
<mighty17[m]> freemangordon: our blobs ie the one you RE'd?
<freemangordon> no
<freemangordon> the real blobc
<freemangordon> pvr_dri_support.so
<freemangordon> (IIRC)
<mighty17[m]> so his mesa is broken?
<freemangordon> it doesn't have the needed function exported
<freemangordon> no idea
<mighty17[m]> im confused, if blobs dont support it why'd it be in mesa
<freemangordon> becasue this is crhomioumos mesa
<freemangordon> for different driver
<freemangordon> not for ours
<freemangordon> thats why I REed pvr_dri.so that came with our blobs
<mighty17[m]> ohhh damn
<mighty17[m]> freemangordon: so atleast we know what func we have :D
<freemangordon> so what we have in *our* mesa is exactly what comes with DDK 1.17 blobs
<mighty17[m]> so basically we need to implement what chromiumos mesa had but with funcs in our blobs
<freemangordon> exactly
<freemangordon> or just hardcode
<Wizzup> uvos: @ what happened, your guess is a good as mine
<uvos> Wizzup: ok
* freemangordon is afk
<uvos> Wizzup: newspost looks correct otherwise
<mighty17[m]> freemangordon: oooh thanks for the guide!
<Wizzup> in another month or so I'll remove his ssh keys
<Wizzup> uvos: ok, if you have more things you think should be added lmk
<uvos> salutem maybe?
<uvos> maybe distobute the newspost via salutem :P
<Wizzup> was thinking about that
<Wizzup> yeah
<sicelo> I can somewhat confirm parazyd is fine where he is. I dropped him a message on Facebook a couple of weeks ago
q655778 has joined #maemo-leste
Guest9123 has joined #maemo-leste
q655778 has quit [Client Quit]
Guest9123 has quit [Client Quit]
G54 has joined #maemo-leste
G54 has quit [Client Quit]
<bencoh> sicelo: oh, that's a good start, if you received some kind of answer
duuude has joined #maemo-leste
pere has quit [Ping timeout: 260 seconds]
hexagonwin_ has joined #maemo-leste
duuude has quit [Ping timeout: 260 seconds]
pere has joined #maemo-leste
duuude has joined #maemo-leste
<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)
<Wizzup> droid4 has the led override still
<Wizzup> so it always shows the green one
<uvos> charge led is forced by hardware
<uvos> theres a register bit thats called disable_charge_led in moto kernel sources
<uvos> but changing it stops charging entirely for some resaon
<uvos> so maybe its misslabled
<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
<uvos> should not be hard to figure out, but its not a priority
xmn has joined #maemo-leste
tvall has joined #maemo-leste
<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
<mighty17[m]> (intel_image_formats/g_asFormats for us)
<freemangordon> mighty17[m]: sorry, cannot help further without spending some time I don;t have now
<mighty17[m]> oh alrighty, feel free to have a look once you're free and ping me, its my first time doing it so 😅
<freemangordon> well, better do not wait for me, I am not sure I will have time for that soon
<mighty17[m]> i am unsure if what im doing is correct anyways :P
duuude has quit [Ping timeout: 260 seconds]
duuude has joined #maemo-leste
Danct12 has quit [Remote host closed the connection]
Danct12 has joined #maemo-leste
Twig has quit [Remote host closed the connection]
duuude has quit [Ping timeout: 260 seconds]
duuude has joined #maemo-leste
norayr has joined #maemo-leste
mardy has quit [Quit: WeeChat 2.8]
duuude has quit [Ping timeout: 252 seconds]
uvos has quit [Read error: Connection reset by peer]
duuude has joined #maemo-leste
uvos has joined #maemo-leste
duuude has quit [Ping timeout: 250 seconds]
elastic_dog has quit [Ping timeout: 252 seconds]
elastic_dog has joined #maemo-leste
duuude has joined #maemo-leste
uvos has quit [Ping timeout: 256 seconds]