Anasko has quit [Remote host closed the connection]
Anasko has joined #maemo-leste
hm has quit [Remote host closed the connection]
System_Error has quit [Remote host closed the connection]
System_Error has joined #maemo-leste
joerg is now known as Guest2373
Guest2373 has quit [Killed (zirconium.libera.chat (Nickname regained by services))]
joerg has joined #maemo-leste
gnarface has quit [Ping timeout: 260 seconds]
gnarface has joined #maemo-leste
xmn has quit [Quit: Leaving]
xmn_ has joined #maemo-leste
xmn has joined #maemo-leste
xmn_ has quit [Ping timeout: 276 seconds]
ceene has joined #maemo-leste
_fab has quit [Ping timeout: 260 seconds]
<sicelo>
Wizzup: i think leste needs a porting guide :-)
<sicelo>
but i guess, -ETIME
_fab has joined #maemo-leste
<sicelo>
i'll see if i can do a basic one
ungeskriptet has quit [Ping timeout: 245 seconds]
ungeskriptet_ has joined #maemo-leste
ungeskriptet_ is now known as ungeskriptet
<sicelo>
uvos: i would like to get maemo-leste-upstream-forks/iio-sensor-proxy archived, then we replace it with a new iio-sensor-proxy directly from upstream (version 3.7). this has most of the patches that made the leste fork necessary in the first place
pere has quit [Ping timeout: 265 seconds]
<sicelo>
plus support for N900's proximity sensor. the only thing missing is support for uncalibrated compasses. however, per our discussion last time, it really isn't working anyway, since D4-side there's something not right to begin with.
<sicelo>
the aim of this move is to drop the fork entirely - we will only have it for now just because daedalus is on a lower iio-sp version. by excalibur we shouldn't need it at all (i *think* debian should have 3.7 by the time trixie releases)
<sicelo>
do you have any comments/objections before i ask Wizzup to do it? i'm ready to submit the MR (or of course you can, if your time schedule allows)
ceene has quit [Read error: Connection reset by peer]
ceene has joined #maemo-leste
pere has joined #maemo-leste
ceene has quit [Remote host closed the connection]
ceene has joined #maemo-leste
pabs3 has quit [Killed (lithium.libera.chat (Nickname regained by services))]
pabs3 has joined #maemo-leste
ceene has quit [Remote host closed the connection]
<Wizzup>
sicelo: yes @ porting guide
<sicelo>
i'm not good with documenting stuff, but i'll try my best ... since i intend to finalize the L5 port soon
ceene has joined #maemo-leste
<sicelo>
btw do you have any rough date that you're working towards in terms of daedalus release? i have a couple of time constraints my end too, but it'd be awesome if L5 integration would land at the same time :-)
halftux has joined #maemo-leste
<halftux>
sicelo: I could make a porting guide but you need to teach me first. I also own a L5
mkfx has left #maemo-leste [Error from remote client]
apac has joined #maemo-leste
<Wizzup>
sicelo: not really, I guess once we fix everything
<sicelo>
halftux: oh nice! i was thinking to mostly use the kernel from Mobian
<halftux>
sicelo: and what image you are using as a base for replacing kernel and modules with Mobian's?
<sicelo>
i used PP image
<sicelo>
maybe now we have a working generic arm64 image again ... haven't checked
n900 has quit [Ping timeout: 268 seconds]
<Wizzup>
working on the images
mkfx has joined #maemo-leste
<Wizzup>
(I also just got 2.5 Gbit/s at home so I'm planning to host more at home here, which will make things easier)
<donihalim>
Wizzup: just curious how much you paid for 2.5G?
<Wizzup>
I think 35 euro
<Wizzup>
around there, maybe a few euro more for a static ip
<uvos__>
sicelo: yes thats correct the compass is currently broken at the kernel level on d4
<uvos__>
sicelo: since we have no userspace that uses it i am ok with removing it for now
<uvos__>
sicelo: i dont have perms to archive that repo but i agree we can do so. is 3.7 the version in the devuan repos?
<uvos__>
or shoud do we have to build newer upstream?
<uvos__>
ah i see
<uvos__>
if we build newer upstream
<uvos__>
we should not archve the repo
<uvos__>
instead we should park our fork in some branch
<donihalim>
35 euro thats really cheap for 2.5Gb internet
<uvos__>
and force push master to the upstream version
<uvos__>
i can do that
<donihalim>
Btw good news, messages from whatsapp bridge actually showed on conversations app
<Wizzup>
which bridge are you using?
<donihalim>
But irc bridge dont, maybe it needs some time to sync?
<donihalim>
Wizzup: mautrix-whatsapp
<donihalim>
And heisenbridge for irc
<Wizzup>
donihalim: does that still require an ios/android device somewhere?
<Wizzup>
hm, seems to use android vm
<donihalim>
I think yes, for login with the qr code
<donihalim>
Sure android vm should work
<donihalim>
From the wiki: Please note that the bridge uses the web API. If the phone is offline for >2 weeks, linked devices will become disconnected:
<Wizzup>
yeah
apac has quit [Ping timeout: 252 seconds]
<donihalim>
I notice that everytime i rebooted the phone or set availability to offline matrix reconnected with different device/session id
<Wizzup>
it's quite possible that we don't have any persistent storage yet for matrix
<donihalim>
Ah that's why
<sicelo>
uvos__: i'm ok with that approach too. so yes, we're doing upstream so we can already get all of the other goodies (n900 prox, compass on dbus without geoclue, face/up down, etc.)
<sicelo>
uvos__: fwiw, what may interest you - with 3.7, d4 and N900 will be using iio-sp buffer driver instead of the manual polling. still not using interrupts though, but i guess it's a bit of improvement
Anasko has quit [Ping timeout: 248 seconds]
hm has joined #maemo-leste
_fab has quit [Quit: _fab]
xmn has quit [Read error: Connection reset by peer]
pere has quit [Remote host closed the connection]
pere has joined #maemo-leste
xmn has joined #maemo-leste
_fab has joined #maemo-leste
apac has joined #maemo-leste
xmn has quit [Ping timeout: 276 seconds]
uvos__ has quit [Ping timeout: 268 seconds]
<freemangordon>
Wizzup: do you have a list of tasks for daedalus to become ready?
<sicelo>
i seem to think i mentioned last time this is an opportunity for your first Leste MR ... i.e. you can submit MR with that keymap :-)
<sicelo>
you won't be 'stealing' it from pmOS ... it largely comes from Maemo Fremantle and Arch Linux that was once available for N900
arno11 has joined #maemo-leste
<donihalim>
sicelo that's a good idea, lets see what i can do:)
<arno11>
Wizzup: @bunch of changes from arno11 to leste-config: AFAIK everything is already merged and working apart transitions file.
<Wizzup>
That change, then :)
pere has joined #maemo-leste
<donihalim>
sicelo it's working, thanks :)
<arno11>
Wizzup: ok :)
<sicelo>
donihalim: yw
<freemangordon>
sicelo: do you have any feedback from upstream upower?
<sicelo>
unfortunately fdo gitlab is in migration (which will last a while). otherwise, the current maintainer was welcoming of the idea
<sicelo>
basically someone just needs to write some code and make an MR :-)
<freemangordon>
cool
halftux has left #maemo-leste [#maemo-leste]
<freemangordon>
If we have clear requirements, I can write the code. do we have an issue with what has to be done?
<sicelo>
1. There is no problem if the fuel gauge is calibrated (or at least reporting a percentage)
<sicelo>
2. So the problem is with uncalibrated fuel gauges, reporting 0%, 0mAh, 0W. even if the gauge does not report the property at all, the g_udev function that does the read will return 0 ... so there's no difference between not reporting anything and reporting 0
<Wizzup>
is this only for n900 or also other devices?
<sicelo>
Droid 4 too
<Wizzup>
btw, the other upower thing that we must need is that it doesn't shut down our device
<Wizzup>
that is maybe in latest master but not in daedalus
<sicelo>
2a. if upower sees the 0, it then initiates a shutdown
<sicelo>
so what we want to do (to benefit N900 and Droid 4):
<sicelo>
1. take capacity_level into account ... so basically when you have a 0, you also check if capacity_level reports Critical or at least Low.
<sicelo>
1a. we don't want to derive a percentage (what we have been doing all along with spinal's patches). so probably best idea/option is to add a new dbus property (something like "kernel-level"), which simply follows whatever is in capacity_level
<sicelo>
1b. with this, inside upower, we can report action level (i.e. when upower shuts down device) when both the 0 and Low/Critical are reported
<sicelo>
1c. also, by exporting this via dbus, status-battery can be taught to display some battery bars even when we have 0 percent displayed
<sicelo>
1d. if upstream doesn't want to do what i propose in 1b. above, we can let it be, but use the new upower feature that allows upower to not shutdown device even when it determines that action needs to be taken. we would then have our own thing that listens to that dbus signal, checks capacity_level/kernel-level, and takes the appropriate action. this would be a very simple program
<sicelo>
that's basically it, as best as i understand it (and i think i do, haha ... having spent quite a bit of time on upower and the N900 fuel gauge in connection with pmOS)
<freemangordon>
please, open an issue on github with ^^^ info
<sicelo>
... gawd the N900 takes aeons to poweroff. i should make some time to look at it
<sicelo>
freemangordon: sure, will do.
<Wizzup>
we also want to make sure that upower never initiates a shutdown for us
<Wizzup>
in case we port to a device where we can't read the battery yet, etc
<sicelo>
we can have this for free with up-to-date upower (as indicated in 1d above). upower now has a setting you can enable to tell it to do nothing, i.e, completely drain your battery
<sicelo>
Wizzup: so we can ship appropriate config on such devices (including D4 and N900)
<Wizzup>
yes, but to make it clear: bookworm upstream is not new enough
<Wizzup>
(bookworm=daedalus)
<Wizzup>
so we *still* have to build it
<sicelo>
yes
<arno11>
sicelo: yeah n900 poweroff is still an issue but not so critical (around a min on daedalus). qt5 slow launch is a bigger problem imo. even if it is easy to workaround, something is wrong somewhere. btw is it noticeable on d4 ?
<arno11>
seems related to new pvr btw, but definitely over my skills
<sicelo>
ah, i don't think i've tried any qt application yet :-)
<sicelo>
oh, i've received SMSes, so Conversations
<arno11>
conversations is ok because already running in background
<arno11>
so no real issue with it by default
<arno11>
for other qt5 apps, that's different story...even with osso-calculator
xmn has joined #maemo-leste
<freemangordon>
arno11: haven't noticed anything unusual on d4
<freemangordon>
but not using it much
<freemangordon>
lemme boot my d4 to check
<arno11>
ok, is it a fresh img or dist-upgrade ?
<freemangordon>
dist-upgrade
<freemangordon>
calculator launches in ~ 3 seconds
<arno11>
ah ok, because even on n900, Wizzup did'nt notice the slowness from dist-upgrade iirc
<arno11>
ok, got the same result on n900 but with raster
mkfx has left #maemo-leste [Error from remote client]
<arno11>
by default, it is 10 sec to start calculator lol
<freemangordon>
hmm
<freemangordon>
ok, I might have a look during the weekend
<arno11>
:D could be really cool :D
akossh has joined #maemo-leste
ikmaak has quit [Ping timeout: 260 seconds]
ikmaak2 has joined #maemo-leste
ikmaak2 is now known as ikmaak
<arno11>
Wizzup: btw i got picodrive finally working fullscreen and fullspeed with sdl in daedalus. but for that, i need to rebase it -only- for daedalus. so i suppose i just have to create an empty daedalus branch in pico repo and fork the 'mainline' pico i need, right ? or is there a better way ?
<arno11>
perfs are amazing: 32x 3D games like Virtua Racing run @60fps on N900 ! (with compo off ofc)
apac has joined #maemo-leste
apac has quit [Ping timeout: 245 seconds]
kiva has joined #maemo-leste
<Wizzup>
arno11: yes, I think you cna make a new branch, change master, rebase, whichever you prefer
<Wizzup>
the branches don't need to share any history
_fab has quit [Quit: _fab]
kiva has quit [Quit: Client closed]
kiva has joined #maemo-leste
<kiva>
Weeks in Calendar App looking good now Pinephone, thanks for updater!
Anasko has joined #maemo-leste
<kiva>
It seems that there is two new sd-card images for Pinephone is that not Chimera image Daedalus or what?
LjL has quit [Read error: Connection reset by peer]
LjL has joined #maemo-leste
kiva has quit [Quit: Client closed]
<arno11>
kiva: all seem chimaera
<arno11>
Wizzup: ok ty
<Wizzup>
yes, pine for daedalus needs some work on my end still
<Wizzup>
(or hopefully someone else :D)
norayr has joined #maemo-leste
akossh has quit [Ping timeout: 260 seconds]
arno11 has left #maemo-leste [#maemo-leste]
Anasko has quit [Remote host closed the connection]