libera/#maemo-leste/ Monday, 2022-11-14

mogolobogo[m]<uvos> "its just absurdly slow at..." <- Do you possibly have a config example somewhere? Might be very helpful on a wiki as well ?00:10
mogolobogo[m]<Wizzup> "but since monav is removed..." <- Might it be possible or a good plan to add mepo to the repos? I believe that is the pinephone standard00:11
BlagovestPetrov[guys, is there any documentation about the GTK api?00:14
BlagovestPetrov[how is the menu generated, is it using dbus?00:14
BlagovestPetrov[ok, that's libhildon :)01:03
tmlindfreemangordon: sounds like you got something working :)06:13
tmlindfreemangordon: 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 current06:14
tmlindi'd assume we could listen for BUS_NOTIFY_ADD_DEVICE that will likely happen after gadget has been configured06:16
freemangordontmlind: maybe, but why do extra work if this already comes through usb_charger framework?07:17
freemangordonwhat I got working is charger detection and current limit :)07:19
freemangordontmlind: please, have a look when you have some spare time https://pastebin.com/TTwcMhYA07:22
freemangordonI 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_S07:24
freemangordonandroid kernel waits until there is no charge in sense registers before making decision on what to do07:25
freemangordonI think we shall do the same07:25
freemangordonanother 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.07:26
freemangordonso, I am waiting for your comments before sending some parts for upstreaming07:27
tmlindfreemangordon: probably best to discuss the extcon stuff on the mailing lists to avoid extra work07:31
tmlindsre might have some ideas07:31
freemangordonsure, but what about phy driver?07:32
freemangordonit is your name there07:32
freemangordonbut ok, I might send some RFC patch07:32
freemangordonthough, sre looks like overloaded07:32
tmlindsure phy if no better place is found, we want to avoid circular module dependencies though between charging and usb :)07:33
tmlindbest to keep usb phy and usb functionality working standalone without charger, and cpcap charger working without usb07:34
freemangordonno, 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 :)07:34
freemangordonlike, phy reads sense and starts doing things07:34
freemangordonthat might happen before extcon had a chance to read sense regs07:35
tmlindextcon-cpcap.c not git added, not in the patch?07:35
freemangordonoh07:35
freemangordon:)07:35
freemangordonyeah, sorry, will do now07:35
tmlindok07:36
tmlindthe bus notifiers would allow checking state after enumeration without adding long sleeps07:36
freemangordontmlind: https://pastebin.com/MMNZRwNp07:37
tmlindok07:37
freemangordonI think it will need one IRQ less though07:38
freemangordonor handling vpus IRQ instead of SE107:38
freemangordon*vbos07:38
freemangordonoh07:38
freemangordonVBUS07:38
freemangordonbecause android somehow manages to charge from ASUS 2.4A powerbank I have here without me having to press the button on the bank07:39
freemangordonbut those are details anyway07:39
tmlindok07:40
tmlindso musb set_power probably can't be removed until all the users are fixed07:40
freemangordonwhy it has to be removed?07:41
tmlindi meant removing the check for set_power07:41
freemangordonah07:41
freemangordonyeah07:41
freemangordonbut I didn't find any users :)07:42
tmlindthere are at least two legacy layers still in use in musb, set_power, and drivers/usb/phy07:42
tmlindhmm07:42
freemangordonmaybe I didn't search correctly07:42
tmlindmaybe n8x0 is still using it with platform_data?07:43
freemangordonI am grepping07:43
freemangordonhmm, wait07:43
freemangordonthe check is in a static function07:43
tmlindtusb_set_power()07:43
freemangordonmusb_gadget_vbus_draw() is the patched function07:44
tmlindno musb->xceiv->set_power = tusb_draw_power07:44
freemangordonso?07:44
freemangordonmusb_gadget_vbus_draw() had a patch if there is no set_power cb to just return07:45
freemangordons/patch/check07:45
tmlindyeah so is that check safe to remove?07:45
freemangordonI removed that check, but it is still there in  usb_phy_set_power()07:46
freemangordonhttps://elixir.bootlin.com/linux/latest/source/include/linux/usb/phy.h#L29507:46
tmlindseparate clean-up patch then?07:46
freemangordonsure07:46
freemangordonthere are at least 4 or 5 patches combined in what I pastebinned ^^^ :)07:47
tmlindok07:47
freemangordonmusb/usb_charger/cpcap_phy/cpcap_charger/extcon/dts07:47
freemangordonso 6 :)07:47
tmlindso what's the plan on telling cpcap-charger the max configured rate for the usb gadget?07:47
tmlindor how does that happen..07:48
freemangordonusb_charger_register_notifier()07:48
freemangordonnotifier gets called by usb_phy_set_charger_current()07:49
freemangordonwhich gets called by either usb_phy_set_power() or by excon API (through phy/usb integration)07:49
freemangordonbut, both gadget and extcon end up notifying through https://elixir.bootlin.com/linux/latest/source/drivers/usb/phy/phy.c#L23107:51
tmlindyeah ok, so that should be discussed with the drivers/phy folks if that's still ok to use or what they recommend, i don't know07:51
freemangordonright07:51
freemangordonso, how to send that on the ML? RFC series?07:51
tmlindyeah rfc sounds good, cc usb and drivers/phy folks at least07:52
tmlindweird if the drivers/usb/phy dependency is still needed :)07:52
freemangordonBTW, there is another way, IIUC, through https://elixir.bootlin.com/linux/latest/source/include/linux/usb/phy.h#L15707:52
freemangordonbut, this limit detection to chargers only07:53
freemangordonwe still need extcon for carkits and such07:53
tmlindok07:53
freemangordonandyeah, it is usb_charger_type still :)07:53
tmlindthe debug serial port mode is carkit with charging07:54
tmlindhmm nope, vbus must be disconnected to get debug uart..07:54
tmlindthe serial port with charging is a carkit mode with a certain id pin pull up value07:55
freemangordonthis is what we can potentially detect https://elixir.bootlin.com/linux/latest/source/include/linux/extcon.h#L3507:55
freemangordonBTW, I think headset detection should be extcon as well07:55
tmlindok07:55
freemangordonbut that's another story07:56
tmlindthere's some pdf somewhat documenting the carkit pull resistor values, i think it's for some st phy or pmic07:56
freemangordonI found 2 or 3, all describing the same values07:57
freemangordonthere are about 40 or so variants07:57
tmlindyeah07:57
freemangordonseems to be samsung that came with those07:57
freemangordonnot that I can test here, I don;t have anything with uSB A port07:58
freemangordon*uUSB07:59
tmlindi think this doc lists the carkit modes fyi: https://www.onsemi.com/download/data-sheet/pdf/fsa9288a-d.pdf08:00
freemangordonyeap08:01
tmlindyou 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 :)08:02
tmlindwe don't have any of the id pin pull resistor value stuff implemented though08:03
freemangordonit should be easy though08:03
tmlindyeah just cpcap regs08:03
freemangordonadc08:03
tmlindyeah probably implemented for measuring already in the iio code08:03
freemangordonright08:04
tmlindnot sure if the usb headsets have id pin grounded, if not a usb-a to microusb-b with otg pin grounded cable is needed08:05
freemangordonI think detecting usb audio accessory is done in the same way, it is still CEA-936-A08:06
freemangordonstill done through ID pin, but seems ID pin is used in a different way08:08
tmlindok08:13
freemangordontmlind: uvos: so, cpcap-charger charge current ramping patch is not upstream?08:26
uvosfreemangordon: right i dident submitt it, as its not ready09:29
uvosso 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 again09:30
uvos ramping slowly avoids this & allows regulation to catch up, fixing the issue09:30
uvoshowever we inform userspace that charging is active as soon as charging becomes active at the first current step in the ramp09:30
uvosat this time surely current is sill negative, this causes userspace to think we are not charging at all.09:30
uvosi "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 current09:31
uvosobv this isent a solution fit to be merged09:31
uvosthe real solution would be to avoid informing userspace that we started charging untill the ramp is finished09:31
uvosbut im not sure how to do this best09:31
freemangordonuvos: do not call  power_supply_changed() until have to?09:53
Wizzupmogolobogo[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 correctly09:54
Wizzupmogolobogo[m]: what is mepo?09:54
mogolobogo[m]Wizzup: https://sr.ht/~mil/Mepo/12:15
Wizzupmogolobogo[m]: does this do routing?12:18
Wizzupwe have about 4 map viewers, also for other map sources, but nothing for routing12:18
Wizzupah, it can potentially use them?12:18
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 for12:22
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.12:22
mogolobogo[m]I am not all too deep in the matter though.12:24
WizzupSounds about right12:27
WizzupI like maep the most as a map viewer, but it is online, but can cache12:27
Wizzup(and not vector)12:27
bencohmarble was pretty good as well, but it's qt4-based12:39
bencoh(I still use marble on n900)12:39
Wizzupdoes it do routing?12:48
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.12:53
mogolobogo[m]bencoh: never tried marble, does it do offline/12:53
Wizzupmogolobogo[m]: would be sweet if someone could try it on maemo and package it13:00
WizzupI assume it supports X (through SDL?) as well13:00
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 base13:07
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 projects13:08
uvos__so i asume its even closer to a finished solution now13:08
uvos__the main problem beeing it needs newer libs than we have in our now very old debian/devuan13:09
uvos__ofc i also dont know how well this will perform on d413:10
uvos__it is at least alot faster than navit on my desktop pc13:10
uvos__i gues one could try the android version on los13:11
Wizzupuvos__: would bullseye be new enough?13:12
Wizzupor do we need testing?13:13
freemangordonI think we shall start moving to bullseye :(13:13
freemangordon(chimaera I guess)13:13
uvos__i dont know of the topp of my head for sure, but i think chimaera was enough13:13
Wizzupfreemangordon: yes, we have funding for this and might start as early as next week13:14
WizzupI am asking because we might as well go to testing13:14
Wizzupit's probably not much more effor and it will become stable eventually13:14
Wizzupdaedalus or something in devuan13:14
Wizzuplast time I brought it up uvos said no, better to chimaera13:15
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.13:15
freemangordonWizzup: wouldn't it be too much of a hop oldstable->testing?13:16
freemangordonwe have lot of users of obsolete API13:16
Wizzupfreemangordon: depends on what testing deprecates on top of current stable13:16
uvos__also i fear testing changing beneath our feet while porting13:16
Wizzupwe know there is gconf, but that is already for current stable13:16
Wizzupuvos__: hm, debian testing is usually already quite frozen, no?13:16
uvos__sure13:17
Wizzupbut it's a fair point13:17
uvos__still bugs13:17
uvos__any changes can surface annoying extra bugs in maemo code or debian13:17
Wizzupok, I am fine with chimaere13:17
Wizzupchimeara13:17
Wizzupexcept for the name13:17
Wizzupchimaera*13:17
Wizzuplol13:17
freemangordonactualy this is easier13:18
freemangordon:)13:18
uvos__devuan 1113:18
uvos__:P13:18
Wizzupwhat is?13:18
freemangordonbeowulf is harder13:18
Wizzupthe name?13:18
Wizzuplol13:18
Wizzupok13:18
freemangordonyeah13:18
Wizzupso the plan is to work on porting starting next week or so13:18
WizzupI have a few folks who are willing to help13:18
freemangordonfreat13:18
freemangordon*great13:18
freemangordondo we know what we want to replace gconf with?13:19
uvos__you guys have been through this before, i honstly dont know how to start even13:19
uvos__since how do you test anything if nothing works :P13:19
freemangordonuvos__: trying to compile and run hildon-desktop ;)13:19
freemangordonit pulls almost everything needed13:19
freemangordonthen jildon-home and hildon-status-menu13:20
uvos__gsettings/dconf is probubly the path of least resistance13:20
uvos__but it requires rethinking some interfaces that do stuff with gconf13:20
uvos__that gsettings dosent allow13:20
freemangordonbut they don;t provide notifications, no?13:20
uvos__of it dose13:20
uvos__main porblems are:13:20
uvos__the hack used to allow root and user share one configuration enviorment dosent work13:21
uvos__you need to reorganize everything a bit since in current gconf the settings app owns alot of the schemas13:21
uvos__but in gsettings the application affected uppon must own them13:21
uvos__and eatch application needs its own folder13:21
uvos__no osso common folder for display for isntance13:21
freemangordonugh13:22
uvos__but really this is no big issue13:22
freemangordonhow's that?13:22
freemangordonlike one and the same setting is used all over the place13:22
freemangordonI think this *is* big issue13:22
uvos__thats no a problem13:22
uvos__well i ported mce so ill explain how this affected it13:22
freemangordoncan;t we move to configfs?13:23
freemangordonand be independent of whatever new shiny interface freedesktop guys will come up with in next verease?13:23
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).13:23
uvos__the only thing needed was moving the keys that mce is supposed to apply (ie display brightness etc) to a mce namespace13:24
uvos__and install the schema with mce13:24
uvos__(since in gsettings it is an error to have a key without it being the schema)13:24
freemangordonand how the applet sets those keys?13:24
uvos__other than that everything is the same13:24
uvos__every other user that jsut wants to set or know the key13:25
uvos__can just register for it13:25
uvos__it just needs to know its in mces namespace13:25
freemangordonhmm, ok13:25
Wizzupuvos__: freemangordon: so I do have a plan on where to start13:25
freemangordonso, we can still register for changed notifications?13:25
WizzupI'm just saving it for a few more days when we 'actually' would start13:25
freemangordonok13:25
uvos__yes ofc13:25
uvos__just that the schma needs to belong to some application13:25
uvos__and every other user must depend on this application13:26
uvos__as trying to interact with the key while the schema is not registerd is an error13:26
freemangordonoh, somehow you left me with the impression that it can no longer be used for IPC13:26
uvos__no no13:26
freemangordonok13:26
uvos__just not wiled ipc13:26
freemangordonwell, not that big issue then13:26
uvos__like random keys just created dynamicly13:26
uvos__to comunicate something13:27
freemangordonwhat about icd2 then?13:27
uvos__or keys that belong to no one13:27
Wizzupthat would be a problem @ icd213:27
freemangordonit creates networks as keys?13:27
uvos__icd2 is maybe not a great fit anymore13:27
WizzupI suppose we could also just package gconf, but yeah13:27
uvos__i think there is a way to do this tho13:28
uvos__its just more complicated13:28
uvos__you have to add a schema for a network with certain fileds13:28
uvos__and then you can have an array in icd2 schema and then create entrys13:28
uvos__so it schould work too13:28
Wizzupit does feel like boring work for no real gain for us13:28
uvos__just is a bit more work to orgaize it like is required13:28
uvos__sure there is litttle to gain here13:29
uvos__besides gsettings enforcing some correctness13:29
uvos__to for instance allow it to ensure that uninstalling a application removes all its keys etc13:29
uvos__but we must miagrate to something13:29
freemangordonwait, uninstalling application removes its settings?13:30
freemangordonthis is crazy13:30
uvos__no it can remove its settings13:30
uvos__ie this can be done13:30
freemangordonah13:30
freemangordonok13:30
uvos__in gconf this is not possible to do correctly13:30
Wizzuphm, well, we should consider if we want to do that migration now, or if we just package gconf and be done with it13:30
uvos__arch for instance allows you to do this with a flag in its package manager while uninstalling13:30
uvos__i assume debian has something like this too13:30
Wizzupit might easily take up a few weeks of full time development if we port to gsettings13:30
uvos__sure13:31
Wizzupbut on the other hand we might rely on something (not our own pkg) that used to use gconf but now only uses gsettings13:31
uvos__mce and all its users (afaik) are done13:31
uvos__but yeah its lots of work for everthing else13:31
freemangordonI guess we shall start soon or later13:32
Wizzupthere's at least 65 packages, maybe more13:32
Wizzupthese are ones that list it explicitly in the control files13:32
WizzupI'd personally vote to do it later unless there's a real reason to do so now13:32
freemangordonmaybe package gconf and slowly start migrating once we have everything else up and running13:33
uvos__no opinion13:33
bencohmogolobogo[m]: marble works offline, yes14:05
uvos__there is also a mobile version of marble that uses kirigami mobile ui frame or what its called, for plamo14:09
uvos__never used it14:09
uvos__but with the other kirigami apps us needing newer qt was allways the problem14:10
freemangordonuvos__: so, what about my proposal to not call  power_supply_changed() until charging current had settled? n regards to cpcap_charger current ramping that is14:11
freemangordonor rather setting status to "not charging" at ramp start and changing to "charging" at end14:12
* freemangordon wonders why sre is so slow @ reviewing patches14:13
uvos__freemangordon: sure yeah, but i have too look at the code again to see how exactly its called14:14
uvos__in prinicpal that should work14:14
uvos__but may have downsides14:14
uvos__what if usespace checks state via sysfs during this time14:15
freemangordonnot-charging14:15
freemangordonin any case, better send for upstreaming, if there is something wring, you'll be told so, no?14:16
uvos__sure but then we need to add to the function that reads state for sysfs14:16
freemangordonbut give that they accepted your battery serial to be in linus tree :p14:16
uvos__so that it knows a ramp is in progress14:16
uvos__since it just checks reg state atm14:16
uvos__and reg state will show charging14:16
uvos__freemangordon: hey i thought the id was a constant :P14:17
freemangordonit is ;)14:17
freemangordon:D14:17
uvos__across all battiers14:17
uvos__batteries14:17
freemangordonyeah, I know, kidding14:17
freemangordonstill, I think it is better to even send RFC patch14:18
freemangordonyou will get feedback on how to properly implement14:18
freemangordonI know it is annoying, but the less patches we carry, the better in long term14:18
uvos__sure im not dissagreeing14:20
sicelohttps://youtu.be/wOmRMg546UY - snapdragon 845 phone running linux. user says he gets almost same battery life as he did on android20:25
Wizzupwhich is? :D21:17
sicelophone? oneplus 621:24
WizzupI mean, what is the battery life that he claims21:24
sicelohttps://www.youtube.com/watch?v=wOmRMg546UY&t=175s ... 3days idle on wifi, 1 day with sim. about the same as android on the same device21:31
sicelobtw, got a chance to test the usb-gadgets MR with gentoo yet?21:34
Wizzupdoesn't that mean that android has pretty poor battery life?21:40
Wizzupsicelo: hmm, no, not yet, I can do that tomorrow, do you have a link to the mr?21:41
Wizzupsorry, I've been really busy with the nlnet stuff21:41
sicelohttps://github.com/maemo-leste/hildon-usb-gadgets/pull/121:44
uvosthats pretty poor battery life for a android device22:46
uvosbut pretty execelent for a linux phone device22:46
uvoswonder what the pocophone f1 target we have uses22:46
uvos(its the same chip)22:46
WizzupDid that ever actually work, the pocophone target?22:49
uvosWizzup: yes23:02
uvosWizzup: absolutly it worked23:02
uvoson at least the guys device (who ported it)23:03
Wizzupok23:08

Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!