akossh has quit [Ping timeout: 260 seconds]
sunshavi has quit [Ping timeout: 252 seconds]
<Wizzup> yup dist-upgrade successful :P
<Wizzup> freemangordon: my droid 4 with chimaera mostly just works, but maemo-summoner /usr/bin/osso-addressbook.launch fails it seems
<Wizzup> I'll figure it out tomorrow or so
joerg has quit [Ping timeout: 268 seconds]
joerg has joined #maemo-leste
thunderysteak has quit [Ping timeout: 268 seconds]
<tmlind> uvos: didn't we already patch kexecboot to use KEY_END?
<tmlind> fyi, i recreated my earlier hack to allow dtc fdtdump command to decode motorola little-endian dtb files:
<tmlind> dtc -I dtb -O dts will fail with errors, but fdtdump produces somewhat readable output
<tmlind> it's against dtc at https://github.com/dgibson/dtc
<tmlind> oh dtc -f -I dtb -O dts dtbname works too
<tmlind> and with dtc the decoded addresses have wrong endianess compared to dtcdump, oh well dtcdump should do the trick anyways
<tmlind> oh and on the tablets, the vsimcard regulator is for emmc, not micro-sd
<tmlind> no, i'm confused.. dts is ok, emmc always uses vsdio, micro-sd is supposed to use vsimcard on tablets instead of vwlan2
mardy has joined #maemo-leste
uvos has joined #maemo-leste
<uvos> tmlind: your right, thats the same as mz6xx
<uvos> wierd ok so the power key in kexecboot is another problem
<uvos> tmlind: 2022-11-29 is built from the right kexecboot branch/tag right?
<uvos> android getevent for sure reports it as end
<uvos> tmlind: btw any idea what your supposed to do on xt910 if the device hangs
<uvos> both volume buttons are on the omap keymatix
<uvos> so no power+volume reset claw
<tmlind> hmm i think power+vol down works for me
<uvos> your right it works
<uvos> muss have connected the button to both somehow
<tmlind> i guess i need to check the kexecboot binaries again on mz617 for the power key, maybe i messed up something while redoing the branch
jrayhawk has quit [Ping timeout: 252 seconds]
<uvos> tmlind/ Wizzup: so whats the offending modem module called?
<uvos> id like to rescue the n900
<uvos> by blacklisting it
jrayhawk has joined #maemo-leste
elastic_dog has joined #maemo-leste
elastic_dog has quit [Quit: elastic_dog]
elastic_dog has joined #maemo-leste
jrayhawk has quit [Ping timeout: 256 seconds]
jrayhawk has joined #maemo-leste
uvos has quit [Remote host closed the connection]
<Wizzup> uvos__: nokia-modem or nokia_modem might be enough,
<Wizzup> uvos__: or just mv /etc/init.d/cellulard /etc/init.d/cellulard_
<Wizzup> so that nothing onlines the modem (iiuc)
<Wizzup> uvos__: I don't remember the other names, but there are others, it might be in the trace
uvos has joined #maemo-leste
norayr has quit [Ping timeout: 256 seconds]
<Wizzup> freemangordon: for the qt5 menu indicator, how would we/qt5 know whether the application wants to use maemo style menus, or regular qt menus
<Wizzup> freemangordon: for example in 'dorian' I simply hide the menu, and then pressing the top bar does the right thing
<Wizzup> but non-native maemo apps do not hide their menu
<Wizzup> so how do we know the application wants 'maemo' style basically is the question
<Wizzup> should I make that explicit?
<Wizzup> could be:
<Wizzup> #if defined(Q_WS_MAEMO_5) setProperty("X-Maemo-Style", 1);
<Wizzup> #endif
<Wizzup> (or even without the devices for an application)
<bencoh> I'd leave a way to change that without rebuilding any binary
<bencoh> with a default (global) config, and a per-app/context config to override it (envvar, whatever)
<Wizzup> sure, with additional env
<Wizzup> because our qt stuff is now entirely a plugin, there are no compile directives to influence qt
<Wizzup> but yeah, I was also thinking of env fallback
<Wizzup> this was I an just always render the _HILDON_WM_WINDOW_MENU_INDICATOR when an application is 'maemo mode' en has a qmenu
<Wizzup> s/en has/and has/
<Wizzup> this way* :)
<Wizzup> uvos__: opinions ^^?
<Wizzup> btw, maybe setProperty is not global enough
<Wizzup> unless setProperty can be done on the QApplication object
<Wizzup> yeah, that's a qobject thing, so that should be possible
<uvos> Wizzup: sounds fine really
<Wizzup> ok
<Wizzup> how about the env var
<Wizzup> QT_MAEMO_MODE=maemo ?
<uvos> yes with additional env var override
<uvos> oh the name
<Wizzup> yeah
<uvos> above sounds sane
<uvos> id also really really wish the menu would support qmenu hierachies by just opening one menu window after the other ie for file->action
<uvos> instead of flattening the actions
<uvos> but thats out of scope atm
<Wizzup> I was literally thinking the same right now
<Wizzup> QMaemo5ApplicationMenu::recursiveAddActions
<Wizzup> this flattens all the actions
<Wizzup> we could have it act on subsections that are pressed
<uvos> that would go a long way towards makeing regular desktop applications useable
<Wizzup> Did you also said you used a different scaling for many qt appls?
<Wizzup> apps*
<Wizzup> did you also say*
<uvos> Wizzup: yes for desktop applications i just set the QT_SCALE_FACTOR in the .desktop file
<uvos> to make them most useable
<Wizzup> ok
<uvos> usually 1.2 or so
<Wizzup> I wonder if I could also detect if an application is linked against maemo components, then we could also auto enable the property
<Wizzup> $ ldd $(which dorian) | grep -i maemo libQt5Maemo5.so.5 => /usr/lib/x86_64-linux-gnu/libQt5Maemo5.so.5 (0x00007fd414597000)
<uvos> the heuristic here being if the desktop file is in hildon subdir or not
<uvos> its not that ideal tho since it affects only applications launched via h-d, not xterm or so
<Wizzup> well what I mean is here the qt platform plugin could know automatically if it is maemo without the app calling setProperty("X-Maemo-Style", "maemo")
<uvos> also idk if autodetecting the scale factor in particular is sane
<Wizzup> yeah, not sure if it is
<uvos> its not
<Wizzup> btw that PR has 'X-Maemo-Hilon' everywhere
<Wizzup> not 'X-Maemo-Hildon'
<uvos> Wizzup: this pr is abandoned
<uvos> since freemangordon dident like it at all
<uvos> so it wont be merged ever anyhow
<Wizzup> ok
<Wizzup> maybe close it then as such
<uvos> well i like mergeing it privately, but yeah i can keep it in a branch instead
<uvos> anyhow so with some applications i use fusion and a scale factor, with others i use maemo style (which is bigger allready) and no scale factor and with some i use maemo style and a scale factor (mostly qml)
<uvos> so scale heurisic istent going to work imo
<Wizzup> right
<Wizzup> your qml apps automatically get the maemo style?
akossh has joined #maemo-leste
<uvos> no ofc not (besides dialogs and sutch) thats not how qml works
<uvos> but dialogs and sutch are a thing :)
<Wizzup> right
<Wizzup> please feel free to suggust more
<Wizzup> (there's vkb I guess)
<tmlind> uvos: power button fails with the most recent image also on mz617, will try to figure out what i messed up
<uvos> tmlind: ok, probubly just built the wrong commit in buildroot ;)
<uvos> wtf is this and how is it building d3 and n900 dts
<Wizzup> uvos: for sure there are others, but I am not sure this is used
<Wizzup> ./scripts/package/mkdebian
<uvos> lets just remove this then, its confusing
<Wizzup> yeah, I need a bit of time to remember this
<Wizzup> I'll brb, but can look at this when back
<Wizzup> afaik we just build all dtbs really
<Wizzup> and maemo-kernel-config copies things
<uvos> tmlind: btw i disagree to calling the phone common dts "droid"
<uvos> 1. the xyboard was sold as the droid xyboard when sold via verizon contract
<uvos> 2. the name "droid" was owned by lucas arts and licenced to verizon only, and they used this name as a prefix or as the name of all thair devices during this time period, not just motorola devices
<uvos> 3. because the the droid name was licenced to verizon not motorola all the phones where sold under other names outside the us (ie droid 1/2/3/4 -> milestone 1/2/3/4, droid razr -> razr etc)
<Wizzup> uvos: dpkg -L linux-image-omap has all the DTBs it seems
<Wizzup> so as long as you add it to kernel makefile it should be fine
<tmlind> uvos: well do you have some better name in mind? i used motorola-mapphone-phone.dtsi, but has phone twice..
<tmlind> updated droid4-kexecboot images pushed out to https://github.com/tmlind/droid4-kexecboot/tree/master/2022-12-04
<tmlind> i updated kexecboot in buildroot, not sure why the patch did not get picked up when i built few days ago
<uvos> i dont see why we should shy away from phone twice, motorola used "mapphone" for tablets, hardly our fault :P
<tmlind> i also though about motorola-mapphone-handset.dtsi
<uvos> that would be good too
<tmlind> ok let's use that then
<tmlind> i noticed aliases are still there for xt910-xt912 shared file, will remove the aliases
<tmlind> any other issues known?
<uvos> Wizzup: i dont follow the package hardly contains "all" dtbs
<uvos> tmlind: not yet
<tmlind> ok
<tmlind> will push out v2 branch shortly then
<uvos> tmlind: maybe you could add d3 dts
<uvos> and rename motorola-mapphone-xt875-xt894.dtsi motorola-mapphone-xt8xx.dtsi
<uvos> since it now covers xt86x too
<uvos> and not mz6xx or xt9xx
<tmlind> ok
<uvos> tmlind: sec ill push d3 dts
<tmlind> ok
<tmlind> hmm need to check tmp105 is not there on tablets
<Wizzup> uvos: did you fix up the d3 keymap? I don't remember if I fully finished it
<uvos> yes
<uvos> keymap is fine
<Wizzup> great
<tmlind> uvos: can you do a proper d3 dts patch for mainline? leave out ramoops lcd etc stuff that does not related to mainline
<uvos> tmlind: sure
<uvos> but rn it depends on your wip stuff
<uvos> (dtsi rearangeing)
<tmlind> then i can rebase patches on v6.2-rc1 and send them all to the lists
<tmlind> ah ok yeah few mins
<Wizzup> just for the record, the xt86x has stability issues, but it's not clear those are related to the dts
<uvos> i dont think this should excude it from mainline, d4 as stability issues too :P
<Wizzup> right, just wanted it to be clear/known :)
<uvos> besides im tired of rebaseing it whenever the other dts changes :P
<Wizzup> :)
<tmlind> we're better off if we have minimal skeleton device dtsi files in the mainline, makes patching in devices easier
<tmlind> and a lot of features already work on all of them
uvos__ has quit [Ping timeout: 246 seconds]
<tmlind> hmm so tmp105 is there on tablets, need to check if it's on the same bus
<tmlind> yeah i'll add tmp105 to the mapphone-common.dtsi
<uvos> oh btw
<uvos> tmlind: xt91x was updated to android 4.1 with a slightly different kernel than d4
<uvos> tmlind: its possible that on devices updated to 4.1 the kexec modules for the kernel shipped with android 4.0 wont work
<uvos> tmlind: but we can just flash the 4.0's kernel, but this might break android (no idea)
<uvos> we cant fully downgrade because some fuses where blown
<uvos> at least if its the same as xt875
<uvos> for some reason xt894/mz6xx where never updated so they dont have this problem
<Wizzup> they probably decided the d4 was locked down enough as it is in the modem :P
<uvos> well its mostly a android version update
<uvos> with new features
<Wizzup> (it was a joke :) )
<uvos> im german, we don't do jokes.
<Wizzup> ;)
<tmlind> uvos: ok
<tmlind> heading out here now, bbl
<Wizzup> ttyl :)
<uvos> ttyl
<uvos> Wizzup: ok so i pushed a new maemo-6.1 that supports xt910
<uvos> but i still dont get where the package decides what to include dtb wise
<Wizzup> so all dtb'd are in the package
<Wizzup> the question I think is what end up in boot
<uvos> thats mapphone-kexecboot-config
<uvos> package
<uvos> thats not the problem
<Wizzup> yes, exactly
<Wizzup> so what is the problem?
<uvos> but the not _all_ dtbs are in the package
<Wizzup> are you sure?
<uvos> thers only d4, xt875, n900 and d3
<Wizzup> 141
<Wizzup> # dpkg -L linux-image-omap | grep dtb -c
<Wizzup> # ls /usr/lib/linux-image-omap/*.dtb | wc -l
<Wizzup> 141
<uvos> ok but ls /boot/boot/
<uvos> who decides what ends up there
<Wizzup> afaik that is mapphone-kexecboot-config
<uvos> dont see it
<Wizzup> ok
<Wizzup> 5 mins
<Wizzup> ok, I think I recall now
<Wizzup> see scripts/package/builddeb
<Wizzup> in maemo-6.1
<Wizzup> (droid4-linux)
<uvos> sure i greped that file for mapphone
<uvos> dosent contain
<uvos> oh because the dtb dont contain that string
<uvos> duh
<uvos> ok
<uvos> found it
<Wizzup> great
<Wizzup> and yeah it's not perfect, but it works
<uvos> the debian/rules way seams way more obvious
<uvos> how is this better?
<Wizzup> this gets updated with the kernel releases
<Wizzup> I don't know anymore, it's been a few years since we switched
<Wizzup> I have root on my xt912 4.0.4 now btw
<uvos> ok as tmlind mentioned could you check the partion table?
<Wizzup> ok
elastic_dog has quit [Ping timeout: 246 seconds]
<uvos> Wizzup: what section shal we put xt910?
<Wizzup> what package specifically?
<uvos> xt912-kexecboot-config
<uvos> its
<uvos> Package: bionic-kexecboot-config
<uvos> Section: bionic
<uvos> etc
<Wizzup> you can make it Section: razr
<Wizzup> or something like that
<uvos> to follow this mold we need one section for xt910 and one for xt912 even
<Wizzup> so
<Wizzup> as far as I can concerned it can be section: mapphone
<uvos> since they need different dtb
<Wizzup> and we can just put all future stuff in there
<uvos> ok
<Wizzup> the only use for the sections is that it -can- make package dep resolving easier
<uvos> so what shal i do rn
<uvos> change all of them to mapphone?
<Wizzup> and I think if we simply have an explicit meta for each device we don't need it
<Wizzup> either that or make it razr :P
<Wizzup> we also have just 'droid3', not 'xt860', 'xt861', 'xt862'
<uvos> sure but all d3 have one dts
<Wizzup> 30s
<uvos> xt91x are more like different phones in this way
<uvos> and differ way more than d3 varaints
<uvos> anyhow ill just make everything mapphone here
<uvos> and check if the metapackage is sane
<Wizzup> ok so there is a reason not to go for Section: mapphone
<uvos> yes?
<Wizzup> wait, is that even true... hm
<Wizzup> I think you can just leave Section empty really
<uvos> so one problem with makeing things mapphone
xmn has joined #maemo-leste
<uvos> is that current installs dont have it
<Wizzup> we don't want phones that just have a 'droid4' component to not get updates
<Wizzup> yes exactly
<uvos> in the deb string
<Wizzup> but if you just omit the section it should just land in the normal ones
<Wizzup> I don't think there's a reason we really need separate sections even
<uvos> no is shal make everything d4
<uvos> since bionic is just an overlay of d4
<Wizzup> why not just omit Section?
<uvos> and bionic has droid4 bionic in its sections
<uvos> for this package thats fine
<uvos> but for others its not
<Wizzup> I'd rather not have droid4 everywhere in chimaera
<Wizzup> if you omit the section, it should just work
<uvos> for this package yes
<Wizzup> the main reason we would want section is to prevent users from say installing n900 kernel on d4
<Wizzup> (even though it's a shared kernel, but you get the idea)
<uvos> but we have packages where we have a mapphone variant
<uvos> with the same name
<uvos> that shal only be installed on mapphones
<Wizzup> uvos: which packcages?
<uvos> the droid4 section is currently used for this
<uvos> in the past at least ofono, not sure if we changed this
<Wizzup> we have a unified ofono
<Wizzup> (now)
<uvos> also mesa, but i unified this one
<uvos> so not sure
<uvos> maybe we dont anymore
<Wizzup> I think I'd just remove the section for now, and if we need it, we can go for a shared mapphone
<uvos> ok
<Wizzup> (remove the section from debian/control)
<Wizzup> let's do experimental for now -just in case-
<uvos> well for this package its fine for sure
<uvos> ill remove parazyd and add myself as maintainer too ok?
<Wizzup> sure
<bencoh> :)
<uvos> ERROR: Permission to maemo-leste/mapphone-kexecboot-config.git denied to IMbackK.
<uvos> Wizzup: pls
<Wizzup> done
<uvos> Wizzup: ok checks out
<uvos> you can use xt910 kexecboot/ utags
<Wizzup> am I crazy or do they just contain zeroes
<uvos> yes
<uvos> that exactly what we want to see
<Wizzup> ok
<uvos> if p13 dident contain zeros this would mean the baseband software parttion would be used for something
<Wizzup> check
<uvos> so it wouild be bad if you just overwrote that with kexecboot
<Wizzup> :)
akossh has quit [Ping timeout: 256 seconds]
<tmlind> Wizzup: ok yeah so first flash allow-mbmloader-flashing-mbm.bin
<uvos> they doubled the size of mbm sometime between edison and maserati
<uvos> never noticed before
<Wizzup> tmlind: ok, let me find a xt912 fw with that file
<uvos> just linked the file
<Wizzup> ah, so spyder
<Wizzup> ty
<uvos> xt912 = droid razr = sypder
<uvos> simple :P
<Wizzup> yep
akossh has joined #maemo-leste
<Wizzup> uvos: ok, flashed that
<uvos> just follow regular kexecboot install procedure
<Wizzup> It isn't clear to me if I need to re-do my dd commands after I flashed this
<Wizzup> ok
<uvos> with the xt910 files
<uvos> no
<uvos> unless you flash the xt910 bootloader
<uvos> well even then
<uvos> we just established the partition table is the same
<Wizzup> do I still need to flash utags - I guess with the xt910 files as you said?
<uvos> yes
<Wizzup> ok
<Wizzup> that's the files I d/l'd for you yesterday?
<uvos> yes
<Wizzup> the ones here: https://archive.org/~merlijn/uvos/ ?
<Wizzup> ok
<Wizzup> I'll use VRZ_XT912_6.7.2-180_DHD-16_M4-31_1FF.xml.zip
<uvos> sure
<uvos> any will work you can flash any bootloader
<uvos> they never blew any fuses
<Wizzup> :)
<Wizzup> I like the razr screen, will be cool to see maemo on it
<uvos> oled
<Wizzup> yeah
<uvos> Wizzup: ERROR: Permission to maemo-leste/mapphone-kexecboot-config.git denied to IMbackK.
<uvos> ?
<uvos> (dident change)
<tmlind> Wizzup: here are the commands to try just in case, use today's droid4-kexecboot files:
<tmlind> fastboot flash mbm allow-mbmloader-flashing-mbm.bin
<tmlind> fastboot reboot bootloader
<tmlind> fastboot flash utags utags-xt910-16-mmcblk1p8-boots-mmcblk1p13-kexecboot.bin
<tmlind> fastboot flash cache droid4-kexecboot.img
<tmlind> fastboot reboot
elastic_dog has joined #maemo-leste
<tmlind> sorry
<tmlind> fastboot flash bpsw droid4-kexecboot.img, cache is only used on the tablets
<Wizzup> tmlind: thanks, I had the droid 4 wiki page open, looks similar
<Wizzup> uvos: did you accept the invitation?
<Wizzup> uvos: I can't "add" people, only "invite" them
<uvos> ah right yes im not in the orga
<uvos> so you can only invite
<Wizzup> I want to take another look at how we do this
<Wizzup> take myself out of the equation a bit if possible
<Wizzup> kexecboot shows up
<Wizzup> I don't think it wants to boot stock android at this point
<uvos> dident want to here either
<uvos> this state is dangourous
<uvos> since you cant charge
<Wizzup> right
<uvos> and you cant shutdown eihter
<uvos> since the power key dosent work
<Wizzup> it does now I think
<uvos> ah right ok
<uvos> tmlind updated kexecboot
<uvos> Wizzup: if you want to get out of this state
<uvos> fastboot erase utags
<uvos> and fastboot reboot
<uvos> to charge a bit in android
<Wizzup> the battery is full, it's all good
<Wizzup> I just turned it off
<buZz> hmmm, if i switch to a fullscreen application, compositing is now always off?
<buZz> ctrl-shift-N makes it fast again, but kinda annoying, did this change?
<Wizzup> buZz: that was always the case
<buZz> oh, ok
<buZz> guess i never noticed prior
<Wizzup> unless you meant to say ON and not OFF
<buZz> hmmm not sure
<buZz> its a fullscreen chromium window
<buZz> i dont remember experiencing such fullscreen windows to slow down from switching, but maybe i never noticed
<uvos> this is not true
<Wizzup> I guess we also ought to rework how the image building works at this point
<Wizzup> it's kind of senseless that build so many images that are almost entirely identical
<Wizzup> droid3/droid4/bionic (and soon razr/mz609/mz617,....)
<buZz> uvos: what isnt?
<tmlind> Wizzup: sounds like the stock boot.img initramfs offset is different on your firmware if stock android won't start
<uvos> tmlind: it dosent boot here eihter
<uvos> btw
<Wizzup> tmlind: hm, ok, it sounds like uvos had the same on his xt910 - this is xt912
<uvos> yes xt910
<uvos> hildon dosent suspend compositing since it wants to display banners
<uvos> @buZz
<uvos> or the volume thingy
<buZz> uvos: fullscreen windows dont show hildon
<tmlind> yeah ok i'll i'll add the xt912 initramfs offset to kexecboot
<uvos> buZz: the notification banner
<Wizzup> tmlind: need any info from me?
<uvos> or the volume banner
<uvos> those things
<buZz> uvos: fullscreen windows
<uvos> buZz: yes
<uvos> buZz: open fullscreen window
<uvos> press vol up
<uvos> whach what happens
<buZz> pressing volume -does- reenable compositing, nive
<buZz> pressing volume -does- reenable compositing, nice tricks
<uvos> exactly
<buZz> but would be nicer to use the fs program without having to do ctrlshiftN all the time :P (or volume buttons)
<buZz> can i force it alwayson for a program?
<Wizzup> yes, this is an atom the program can set afaik
<uvos> there is a hildon hint
<Wizzup> I don't know if it fully overrides it
<uvos> but this is silly
<uvos> since h-d can just do what every other wm dose
<uvos> and suspend whenever there is only one window
<Wizzup> looks like my mz617 is android 4.1.2
<buZz> well, chromium improves greatly in speed from having it on
<uvos> working on mz617 is painfull, no sdcard no allow-mbmloader...
<uvos> no bpsw, flashing kexecboot to cache makes android buggy
<buZz> even 'windowed' you can notice the speed difference a lot
<uvos> yes compoiting is extreamly hevy
<buZz> no, -without- compositing it is slower
Juest has joined #maemo-leste
<uvos> thats wierd
<buZz> try it
<buZz> with it on, i can even use youtube, without its too slow
<uvos> at least scrolling on bbc news
<uvos> suspended is mutch faster
<buZz> try in hildon
<uvos> yes in hildon
<Wizzup> uvos: well it sounds like tmlind had it working
<buZz> not what i'm seeing, lol
<uvos> Wizzup: might be android 4.1 vs 4.0.4
<uvos> we both have 4.0.4
<uvos> tmlind: ^^ ?
<Wizzup> uvos: I mean on mz617
<uvos> what now
<uvos> my mz617 works fine
<uvos> booting android after kexecboot
<uvos> but you break androids chache
<uvos> that dosent stop it form booting
<uvos> but there are issue
<uvos> s
<Wizzup> yeah, so my remark about tmlind had it worked was about mz617, and your comment wrt kernel versions was about razr :)
<uvos> right
<Wizzup> kind of a shame that the mz617 doesn't have a microsd card yeah ;)
<Wizzup> slot*
<uvos> and the bootloader...
<uvos> it has a microsdcard slot btw
<Wizzup> hm
<uvos> motorola dident populate it on us variants
<Wizzup> I was looking at mine and it looks like there's space for it
<uvos> for some reason
<uvos> but its there
<uvos> behind a plastic cover
<uvos> (the footprint, its not populated)
<Wizzup> ah, so if you cut the plastic open it is there? ok
<Wizzup> ok, so without a holder
<uvos> yes
<Wizzup> well, that's not too hard to fix :p
<buZz> hmhm yeah, after volumebar fades out, it switches comp back off, slow again, ONLY on fullscreen, not on windowed
<Wizzup> buZz: so 'comp off' and 'slow again' doesn't make sense to me
<Wizzup> you mean 'comp on'
<buZz> Wizzup: no
<Wizzup> unless I'm going nuts
<uvos> he is reporting some bug
<Wizzup> how can compositing being off make things slow?
<uvos> i cant repo it
<Wizzup> aha
<tmlind> uvos: yeah cache can be flashed.. could not find other partition
<uvos> omapddx could misbehave
<buZz> comp -off- on -fullscreen- chromium windows makes them slower
<uvos> with comp on h-d renders the frame
<uvos> off omapddx dose
<tmlind> Wizzup: care to flash cdma_spyder_9.8.2O-72_VZW-16_1ff.xml.zip. on your xt912 and i'll provide an experimental kexecboot image to try?
<uvos> there might be something wrong in omapddx
<buZz> uvos: it does render, but a lot slower
<tmlind> we need to figure out how to extract the initramfs address dynamically..
<buZz> might be the 'reboot device, your gpu is in weird state'
<buZz> i'll try
<Wizzup> tmlind: I will need to find that image first, but then I'm happy to try. I also have two here, one with kernel 4.1.2 (or so), if that's what you'd like me to try?
<uvos> *android 4.1.2
<Wizzup> uvos: yes ty
<Wizzup> https://rootjunkysdl.com/?dir=Droid%20Razr%20Maxx/Jelly%20bean%20update%20from%208%20to%2016 looks like it's here (the file)
<tmlind> ok
<Wizzup> uvos: left a comment
<Wizzup> uvos: wait, is your razr 4.0.4 or 4.1.2 ?
<uvos> 4.0.4
<Wizzup> ok
<uvos> my 4.1.2 razr is also 404
<Wizzup> I don't understand that :)
<Wizzup> 404 as in http?
<uvos> yes i dont have one
<uvos> fixed @pr
<Wizzup> I thought you didn't do jokes
<Wizzup> ;)
<uvos> who says what is joke and what is not?
<Wizzup> the joke police?
<Wizzup> uvos: btw the leste-config change was for Section: droid4, I assumed that was intended
<uvos> yeah
<tmlind> Wizzup: here are the xt912 test images to try after you've updated the firmware to cdma_spyder_9.8.2O-72_VZW-16_1ff.xml.zip http://muru.com/linux/d4/test/
<uvos> Wizzup: btw images
<uvos> we should just disrobute boot and root seperatly
<uvos> hmm nvm
<uvos> that dosent help because of leste-config
<uvos> what is cdma_spyder_9.8.2O-72_VZW-16_1ff.xml.zip?
<uvos> android version wise
<uvos> i dont know if updateing to 4.1 and blowing the fuse is a good idea
<Wizzup> uvos: I was planning to use my 4.1.x one
<Wizzup> if that makes sense
<uvos> then it probubly wont work if its not a 4.1 image
<uvos> at least thats how it works on bionic
<tmlind> anybody have a good shell trick in mind to extract the initramfs address with busybox sh? multiple matches with grep -oban $'\x1f\x8b' boot.img..
<buZz> alright, took 4 powercycles, but now chromium fullscreen is just as fast with compositing enabled as disabled
<Wizzup> tmlind: I can try to help, if that's the grep command to start out with
<uvos> hmm
<uvos> @buZz
<buZz> guess its the gpu bug freemangordon spoke about before
<uvos> probubly
<uvos> vsync behavior is different in these modes
<uvos> must be some timeing bug with cm pannel
<buZz> -some- boots he couldnt get yt playing fast, but 'normally' it works
<uvos> or something like that
<uvos> buZz: did you hard reboot (via power off)
<uvos> or reboot
<buZz> yes , poweroff
<buZz> 'reboot' rarely ever helps
<uvos> right
<buZz> sounds familiar? :)
<uvos> reboot not helping makes sense since not all regisers reset
<uvos> but no i have not seen the perf bug
<uvos> (or noticed at least)
<buZz> maybe we can somehow overwrite 'all registers' with knowngood values?
<Wizzup> uvos: btw I think the release tmlind mentioned is 4.1, judging from https://forum.xda-developers.com/t/index-motorola-droid-razr-2012.3023837/
<uvos> no also resigers was the wrong word
<uvos> i ment hw state in general
<uvos> not only accessable regisers
<buZz> ah hmhm
<uvos> maybe boot android and see if that helps
<uvos> it might know how to get the hw in the right state better
<uvos> (as a workaround only ofc)
<Wizzup> tmlind: busybox might have 'xxd' it makes grepping any easier
<Wizzup> I'm assuming it's here somewhere (the first hit):
<Wizzup> 00004e40: 6f72 0000 756e 636f 6d70 7265 7373 696f or..uncompressio
<Wizzup> 00004e60: 0203 9cfd 0f78 54c5 f53f 8edf bb7f 9225 .....xT..?.....%
<Wizzup> 00004e50: 6e20 6572 726f 7200 1f8b 0800 0000 0000 n error.........
<Wizzup> yeah, ok
<uvos> Wizzup: sphone should build now
<uvos> (for chimaera)
<uvos> glib docs where simply wrong
<buZz> w00t
<buZz> uvos: could you have the sphone txt displays be selectable? so i could copypaste numbers from it to contacts
<buZz> specifically the sms inbox
<uvos> sure but needs some thought how to do exactly
<buZz> maybe just a longhold->copynumbertobuffer ?
<uvos> dunno
<uvos> needs to work well on desktop and on leste
<uvos> needs some thought as i say
<buZz> either way its now 'write number on paper' and then switch to other
<buZz> program to enter it
<buZz> lol
<uvos> sure it needs some kind of method
<uvos> maybe you can copy from abook (for now)?
<buZz> nope
<buZz> you cant get details for contacts that dont exist, try it
<uvos> ok
<buZz> adding a 'import this unknown contact' in abook would be cool too
<buZz> ooo, i guess i could just dump the db in xterm and copy there
<uvos> or allways run sphone in verbose mode and copy it from its logs xD
<Wizzup> tmlind: busybox xxd -p -c 10000000 boot.img this can make it one simple line of hex, and with normal grep you can then find the offset with --byte-offset
<Wizzup> but busybox grep doesn't have --byte-offset
<uvos> Wizzup: btw regarding not building almost identical images.
<uvos> at least we are not behind here, even los with a huge amount of devcies in support do this
<Wizzup> yeah, it's just that it's slow I guess, that's what bothers me
<Wizzup> in the next two months my living place should stabilise and I'd have more room to improve it
<Wizzup> s/place/situation/
<Wizzup> uvos: I can try to build a razr image?
<Wizzup> I guess we might need a meta update for it
<uvos> yes
<uvos> theres more stuff
<Wizzup> apart from hildon-meta ?
<uvos> no probubly not
<uvos> but i was going to try and flash d4 image
<uvos> update to expiramental on d4
<Wizzup> yeah that's easier/better
<uvos> and then change boot.conf by hand
<uvos> and shove the sd into a razr
<Wizzup> cp: cannot stat '/usr/lib/linux-image-omap/omap4-razr-xt910.dts': No such file or directory
<Wizzup> maybe I'm not n experimental
<buZz> maybe we just need a faster CI server? :P
<uvos> buZz is paying
<buZz> hehe
<Wizzup> I don't think buzz has any idea how fast it already is
<buZz> what do we have? maybe i can find some hw for free
<uvos> thats why he is paying
<Wizzup> it's just the image building process itself that involves a lot of network fetching and otherwise i/o stuff on loopback mounted cr*p
<buZz> ah right
<buZz> needs nvme and optane i guess , hehe
<Wizzup> we have this
<buZz> ah cool
<Wizzup> good luck trying find anything better that's affordable :)
<Wizzup> well not the 1U one, but the workstation one :P
<uvos> i gues we could farm out the image building to an amd64 machine
<Wizzup> I think that is exactly what happens
<Wizzup> so it does qemu-user emulation
<Wizzup> for some of it
<uvos> oh ok
<Wizzup> there's many reasons it's slow, but the hw isn't the main reason, IIRC
<Wizzup> in any case...
<buZz> yeah that would be my idea too, x86 old servers are cheaper than arm ones
<Wizzup> uvos: so there's some weird mismatch for me, is the razr dts included in the experimental kernel?
<uvos> hopefully, cant check rn, makeing food
<Wizzup> cp: cannot stat '/usr/lib/linux-image-omap/omap4-razr-xt910.dts': No such file or directory
<Wizzup> shouldn't that be DTB?
<uvos> might be my typo yeah
<Wizzup> and also xt912
<Wizzup> not xt910
<uvos> i added both
<Wizzup> well the xt910 isn't in the package I have :)
<uvos> ok probubly dtb dts typo somewhere
<uvos> brb
<Wizzup> yes, typo, but also xt910 is not in the package
<Wizzup> # dpkg -L linux-image-omap | grep xt9
<Wizzup> /usr/lib/linux-image-omap/omap4-razr-xt912.dtb
* Wizzup also taking a break
<Wizzup> tmlind: I didn't quite figure out the grep thing, sry
<tmlind> yeah np
sunshavi has joined #maemo-leste
<uvos> Wizzup: found 2 issues and rebuilding kenrel
<Wizzup> uvos: are you sure that the xt910 dts is included
<Wizzup> ah
<Wizzup> ok
<Wizzup> I clicked the same commit twie
<Wizzup> twice
<tmlind> heh hd boot.img | head -n1 | cut -d' ' -f12,13,14,15 | sed -e 's/ //g;' | tac -rs ..
<tmlind> gets the kernel size, then presumably the initramfs is 5 * 1024 after that
<tmlind> this might work:
<tmlind> kernel_size_hex="0x$(hd ${boot_img} | head -n1 | cut -d' ' -f12,13,14,15 | sed -e 's/ //g;' | tac -rs .. | tail -n1)"
<tmlind> kernel_pages=$((${kernel_size_hex}/1024))
<tmlind> initramfs_offset=$(((${kernel_pages}*1024) + (1024 * 3)))
<bencoh> where did you get the 1024*3 from?
norayr has joined #maemo-leste
Twig has joined #maemo-leste
<tmlind> well there's a header.. the pages need to be rounded up so the above is buggy
<tmlind> still having issues though
<tmlind> here's my current buggy version:
<tmlind> boot_img="${1}"
<tmlind> ks="$(hd ${boot_img} | head -n1 | cut -d' ' -f12,13,14,15 | sed -e 's/ //g;')"
<tmlind> kernel_size_hex="0x${ks:6:2}${ks:4:2}${ks:2:2}${ks:0:2}"
<tmlind> dd if=${boot_img} skip=${initramfs_offset} bs=1 count=4 | hd
<tmlind> kernel_pages=$((((${kernel_size_hex} + 1023) & ~1023) / 1024))
<tmlind> initramfs_offset=$(((${kernel_pages}*1024) + (1024 * 2)))
<tmlind> for some cases it needs (1024 * 3), for some cases (1024 * 2), not sure if there is sometimes an empty page between kernel and initramfs
<bencoh> isn't that because they want some "aligned" adress for initramfs?
<tmlind> hmm yeah.. and i think it needs to be page aligned 0x800 + kernel_address
thunderysteak has joined #maemo-leste
alex1216 has joined #maemo-leste
<tmlind> hehe this one seems to work so far for me:
<tmlind> boot_img="${1}"
<tmlind> ks="$(hd ${boot_img} | head -n1 | cut -d' ' -f12,13,14,15 | sed -e 's/ //g;')"
<tmlind> kernel_size_hex="0x${ks:6:2}${ks:4:2}${ks:2:2}${ks:0:2}"
<tmlind> echo "kernel size: $((${kernel_size_hex}))"
<tmlind> align=$((2048 - 1))
<tmlind> initramfs_offset=$(((0x800 + ${kernel_size_hex} + ${align}) & ~${align}))
<tmlind> echo "initramfs at: ${initramfs_offset}"
<tmlind> dd if=${boot_img} skip=${initramfs_offset} bs=1 count=4 | hd
<Wizzup> sweet
<Wizzup> did you still need me to try this .xml.zip file, and shall I try it on my already 4.1.2 razr then?
<tmlind> Wizzup: sorry can't follow what you mean, which firmware do you have now?
<Wizzup> tmlind: so I had a razr with some 4.0.4 on it, that I didn't clean-flash, and I put kexecboot on that one. I also have a 4.1.2 razr that I haven't put kexecboot on it yet, then you asked me to try it (kexecboot) with cdma_spyder_9.8.2O-72_VZW-16_1ff - which is 4.1.2 iiuc
<Wizzup> uvos said maybe it's not a good idea to upgrade my 4.0.x to 4.1.x so I said I can flash it to the razr that is already on 4.1.2
<Wizzup> I'm just checking if you still wanted me to flash cdma_spyder_9.8.2O-72_VZW-16_1ff to my 4.1.2 and see if kexecboot works with that
<tmlind> Wizzup: ok if you did not yet update, please just wait a bit then :)
<Wizzup> ok :)
<uvos> Wizzup: booting a new d4 image
<uvos> it stalled for a really really long time generating ssh keys
<uvos> probubly rand starvation
alex1216 has quit [Quit: WeeChat 2.3]
<tmlind> somehow similar changes in preinit.sh are not working yet.. need to debug with a serial console at some point, have to give up for now
<uvos> aand like an idiot i pushed the sdcard into xt910's simcard slot
<uvos> and now having a hard time getting it out
<norayr> uh
<norayr> sicelo, i got an n900 from someone who knows me and doesn't want to use it anymore.
<norayr> but no leste on it yet.
<norayr> i checked live wallpaper and apparently the board there doesn't have a message under fremantle as well.
<norayr> so i need ho figure out where the message should come from, if there should be any.
<norayr> maybe some http connection became https?
<norayr> or maybe the site doesn't exist anymore.
<norayr> anyone remembers live wallpaper's modern theme behaviour ten years ago?
<uvos> my xt910 is in hildon!
<uvos> tmlind: theres something wrong with the pannel timeing
<uvos> tmlind: it rolles like a tv out of hsync
<uvos> sensors dont work yet
<uvos> interesting
<uvos> on xt910 the buttons on the bottom are _not_ part of the main touch screen
pere has quit [Ping timeout: 256 seconds]
<sicelo> norayr: i never used live wallpaper
<uvos> none of the leds work
<uvos> besides notification
<tmlind> uvos: cool that you got it going :)
<tmlind> later
<Wizzup> uvos: sweet
<uvos> Wizzup: im doing inital wiki page
<uvos> im noticing how out of date the d4 page is....
<uvos> can you include stuff on media wiki
<uvos> ie if i write a section on bluetooth
<uvos> can we just include that on the xt875,xt894 and xt91x pages?
<sicelo> using templates is one of the best/easiest ways to achieve that
<uvos> sicelo: ok
mardy has quit [Quit: WeeChat 3.5]
<uvos> anyhow its not very happy: http://uvos.xyz/maserati/videos/razr.mkv
<uvos> apt reinstall firmware-ti-connectivity
<uvos> Reinstallation of firmware-ti-connectivity is not possible, it cannot be downloaded.
<uvos> uh what now
<uvos> (same on my main d4)
<uvos> apt install firmware-ti-connectivity
<uvos> firmware-ti-connectivity is already the newest version (20190114-2).
<sicelo> apt-cache policy might tell you where it expects to download it from, and you can hopefully then figure out why it can't
norayr has left #maemo-leste [Error from remote client]
norayr has joined #maemo-leste
pere has joined #maemo-leste
Twig has quit [Remote host closed the connection]
<sicelo> talking about leds, uvos, i think you said the green charging led is hardcoded or something? it's hardcoded in hw, that is?
* sicelo wishes it could blink
Juest has quit [Quit: Client closed]
<uvos> cpcap dose that in hw
<uvos> however there is a register to turn it off
<uvos> the mainline kernel dosent have any way to set this
<sicelo> so i guess cpcap-charger would need to be unloaded, then manually toggle the register (via i2c?) ?
<buZz> (its shitty-sung on purpose btw, lol)
<uvos> sicelo: no the mainline kernel resets these resigers as part of its inialization code
<uvos> you have to patch the driver
<uvos> cpcap is on spi
<buZz> afaik the mainline kernel -does- have support to blink that led, at least in white ... i think maybe other colors too?
<buZz> even has a 'charging' triggermode
<buZz> not sure if it would be flashing though, hmm
<sicelo> when connected to a charger, the led becomes green and cannot be controlled. you can write any value to /brightness, with no effect
<sicelo> but yes, at other times, you can do what you want
<buZz> right
<buZz> maybe the keyboard capslock light can be used for your purpose? :D
<sicelo> no. because that requires keyboard to be slid out first before it can be useful as a notification light
<sicelo> anyway, i just wanted to know if there was no way to retain control of that LED while charging
<sicelo> fwiw, N900's charger also does the same thing to the LED, except in its case, it's not hard to disable that function and retain control of LED
<uvos> its not hard with cpcap either
<uvos> just 1 bit in a register
<uvos> the problem is more that there is not really a standart userspace interface you could use
<uvos> also personally i dont care since i like the hw control
uvos has quit [Quit: Konversation terminated!]
<buZz> sicelo: ooo, the backlight of the 4 hw touchbuttons? :D
<buZz> hahaha
<buZz> hahahahahahaha, as root ; echo "battery-charging-blink-full-solid" > /sys/class/leds/button-backlight/trigger
<buZz> not sure if it works when screen is off
<buZz> i guess not :/
<buZz> hmm oh, someone is turning off the trigger :D
Juest has joined #maemo-leste