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