<tmlind>
freemangordon: sounds like you got something working :)
<tmlind>
freemangordon: one more thing for an idea.. we should get bus notifications on usb gadget enumerated, not sure if we can also query the configured max current
<tmlind>
i'd assume we could listen for BUS_NOTIFY_ADD_DEVICE that will likely happen after gadget has been configured
xmn has quit [Ping timeout: 256 seconds]
Daanct12 has joined #maemo-leste
xmn has joined #maemo-leste
xmn has quit [Quit: xmn]
joerg is now known as Guest9398
joerg has joined #maemo-leste
Guest9398 has quit [Ping timeout: 256 seconds]
mardy has joined #maemo-leste
Twig has joined #maemo-leste
<freemangordon>
tmlind: maybe, but why do extra work if this already comes through usb_charger framework?
<freemangordon>
what I got working is charger detection and current limit :)
<freemangordon>
I think it can be done better in cpcap usb phy driver though, like, before the patch ^^^ patch it was switching to USB on VBUS, without waiting for CPCAP_BIT_CHRG_DET_S
<freemangordon>
android kernel waits until there is no charge in sense registers before making decision on what to do
<freemangordon>
I think we shall do the same
<freemangordon>
another question - is it ok (from the architectural POV) to embed extcon driver code in phy driver? because now we have more or less duplicated code and race.
<freemangordon>
so, I am waiting for your comments before sending some parts for upstreaming
<tmlind>
freemangordon: probably best to discuss the extcon stuff on the mailing lists to avoid extra work
<tmlind>
sre might have some ideas
<freemangordon>
sure, but what about phy driver?
<freemangordon>
it is your name there
<freemangordon>
but ok, I might send some RFC patch
<freemangordon>
though, sre looks like overloaded
<tmlind>
sure phy if no better place is found, we want to avoid circular module dependencies though between charging and usb :)
<tmlind>
best to keep usb phy and usb functionality working standalone without charger, and cpcap charger working without usb
<freemangordon>
no, it is fine as I did it, the point is that there is a race between phy and extcon driver on reading the sense registers :)
<freemangordon>
like, phy reads sense and starts doing things
<freemangordon>
that might happen before extcon had a chance to read sense regs
<tmlind>
extcon-cpcap.c not git added, not in the patch?
<freemangordon>
oh
<freemangordon>
:)
<freemangordon>
yeah, sorry, will do now
<tmlind>
ok
<tmlind>
the bus notifiers would allow checking state after enumeration without adding long sleeps
<tmlind>
you can get a non-standard micro-b to micro-b otg cable with one end id pin grounded and test with two d4 if you want to :)
<tmlind>
we don't have any of the id pin pull resistor value stuff implemented though
<freemangordon>
it should be easy though
<tmlind>
yeah just cpcap regs
<freemangordon>
adc
<tmlind>
yeah probably implemented for measuring already in the iio code
<freemangordon>
right
<tmlind>
not sure if the usb headsets have id pin grounded, if not a usb-a to microusb-b with otg pin grounded cable is needed
<freemangordon>
I think detecting usb audio accessory is done in the same way, it is still CEA-936-A
<freemangordon>
still done through ID pin, but seems ID pin is used in a different way
<tmlind>
ok
<freemangordon>
tmlind: uvos: so, cpcap-charger charge current ramping patch is not upstream?
Daanct12 has quit [Quit: Quitting]
Twig has quit [Remote host closed the connection]
norayr has left #maemo-leste [Disconnected: Replaced by new connection]
uvos has joined #maemo-leste
<uvos>
freemangordon: right i dident submitt it, as its not ready
<uvos>
so the ramping is required as in adverse circumstances (high lead inductance, slow regulation from the port etc) turning on full current causes inrush current to trip the vbus irq. this disables charging again
<uvos>
ramping slowly avoids this & allows regulation to catch up, fixing the issue
<uvos>
however we inform userspace that charging is active as soon as charging becomes active at the first current step in the ramp
<uvos>
at this time surely current is sill negative, this causes userspace to think we are not charging at all.
<uvos>
i "fixed" this by ensureing that the current is allways negative when the first step comes by just giveing userspce the set current, instead of real current
<uvos>
obv this isent a solution fit to be merged
<uvos>
the real solution would be to avoid informing userspace that we started charging untill the ramp is finished
<uvos>
but im not sure how to do this best
uvos has quit [Ping timeout: 268 seconds]
alex1216 has joined #maemo-leste
<freemangordon>
uvos: do not call power_supply_changed() until have to?
<Wizzup>
mogolobogo[m]: I got an example config from uvos for navit, but I tihnk it needs some work, the old maemo navit had a better config if I remember correctly
<Wizzup>
we have about 4 map viewers, also for other map sources, but nothing for routing
<Wizzup>
ah, it can potentially use them?
<mogolobogo[m]>
Wizzup: I do not know, for what I have tried I was not all too happy with any of the map options. Mostly because of the loading speed. CloudGPS is not offline if I remember correctly, I found Navit very difficult to setup and slow, (although that is apparently the vector renderings), but it made me quit halfway. Modrana I found intuitive as well, as you also mentioned, but one can not download large maps, or one can not zoom in for
<mogolobogo[m]>
offline maps enough due to it not being vector based is what I understood. I figured it might be good to implement a currently active project using osm maps, which for what I can see Mepo would be a good option for.
<mogolobogo[m]>
I am not all too deep in the matter though.
<Wizzup>
Sounds about right
<Wizzup>
I like maep the most as a map viewer, but it is online, but can cache
<Wizzup>
(and not vector)
<bencoh>
marble was pretty good as well, but it's qt4-based
<bencoh>
(I still use marble on n900)
<Wizzup>
does it do routing?
<mogolobogo[m]>
Mepo: Milestone 5: UI Niceties (Complete: 8/15/2022, tag: 0.5): Add routing script based on GraphHopper, OpenRouteService, or similar to parse GeoJSON LineString API response into an ordered pin group. Thus allowing for point-to-point navigation.
<mogolobogo[m]>
bencoh: never tried marble, does it do offline/
<Wizzup>
mogolobogo[m]: would be sweet if someone could try it on maemo and package it
<Wizzup>
I assume it supports X (through SDL?) as well
uvos__ has joined #maemo-leste
norayr has joined #maemo-leste
<uvos__>
really the best soluton would be to get organic maps to work, its imo pretty good on andorid and i have compiled it on arch and it works fairly ok on desktop linux, needs some polishing but its a very good base
<uvos__>
this is quite some time ago to (when i tested it) there has beend some development because of insterest from other linux on phone projects
<uvos__>
so i asume its even closer to a finished solution now
<uvos__>
the main problem beeing it needs newer libs than we have in our now very old debian/devuan
<uvos__>
ofc i also dont know how well this will perform on d4
<uvos__>
it is at least alot faster than navit on my desktop pc
<uvos__>
i gues one could try the android version on los
<Wizzup>
uvos__: would bullseye be new enough?
<Wizzup>
or do we need testing?
<freemangordon>
I think we shall start moving to bullseye :(
<freemangordon>
(chimaera I guess)
<uvos__>
i dont know of the topp of my head for sure, but i think chimaera was enough
<Wizzup>
freemangordon: yes, we have funding for this and might start as early as next week
<Wizzup>
I am asking because we might as well go to testing
<Wizzup>
it's probably not much more effor and it will become stable eventually
<Wizzup>
daedalus or something in devuan
<Wizzup>
last time I brought it up uvos said no, better to chimaera
<mogolobogo[m]>
Wizzup: I would theoretically be interested in getting smth to work, I would need some direct support though as I have only recently gotten to learn what packaging conceptually means... Also, I have some other priorities that need attention, so can not promise anything atm.
<freemangordon>
Wizzup: wouldn't it be too much of a hop oldstable->testing?
<freemangordon>
we have lot of users of obsolete API
<Wizzup>
freemangordon: depends on what testing deprecates on top of current stable
<uvos__>
also i fear testing changing beneath our feet while porting
<Wizzup>
we know there is gconf, but that is already for current stable
<Wizzup>
uvos__: hm, debian testing is usually already quite frozen, no?
<uvos__>
sure
<Wizzup>
but it's a fair point
<uvos__>
still bugs
<uvos__>
any changes can surface annoying extra bugs in maemo code or debian
<Wizzup>
ok, I am fine with chimaere
<Wizzup>
chimeara
<Wizzup>
except for the name
<Wizzup>
chimaera*
<Wizzup>
lol
<freemangordon>
actualy this is easier
<freemangordon>
:)
<uvos__>
devuan 11
<uvos__>
:P
<Wizzup>
what is?
<freemangordon>
beowulf is harder
<Wizzup>
the name?
<Wizzup>
lol
<Wizzup>
ok
<freemangordon>
yeah
<Wizzup>
so the plan is to work on porting starting next week or so
<Wizzup>
I have a few folks who are willing to help
<freemangordon>
freat
<freemangordon>
*great
<freemangordon>
do we know what we want to replace gconf with?
<uvos__>
you guys have been through this before, i honstly dont know how to start even
<uvos__>
since how do you test anything if nothing works :P
<freemangordon>
uvos__: trying to compile and run hildon-desktop ;)
<freemangordon>
it pulls almost everything needed
<freemangordon>
then jildon-home and hildon-status-menu
<uvos__>
gsettings/dconf is probubly the path of least resistance
<uvos__>
but it requires rethinking some interfaces that do stuff with gconf
<uvos__>
that gsettings dosent allow
<freemangordon>
but they don;t provide notifications, no?
<uvos__>
of it dose
<uvos__>
main porblems are:
<uvos__>
the hack used to allow root and user share one configuration enviorment dosent work
<uvos__>
you need to reorganize everything a bit since in current gconf the settings app owns alot of the schemas
<uvos__>
but in gsettings the application affected uppon must own them
<uvos__>
and eatch application needs its own folder
<uvos__>
no osso common folder for display for isntance
<freemangordon>
ugh
<uvos__>
but really this is no big issue
<freemangordon>
how's that?
<freemangordon>
like one and the same setting is used all over the place
<freemangordon>
I think this *is* big issue
<uvos__>
thats no a problem
<uvos__>
well i ported mce so ill explain how this affected it
<freemangordon>
can;t we move to configfs?
<freemangordon>
and be independent of whatever new shiny interface freedesktop guys will come up with in next verease?
<uvos__>
so in gconf the settings applet owned the schema with the display settings (imo this is broken allready since mce can run without the settings applet but not vice versa).
<uvos__>
the only thing needed was moving the keys that mce is supposed to apply (ie display brightness etc) to a mce namespace
<uvos__>
and install the schema with mce
<uvos__>
(since in gsettings it is an error to have a key without it being the schema)
<freemangordon>
and how the applet sets those keys?
<uvos__>
other than that everything is the same
<uvos__>
every other user that jsut wants to set or know the key
<uvos__>
can just register for it
<uvos__>
it just needs to know its in mces namespace
<freemangordon>
hmm, ok
<Wizzup>
uvos__: freemangordon: so I do have a plan on where to start
<freemangordon>
so, we can still register for changed notifications?
<Wizzup>
I'm just saving it for a few more days when we 'actually' would start
<freemangordon>
ok
<uvos__>
yes ofc
<uvos__>
just that the schma needs to belong to some application
<uvos__>
and every other user must depend on this application
<freemangordon>
oh, somehow you left me with the impression that it can no longer be used for IPC
<uvos__>
as trying to interact with the key while the schema is not registerd is an error
<uvos__>
no no
<freemangordon>
ok
<uvos__>
just not wiled ipc
<freemangordon>
well, not that big issue then
<uvos__>
like random keys just created dynamicly
<uvos__>
to comunicate something
<freemangordon>
what about icd2 then?
<uvos__>
or keys that belong to no one
<Wizzup>
that would be a problem @ icd2
<freemangordon>
it creates networks as keys?
<uvos__>
icd2 is maybe not a great fit anymore
<Wizzup>
I suppose we could also just package gconf, but yeah
<uvos__>
i think there is a way to do this tho
<uvos__>
its just more complicated
<uvos__>
you have to add a schema for a network with certain fileds
<uvos__>
and then you can have an array in icd2 schema and then create entrys
<uvos__>
so it schould work too
<Wizzup>
it does feel like boring work for no real gain for us
<uvos__>
just is a bit more work to orgaize it like is required
<uvos__>
sure there is litttle to gain here
<uvos__>
besides gsettings enforcing some correctness
<uvos__>
to for instance allow it to ensure that uninstalling a application removes all its keys etc
<uvos__>
but we must miagrate to something
<freemangordon>
wait, uninstalling application removes its settings?
<freemangordon>
this is crazy
<uvos__>
no it can remove its settings
<uvos__>
ie this can be done
<freemangordon>
ah
<freemangordon>
ok
<uvos__>
in gconf this is not possible to do correctly
<Wizzup>
hm, well, we should consider if we want to do that migration now, or if we just package gconf and be done with it
<uvos__>
arch for instance allows you to do this with a flag in its package manager while uninstalling
<uvos__>
i assume debian has something like this too
<Wizzup>
it might easily take up a few weeks of full time development if we port to gsettings
<uvos__>
sure
<Wizzup>
but on the other hand we might rely on something (not our own pkg) that used to use gconf but now only uses gsettings
<uvos__>
mce and all its users (afaik) are done
<uvos__>
but yeah its lots of work for everthing else
<freemangordon>
I guess we shall start soon or later
<Wizzup>
there's at least 65 packages, maybe more
<Wizzup>
these are ones that list it explicitly in the control files
<Wizzup>
I'd personally vote to do it later unless there's a real reason to do so now
<freemangordon>
maybe package gconf and slowly start migrating once we have everything else up and running
<uvos__>
no opinion
<bencoh>
mogolobogo[m]: marble works offline, yes
<uvos__>
there is also a mobile version of marble that uses kirigami mobile ui frame or what its called, for plamo
<uvos__>
never used it
<uvos__>
but with the other kirigami apps us needing newer qt was allways the problem
<freemangordon>
uvos__: so, what about my proposal to not call power_supply_changed() until charging current had settled? n regards to cpcap_charger current ramping that is
<freemangordon>
or rather setting status to "not charging" at ramp start and changing to "charging" at end
* freemangordon
wonders why sre is so slow @ reviewing patches
<uvos__>
freemangordon: sure yeah, but i have too look at the code again to see how exactly its called
<uvos__>
in prinicpal that should work
<uvos__>
but may have downsides
<uvos__>
what if usespace checks state via sysfs during this time
<freemangordon>
not-charging
<freemangordon>
in any case, better send for upstreaming, if there is something wring, you'll be told so, no?
<uvos__>
sure but then we need to add to the function that reads state for sysfs
<freemangordon>
but give that they accepted your battery serial to be in linus tree :p
<uvos__>
so that it knows a ramp is in progress
<uvos__>
since it just checks reg state atm
<uvos__>
and reg state will show charging
<uvos__>
freemangordon: hey i thought the id was a constant :P
<freemangordon>
it is ;)
<freemangordon>
:D
<uvos__>
across all battiers
<uvos__>
batteries
<freemangordon>
yeah, I know, kidding
<freemangordon>
still, I think it is better to even send RFC patch
<freemangordon>
you will get feedback on how to properly implement
<freemangordon>
I know it is annoying, but the less patches we carry, the better in long term
<uvos__>
sure im not dissagreeing
norayr has left #maemo-leste [Disconnected: timeout during receiving]
norayr has joined #maemo-leste
alex1216 has quit [Quit: WeeChat 2.3]
norayr has left #maemo-leste [Disconnected: timeout during receiving]
pere has quit [Ping timeout: 240 seconds]
uvos__ has quit [Ping timeout: 256 seconds]
pere has joined #maemo-leste
uvos has joined #maemo-leste
norayr has joined #maemo-leste
ceene has quit [Remote host closed the connection]
<sicelo>
https://youtu.be/wOmRMg546UY - snapdragon 845 phone running linux. user says he gets almost same battery life as he did on android
<Wizzup>
which is? :D
<sicelo>
phone? oneplus 6
<Wizzup>
I mean, what is the battery life that he claims