norayr has joined #maemo-leste
norayr has left #maemo-leste [Error from remote client]
norayr has joined #maemo-leste
xmn has quit [Ping timeout: 264 seconds]
xmn has joined #maemo-leste
noidea_ has quit [Quit: Leaving]
noidea_ has joined #maemo-leste
thunderysteak has quit [Ping timeout: 260 seconds]
norayr has left #maemo-leste [Error from remote client]
joerg has quit [Ping timeout: 264 seconds]
joerg has joined #maemo-leste
norayr has joined #maemo-leste
norayr has left #maemo-leste [Error from remote client]
<freemangordon> after that date I see only 2.7x.y tags, while chimaera is on 2.66.8
doc has joined #maemo-leste
Twig has joined #maemo-leste
<freemangordon> Wizzup: I think the way it to add "-DGLIB_DISABLE_DEPRECATION_WARNINGS" to CI CFLAGS
<freemangordon> *the way is
<freemangordon> ther is also -DGTK_DISABLE_DEPRECATION_WARNINGS
norayr has joined #maemo-leste
<freemangordon> -DGLIB_VERSION_MAX_ALLOWED=GLIB_VERSION_2_XX as well
norayr has left #maemo-leste [Error from remote client]
xmn has quit [Ping timeout: 264 seconds]
norayr has joined #maemo-leste
ceene has joined #maemo-leste
Danct12 has joined #maemo-leste
norayr has left #maemo-leste [Error from remote client]
<freemangordon> It looks like an error to me
<freemangordon> going to remove
<buZz> uvos: how/where did you add the ignore_temperature_probe=1 ?
<buZz> i guess modprobe.conf
<freemangordon> /etc/modprobe.d/
<freemangordon> buZz: ^^^
Daaanct12 has joined #maemo-leste
<buZz> right, i made a new file, wrote 'options cpcap_battery ..' etc
<freemangordon> BlagovestPetrov[: deprecation issues should be fixed, please upgrade your VM and pull latest source code for systemui etc
<BlagovestPetrov[> thanks :)
Danct12 has quit [Ping timeout: 256 seconds]
Daaanct12 has quit [Ping timeout: 260 seconds]
Danct12 has joined #maemo-leste
<Wizzup> freemangordon: ok, I can do that
<Wizzup> @ glib build flag
<Wizzup> so we take upstream and add your patch?
<Wizzup> looks like it's fixed
<Wizzup> ?
* sicelo hides
<Wizzup> sicelo: lol
<sicelo> anyway, it remains to be seen how this will end
Pali has joined #maemo-leste
<freemangordon> however, this does not mean we don;t need to ship glib with https://gitlab.gnome.org/GNOME/glib/-/commit/f065497acfbfe654369945054240918fcee001c3 backported
<freemangordon> could you please pull chimaera glib in our repo?
<freemangordon> the same way beowulf was pulled
<freemangordon> do you know where this https://github.com/maemo-leste-upstream-forks/glib was forked from?
akossh has joined #maemo-leste
<Wizzup> ok, let me check
<freemangordon> I guess debian salsa or somesuch
<Wizzup> freemangordon: yeah just gimme a sec
<Wizzup> I was not at keyboard
<Wizzup> doesn't seem to be what's actually in bullseye
<Wizzup> lol
<Wizzup> freemangordon: what made you say chimaera is on 2.66.8?
<freemangordon> libglib2.0-0:amd64 2.66.8-1
<freemangordon> dpkg -l | grep glib
<Wizzup> ah!
<Wizzup> I was looking at bookworm somehow
<Wizzup> freemangordon: so shall I do it?
Danct12 has quit [Quit: Leaving]
<Wizzup> done..
<Wizzup> (testing build now)
<Wizzup> ah, the patch doesn't apply cleanly :)
<Wizzup> imagine if this was just in git somehow, and we wouldn't have to deal with quilt :D
norayr has joined #maemo-leste
<Wizzup> --static guint n_desktop_file_dirs;
<Wizzup> freemangordon: this is gone from new glib
<Wizzup> it seems relatively trivial to update the patch, but I won't do it right now, I'll push my wip
<Wizzup> freemangordon: pushed to maemo/chimaera, please take a look at the build fail when you can, otherwise I can do it in ~30-60 mins
akossh has quit [Ping timeout: 264 seconds]
norayr has left #maemo-leste [Error from remote client]
Twig has quit [Ping timeout: 260 seconds]
<freemangordon> Wizzup: we better backport upstream patch
<freemangordon> I'll do it
Twig has joined #maemo-leste
<Wizzup> freemangordon: ok, everything else is set, it just needs a better patch, feel free to rebase and push -f
<freemangordon> trying to build it in the VM now
<freemangordon> Wizzup: and what about the other patch?
<freemangordon> the one that fixes issues on 64bit?
<freemangordon> was it already in beowulf?
<Wizzup> freemangordon: I didn't see it in maemo/beowulf
<Wizzup> maybe it was merged already
<freemangordon> yeah, that was my question - was it already merged :)
<Wizzup> probably an ascii thing really :)
<Wizzup> so yes, I think so
<freemangordon> ok
<freemangordon> trying to build glib in CI
<freemangordon> lets see
<Wizzup> you fixed the patch then?
<freemangordon> in my VM it failed in the packaging part
<Wizzup> where?
<Wizzup> I'll build it now
<Wizzup> I cherry-picked + fixes your patches, but might have missed something
<freemangordon> dh_dwz: error: Requested unknown package libglib2.0-udeb via -N/--no-package, expected one of: libglib2.0-0 libglib2.0-tests libglib2.0-bin libglib2.0-dev libglib2.0-dev-bin libglib2.0-data libglib2.0-doc
<freemangordon> I dropped beowulf patch and used the upstream one instead
<Wizzup> ok, yeah, let me fix that
<Wizzup> I don't think we need to test this in CI really
<Wizzup> it will fail there too
<Wizzup> I see the problem in rules I think
<Wizzup> tests running atm
<freemangordon> ?
<Wizzup> let me fix udeb first
<freemangordon> ok
<Wizzup> I think I have it fixed locally but it's running tests forever
<Wizzup> 19156985 tests passed, 0 failed pfew
<freemangordon> :)
<Wizzup> freemangordon: shall I merge your upstream patch with the one I tried to forward port, so that we don't have a bad patch in history?
<freemangordon> squash 2 commits?
<freemangordon> up to you
<Wizzup> ok
<freemangordon> in the meanwhile gbp:error: File contains no section headers.
<Wizzup> I will fix gbp.conf too
<freemangordon> ok
<Wizzup> one thing at a time
<Wizzup> these tests take forever
<freemangordon> yeah
<freemangordon> gbp.conf is missing [DEFAULT] on top
<Wizzup> yes, I know
<Wizzup> so I didn't get the udeb issue but I changed the rules file during build
<Wizzup> force-pushed, let's build
<Wizzup> I'll start it
<freemangordon> ok
<Wizzup> running atm
norayr has joined #maemo-leste
Twig has quit [Remote host closed the connection]
thunderysteak has joined #maemo-leste
<freemangordon> looks fine
norayr has left #maemo-leste [Error from remote client]
<Wizzup> yup
<Wizzup> ty
Twig has joined #maemo-leste
norayr has joined #maemo-leste
<buZz> i wonder, -can- charge_full even be above charge_full_design ?
norayr has left #maemo-leste [Error from remote client]
<sicelo> it should generally not
<buZz> but i now have a 1750mAh reporting BMS , on a 2250mAh battery :)
<buZz> considering my options here , i could just make charge_full_design writeable? :D
<buZz> or eh, add a option to charge beyond charge_full_design
<buZz> oh, 6*x/5 , it allows ~20% higher
<buZz> i wonder whats the motivation for the 20% , if we could stretch that to 30% , 2250 would fit :P
<buZz> maybe (4*x)/3 ?
<tmlind> buZz: maybe add a module option to use a generic battery and ignore the eeprom?
<tmlind> or a module option to force e960 battery, then we could have a proper profile for it
<buZz> hmm, well, atm its still charging, takes forever :P
<buZz> and i'll make charge_full be 2088000 for now (the max this 6/x*5 allows)
<tmlind> buZz: how about modprobe cpcap-battery batt_type=polarcell_lg_e960 or something similar
<tmlind> then ignore eeprom, keep the temp sensor in case it's wired to the eb41 pcb
<tmlind> then additionally ignore_temperature_probe=1 option can be used if using uvos' pcb
<buZz> would be nice yeah, but this is not my area of expertise :P
<buZz> a batt_type would be best i guess
<tmlind> uvos: would the above work for you for module options?
<Wizzup> freemangordon: sapwood has a commit in -devel that's not in normal beowulf, I think we can move that to normal beowulf, yeah?
<Wizzup> dsme needs some fixes, will do when I get back
norayr has joined #maemo-leste
norayr has left #maemo-leste [Error from remote client]
<Wizzup> Pali: I think I need some help with the u-boot thing that Tom is asking about, I really don't know where to start
<Pali> hm... I just do not know where to start too... Maybe asking Tom for that?
norayr has joined #maemo-leste
<sicelo> OAOB
uvos has joined #maemo-leste
<uvos> tmlind: sure yeah @ options
<uvos> buZz: for now just blacklist the one wire interface module
<uvos> that way you will not get 1750mAh as charge_full_design instead you will get something really high
<uvos> the 20% comes from me estimateing how far the callibration may undereport the real capapacity of the battery
<freemangordon> unless the battery is charged @ 4.35, 1750 is a good estimation
<freemangordon> mine calibrates @ 1594
<Wizzup> uvos: btw I think we might have pm regressions, will need some time to confirm properly
<uvos> im dose 1800 so yours is a bit wierd
<uvos> but yeah 1700 is resonable estimation
<uvos> +-20% especcaly
<uvos> tollerance
<freemangordon> uvos: +1 on the PM regressions
<uvos> as cpcap dose offer
<buZz> uvos: oh right! thats simple :P
<freemangordon> uvos: BTW, charge-mode bug appears every time device is connected to charger after low-battery power down
<freemangordon> please give me some hints how to debug
<freemangordon> are there logs or something
<uvos> not really, i would write a wpa_supplicant conf and connect wifi and start ssh before chargeing_sdl starts
<uvos> then just ssh in and look around
<uvos> freemangordon: Wizzup: ok, mine has idled at 100mW all day, so im not really seeing it, but ofc this is power_avg, not external mesurement
<buZz> uvos: is it hdq1w ?
<uvos> buZz: yes
<buZz> alright
<freemangordon> uvos: what to look for? device charges fine, it is just that battery animation stays at one red line and if you deisconnect the charger device is shut down
<uvos> ok
<freemangordon> maybe cpcap-battery is probed *after* chargeing_sdl is started?
<uvos> freemangordon: should not be possible, probing happens afaik shound happen within sysinit
<uvos> and charging_sdl runs after sysinit
<uvos> but maybe this is me miss interpreting how openrc should behave
<uvos> also idk why it should probe later when the battery is low
<uvos> i gues when poking around:
<uvos> check if the cpcap sysfs files are resonable
<freemangordon> I don;t think EPROBE_DEFER has anything to do with runlevels
<uvos> right defer true
<uvos> but i think sysinit waits until udev sais its ready
<uvos> dunno how defer interacts with udev really
<buZz> hmmz, i added 'blacklist hdq1w' to blacklist-idle.conf , still reading 1740mAh from eeprom it seems
<uvos> really charging_sld is really simple code wise so i dont quite see how it could missbehave, other than wat you said or cpacp driver misbehaveing.
<uvos> its callded omap_hdq1w or something like that
<uvos> iirc
<buZz> oh
<freemangordon> buZz: lsmod is your friend
<buZz> omap_hdq , right
<buZz> :)
<uvos> freemangordon: btw
<uvos> you can runn charging_sdl after boot too
<uvos> just to check if it behaves ok then too
<uvos> it has flags to be run in a window in x11
<freemangordon> I think it needs some logs added here and there
<uvos> it logs some stuff
<uvos> but only to stdout
<freemangordon> where?
<uvos> so you could save that somehwere
<uvos> its not captured in the initscript afaik
<uvos> you could do that
<uvos> but it dosent log mutch more than the battery percent
<freemangordon> it logs to stdout?
<uvos> which its also showing you
<uvos> yeah
<uvos> so it prints to stdout
<buZz> could put a >> charging_sdl.log on it
<uvos> you could redirect that somewhere
<freemangordon> well, I can put some printfs here and tehre
<uvos> sure
<freemangordon> ok
<freemangordon> will do
<uvos> for one thing
<freemangordon> oh, I was about to try to implement SOC estimation based on the voltage
<uvos> whenever charging_sdl runs
<uvos> pvrk compains about something
<uvos> might be related to the eventual hang
<freemangordon> hmmm
<buZz> ah yez
<freemangordon> ok, will check
<freemangordon> where did you get that code from?
<uvos> charging_sdl?
<freemangordon> mhm
<uvos> its from pmos
<uvos> but i also added quite some stuff
<uvos> not sure what part of it your asking about
<freemangordon> I asked in general
<buZz> ah, meh, blacklisting omap_hdq prevents charging to 4.35v
<freemangordon> makes sense, no?
<buZz> welp, beats my purpose anyway :P
<uvos> sure but i gues he dosent want that
<buZz> yes i do, obviously :D
<freemangordon> we *will not* allow you to charge non-HV lipo to 4.35
<buZz> right, thats fine
<buZz> i just want to charge this HV lipo to 4.35 :P
<freemangordon> I dodn;t get why did you remove 1wire protocol driver
<freemangordon> *didn't
<freemangordon> what is the issue?
<uvos> he has a eb41 pcb/eeprom
<uvos> on a larger battery
<uvos> cpcap will discard the callibration
<uvos> if its to larg
<buZz> ah, well, cpcap_battery prevents to calibrate the battery to >120% of charge_full_design
<uvos> ie mutch larger than max_design
<freemangordon> ah
<buZz> yeah well, its 28% more
<freemangordon> well, I guess that shall be fixed in the driver
<uvos> or you could
<uvos> you know, change the eeprom
<buZz> its writeable?
<freemangordon> isn't it OTP?
<uvos> idk
<freemangordon> wait, there are checksums as well
<buZz> the suggestion was adding a battery definition to override
<uvos> freemangordon: true but we dont care
<uvos> so for android yeah
<freemangordon> yes, we care as android will refuse to charge
<uvos> sure but buzz might not care about android
<uvos> this is about a now solution
<freemangordon> well, yeah
<uvos> so check if the eeprom is writeable
<freemangordon> buZz: right, you may try to write
<buZz> hehe well, its 2088mAh now
<uvos> and just change the value of so
xmn has joined #maemo-leste
<freemangordon> buZz: see driver code for the offset and the value you have to write
<freemangordon> uvos: btw, what is the rationale behind that 120% restriction?
<uvos> the callibration sometimes goes totaly bonkers here
<uvos> if you charge and discarge and charge again
<uvos> the errors of the charge counter accumulate
<uvos> its to prevent absurd values form being accepted
<freemangordon> yeah, voltage based SOC it is
<uvos> motorola came to same conclusion i gues
<freemangordon> not only, BME does the same
<freemangordon> so, I will ask upstream upower if they are willing to accept something like that
noidea_ has quit [Quit: Leaving]
noidea_ has joined #maemo-leste
noidea_ has quit [Quit: Leaving]
noidea_ has joined #maemo-leste
noidea_ has quit [Client Quit]
noidea_ has joined #maemo-leste
norayr has left #maemo-leste [Disconnected: Replaced by new connection]
norayr has joined #maemo-leste
<sicelo> buZz: btw did you upstream the droid4 keymap?
Daanct12 has quit [Read error: Connection reset by peer]
Danct12 has joined #maemo-leste
Danct12 has quit [Ping timeout: 260 seconds]
Danct12 has joined #maemo-leste
sunshavi_ has quit [Remote host closed the connection]
sunshavi_ has joined #maemo-leste
<tmlind> buZz: if you really want to charge it to 4.35 volt, first change the battery max voltage in sysfs to 4.35, then set the max charger voltage to 4.35
<bencoh> do we default to 4.2V now?
<freemangordon> tmlind: by looking at the code, that should happen automagically if you set the voltage in the charger driver. is that a bug that it does not happen?
Danct12 has quit [Ping timeout: 260 seconds]
<tmlind> freemangordon: it's that way because of the bloated batteries we had folks report earlier
<freemangordon> tmlind: maybe I didn;t explain it correctly:
<freemangordon> IIUC, in charger driver there is a code that set battery driver limit as well
<freemangordon> so, when you set charger limit to 4.35, it sets battery driver limit to 4.35 as well
<freemangordon> for some reason this does not work
<freemangordon> or, I don;t understand how it is supposed to work
<tmlind> first echo the new desired max value to the battery/constant_charge_voltage
<tmlind> then allow the charger to use it by echo to usb/constant_charge_voltage
<freemangordon> yes, but that's not what I am talking about
<freemangordon> anyway
<tmlind> well we don't want to allow the charger to set the charge voltage higher unless the allowed battery voltage is configured first
<freemangordon> ok, but shouldn;t allowed voltage be tied to design voltage?
<freemangordon> or at least set to design voltage on probe?
<tmlind> no.. at least i have zero interest ruining my batteries after few monts of connected to a dock or lapdock
<freemangordon> it will still default to 4.2
<freemangordon> because of the charger default
<tmlind> yeah that's good
<freemangordon> but having to change 2 things in a special sequence just to charge a battery to a voltage it is designed for lokks like an overkill to me
<freemangordon> *looks
<tmlind> no it's not in this case :)
<freemangordon> also, I would say that holding a mobile phone on a dock for months is not what usually happens to mobiles ;)
<freemangordon> so this is an edge use-case that shall be taken care of in the charger diver, perhaps, but not a reason to not charge to full capacity
<freemangordon> but lets not go into that now
<tmlind> well we don't know how long it takes, few weeks or few months it seems. anything higher than 4.2v you really need to do a statiscically meaningful test for let's say a year to prove that the batteries don't bloat.. so pretty much impossible :)
<freemangordon> I am much more concerned that neither sre nor greg reply :(
<tmlind> i'm mostly concerned about people ruining their batteries
<freemangordon> tmlind: when (and if) it comes to it I will send a patch that fixes that (like I already proposed, it will be really easy to wait for voltage dropping < 4.2 before starting charging again)
<freemangordon> it will take couple of weeks for that to happen if device is connected to a charger all the time
<freemangordon> actually, as uvos said, we *must* do the same for 4.2 batteries
<tmlind> yeah 4.2v batteries probably should have some lower maintenance charge voltage
<freemangordon> which we don't, basically ruining batteries of those users that did not replace their aged original ones with ordinary LiPo batteries
<freemangordon> if they keep them connected to a charger that is
<freemangordon> so, I will make/send a patch for cpcap-charger
<tmlind> hmm yeah bionic has 4.2v battery, but not sure if that too has had bloating issue
<freemangordon> why it shouldn't?
<tmlind> but please not we are not going to enable 4.35v charge by default without proper proof of it not bloating people's batteries
<freemangordon> we start charging almost immediatelly after full is hit
<freemangordon> tmlind: as I said, I'll make a patch when and if it comes to it and will try to convinc you and whoever has doubts that it will be ok
<freemangordon> but, before that I want to understand what the hell is going on and why a simple 2-liner takes 3 weeks to get a "send v2"
<freemangordon> or, why sre replies to other mails but not mine
norayr has left #maemo-leste [Disconnected: closed]
<tmlind> well you need to prove it somehow
<freemangordon> charger?
<tmlind> and it might be that it will now just take a lot longer to ruin the battery
<freemangordon> well, if lot longer is 10 years, I would say we are ok
<freemangordon> no?
<buZz> atm it seems the BMS came loose from the cell, having a hard time getting it connected back
<buZz> might just leave it as-is and fix it later
<tmlind> freemangordon: 30 devices connected to a charger for a year and i'll be happy :)
<freemangordon> tmlind: I think I can can easily prove we are fine once I have measured the time needed for a battery to self-discharge to (made-up value) 96% of its design max voltage
norayr has joined #maemo-leste
<freemangordon> tmlind: not really needed
<tmlind> in any case the logic can be there for sure, let's just not enable it unless the user really wants to do it
akossh has joined #maemo-leste
<tmlind> note that motorola was in business of selling accessories and batteries, they do not need them to last very long
<freemangordon> so, if it takes 2 weeks, you will have 24 charge cycles 4.176->4.35 fo year
<freemangordon> yet those 10yo batteries keep like 900mAh capacity
<freemangordon> so I would say they did it right for the usual mobile-phone use case
<tmlind> hmm yeah that's a good point, if the discharge to a maintenance voltage takes so long that charge cycles are very limited
<freemangordon> I don;t see why not, given that DCP charger detection works :)
<tmlind> the first bloated case i heard of was android baby monitor use case
<freemangordon> so device can be fully supplied by the charger only and battery only self-discharges
<tmlind> anyways, stuff to discuss on the mailing lists
<freemangordon> also, a dock can be easily detected and different ruls applied there
<freemangordon> sure
<freemangordon> the point was that we don;t really need 30 devices and a year to prove :p
<tmlind> well we should treat all the chargers the same
<freemangordon> how's that?
<freemangordon> USB(SDP) - max 500mA
<freemangordon> DCP - 1800
<tmlind> well take the baby monitor example, and no dock. or a trail cam use case (once the camera works)
<freemangordon> ACA - we have to measure the ID pin to detect what max charging current we can draw
norayr has left #maemo-leste [Disconnected: Replaced by new connection]
<freemangordon> tmlind: baby monitor connected to a charger (1500mA min) is perfectly fine
norayr has joined #maemo-leste
<freemangordon> because battery will only do self-discharge
<freemangordon> as the highest current reading I was able to measure here was about 1600 mA
<tmlind> well that's a theory :) i want to see some real tested-by for a long time for sure in this case
<freemangordon> hehe :)
<freemangordon> but yeah, you are right, this is to be discussed over the ML
<freemangordon> if there is anyone but you to discuss with there
<freemangordon> I am really worried about the silence
<tmlind> nah, just people busy with dealing with all the patches
<freemangordon> will see
<tmlind> pavel had some strong opinions too about the min and max voltages to preserve batteries
<freemangordon> I would love to hear his opinions
<freemangordon> but really, we need charger detection first working
<freemangordon> before that
<tmlind> yeah maybe search lore.kernel.org, i think he had some links to too there
<freemangordon> tmlind: did you see https://www.spinics.net/lists/linux-usb/msg233614.html ?
<freemangordon> with your maintainer hat on, what am I supposed to do there?
<freemangordon> fixx the drivers and framework and send a new patch?
<tmlind> yeah i don't know, it's like all the folks dealing with mobile charging disappeared 10 years ago
<tmlind> it's like nothing has happened to make things better?
<tmlind> kind of like the same story as with modem support stuff..
<freemangordon> see, it is not that I expect anything but what upstream will accept. once I know what it is, I will send a patch.
<tmlind> yeah sorry no idea how it should be done for the charger detection..
<tmlind> android probably does this all in userspace?
juustohiiri[m] has joined #maemo-leste
<freemangordon> yes
<freemangordon> afaik
<freemangordon> with the exception that it has extcon driver to detect charger types
<freemangordon> in android it seems to be called "swith" or something
<freemangordon> *switch
<freemangordon> it reports what is connected to the userspace and userspace set max current in the charger driver
<freemangordon> IIUC
xmn has quit [Ping timeout: 248 seconds]
uvos has quit [Ping timeout: 268 seconds]
<tmlind> ok
Danct12 has joined #maemo-leste
Daanct12 has joined #maemo-leste
Danct12 has quit [Ping timeout: 268 seconds]
<vectis> Hi all. I'm trying to get my D4 to connect to various audio devices that I have with bluetooth, but I can never get connected. I can pair with the devices but when trying to connect, bluetooth manager complains about a protocol not being available.
Juest has joined #maemo-leste
<Wizzup> hi
<Juest> hi, been a few years :)
<Wizzup> vectis: so...
<Wizzup> vectis: there's a few things
<Wizzup> vectis: first, you need to set it to phone class, and then secondly, you need to load the module
<Wizzup> I have some notes, I'll publish them this week
<vectis> Wizzup: I saw the video and that prompted me to try myself. How do you set it to "phone class"? Is the module the pulse one?
<Wizzup> it's in my notes, sec
<Wizzup> vectis: Class = 0x005a020c
<Wizzup> in /etc/bluetooth/main.conf
<vectis> Wizzup: Thanks, I'll give it a try.
<Juest> there's no generic image other than virtual machines still?
<freemangordon> what is "generic image"?
<freemangordon> a kind of installer?
<Juest> there's arm64-generic, how about x86_64?
<Juest> generic as in platform
ceene has quit [Ping timeout: 260 seconds]
<vectis> Wizzup: Still can't connect.
<Juest> i mean, amd64 and x86 images for running on bare metal devices to be more correct
<Juest> generic as in device kind*
<Juest> sorry for the weird wording
<Wizzup> vectis: can help tomorrow
<vectis> Wizzup: np :)
uvos has joined #maemo-leste
<sicelo> Wizzup: N900 bootloops on Leste with linux 6.1
<uvos> sicelo: yeah same here
<sicelo> oh, i thought you were not aware
<uvos> Juest: for bare-metal x86 you should be able to just install minimal devuan and install our metapackage
<uvos> idk if anyone has treid this recently thoug
<Juest> i can try that i guess
<Juest> shouldn't it be the same as the virtual machine images?
<uvos> result should be pretty mutch the same
<uvos> but ofc you have the benefit of all the stuff the devuan installer provides
<uvos> functionality wise
<Wizzup> sicelo: want me to get a trace then?
<uvos> Wizzup: so do you have an easy way to mesure power consumption
<uvos> difference in 6.1 that is
<Wizzup> uvos: well the phone just doesn't really last 2-3 days anymore :)
<Wizzup> but I don't have my accurate psu here atm
<uvos> well ok
<uvos> the compaction timers changed some
<uvos> im wondering if its related
<Wizzup> my patch nerfing them is gone, or?
<uvos> no should be there
<uvos> but they changed how the timers work
<uvos> but lets try this:
<uvos> probubly this is not it tho
<uvos> but either way we should have this in leste config
<uvos> anyhow n900 not booting
<uvos> we need some serial here
<uvos> or maybe comparing patches with a 6.1 that dose boot
<uvos> sicelo have a repo?
<Wizzup> I can help tomorrow
<uvos> Wizzup: omapconf is not anny less happy than 5.18
<uvos> so likely its extra activity of some kind
<uvos> freemangordon: btw it cant be the probe order with charging-sdl
<uvos> it opens and closes the files every time it samples the files
<uvos> so a failure to open the sysfs files the first time would not cause it to fail to work later
<uvos> ok there are some extra patches in there we dont have, and we have extra patches not in there
<uvos> we dont have an equiavlent to 0005-kernel-dma-workaround-n900-modem-oops.patch
<uvos> but you told me that allready and this should not cause it to not boot
<uvos> same with 0006-bus-ti-sysc-Add-otg-quirk-flags-for-omap3-musb.patch
<uvos> and 0009-Revert-partially-Revert-usb-musb-Set-the-DT-node-on.patch
<uvos> we also dont have 0003-ARM-dts-N900-use-iio-driver-for-accelerometer.patch
<uvos> but thats def irrelivant
<uvos> but we have lots of extras too
Juest has joined #maemo-leste
Juest has quit [Changing host]
<uvos> enable modem and increase cma size, make watchdog built in, tsc2005: disable irqs on suspend, n900: camera: magic bit makes it work, et8ek8: Support for EXPOSURE_ABSOLUTE
<uvos> so i gues ill sync it up
<uvos> tomorrow
<uvos> ttyl
akossh has quit [Quit: Leaving.]
uvos has quit [Ping timeout: 265 seconds]
Twig has quit [Remote host closed the connection]
doc has quit [Quit: Things to do]
doc has joined #maemo-leste
Danct12 has joined #maemo-leste
Daanct12 has quit [Ping timeout: 265 seconds]
xmn has joined #maemo-leste
norayr has left #maemo-leste [Disconnected: Received SIGTERM]
norayr has joined #maemo-leste
Pali has quit [Ping timeout: 265 seconds]