| vectis | Douh yeah, sorry for asking. It's been a long time since I tried any of this. | 01:03 |
|---|---|---|
| Wizzup | vectis: not sure why it doesn't work by default | 01:05 |
| bencoh | Wizzup: probably because osso-xterm spawns a login shell instead of a regular one | 01:06 |
| vectis | So I have compiled evilvte (terminal emulator) for droid4 and it works, but the caps seem to be on by default. I can get lower case by pressing caps, but I have to do this for every letter. | 01:24 |
| Wizzup | that seems odd? | 01:26 |
| vectis | Yep, no issue in osso-xterm | 01:27 |
| vectis | I've used evilvte for many years on my collection of n810's and thought it would transfer OK over to Leste | 01:31 |
| Wizzup | vectis: is it gtk2? | 01:36 |
| vectis | Yes, appears so (libgtk-x11-2.0.so.0) | 01:40 |
| Wizzup | so hildon input method should work mostly | 01:43 |
| vectis | Ermm, does this mean it doesn't in this case? | 01:47 |
| Wizzup | well, I haven't heard of any application doing caps | 01:49 |
| Wizzup | in this way | 01:50 |
| * Wizzup zz | 01:50 | |
| vectis | Perhaps I am not explaining it right. Every letter I type is upper case unless I hit "caps" first, but it doesn't stick (I have to do this every time) | 01:53 |
| vectis | Time for sleep here as well. Could you try evilvte yourself at sometime? | 01:54 |
| vectis | It's a small binary. | 01:55 |
| sicelo | i probably should scour the logs, but how to get the latest updates on d4? (new mesa, kernel, pvr, etc.) | 11:21 |
| sicelo | i'm on -devel and a simple apt upgrade didn't pull those in, afaict | 11:22 |
| Wizzup | it is in -experimental and we o not have a migration path yet | 11:51 |
| Wizzup | parazyd said he didn't know how to make it work with just update | 11:51 |
| Wizzup | I might try again today | 11:51 |
| Wizzup | sicelo: help appreciated btw | 11:58 |
| sicelo | mmm, it didn't quite work fully for me :-) | 12:55 |
| sicelo | in dmesg, grepping for 'ddk' returns nothing. iirc that should return something, | 12:55 |
| Wizzup | sicelo: what we want is to make sure 'apt upgrade' on -experimental just pulls in all the new stuff | 12:55 |
| Wizzup | but for example cloudgps depends on some sgx package quite directly | 12:55 |
| Wizzup | so we need 'provide' those | 12:56 |
| Wizzup | I suggested to parazyd to depend on *everything* we need in hildon-droid4-meta as a test | 12:56 |
| sicelo | interestingly, that's not installed on my d4 (hildon-droid4-meta). is it new? | 12:58 |
| Wizzup | maybe it's hildon-meta-droid4 | 13:04 |
| sicelo | yes, the package is hildon-meta-droid4, but it's not installed on my d4. also trying to install it now fails with | 13:07 |
| sicelo | The following packages have unmet dependencies: hildon-meta-droid4 : Depends: hildon-meta but it is not going to be installed | 13:07 |
| sicelo | but hildon-meta is installed. | 13:09 |
| Wizzup | sicelo: weird, I have it I think | 13:17 |
| Wizzup | let me debug a bit later today, I have another droid4 here | 13:17 |
| Wizzup | I will bring it up to date with -devel and then see if I can make it 'just upgrade' to -experimental stuff | 13:17 |
| freemangordon | Wizzup: if you have d4 with ddk 1.9 around, could you please enable video-omap debug and provide Xorg.log (after some scroll in h-d) | 13:19 |
| freemangordon | no hurry though | 13:19 |
| freemangordon | also, if possible, start h-d from shell with CLUTTER_SHOW_FPS=1 env var set, and provide max fps h-d scrolls with | 13:20 |
| sicelo | Wizzup: getting weirder, | 13:21 |
| sicelo | hildon-connectivity-wlan : Depends: libicd-network-wpasupplicant-dbus-n900 but it is not installable or | 13:21 |
| sicelo | libicd-network-wpasupplicant-dbus-common but it is not installable | 13:21 |
| Wizzup | freemangordon: can you provide specific instructions? | 13:24 |
| Wizzup | sicelo: this shouldn't happen after apt upgrade | 13:24 |
| Wizzup | sicelo: er apt update | 13:24 |
| sicelo | https://paste.debian.net/1221106/ | 13:27 |
| freemangordon | Wizzup: ok, but later on | 13:31 |
| Wizzup | sicelo: wait you're on experimental | 13:45 |
| Wizzup | sicelo: what if you remove that | 13:45 |
| Wizzup | brb | 13:45 |
| sicelo | https://paste.debian.net/1221108/ | 13:48 |
| sicelo | it's the same. | 13:48 |
| Wizzup | well that dependency shouldn't exist in any repo | 13:54 |
| Wizzup | I also solved it for crab a few days ago | 13:55 |
| sicelo | i guess it comes from https://github.com/maemo-leste/hildon-connectivity-meta/blob/master/debian/control#L18 | 13:58 |
| Wizzup | hmm | 13:58 |
| Wizzup | parazyd: ^^ ? | 13:58 |
| Wizzup | brb for real now | 13:58 |
| sicelo | quick one though ... when installing sgx-ddk-um-ti443x, apt threatens to remove everything qt seemingly, e.g. clock-ui | 14:03 |
| sicelo | pebkac, or it's a known issue? i think i read reports that qt stuff performed better with new mesa :-) | 14:04 |
| Wizzup | sicelo: again, the deps aren't sorted out, there is no easy upgrade path | 14:15 |
| Wizzup | my experimental d4 doesn't have the meta installed even | 14:15 |
| Wizzup | we need to sort that out still, so expect it to want to remove hildon-desktop even | 14:16 |
| Wizzup | I will try to look at it again today | 14:17 |
| sicelo | ah, i get you now | 14:21 |
| Wizzup | I don't have a one liner to upgrade either | 14:23 |
| Wizzup | I did a lot of dpkg --remove --force-all etc | 14:23 |
| Wizzup | freemangordon: let me know btw | 16:29 |
| freemangordon | Wizzup: you should set "Debug" to "On" in .conf file | 16:39 |
| freemangordon | Wizzup: also, to check h-d scroll fps: | 16:40 |
| freemangordon | disable lifeguard resets | 16:40 |
| freemangordon | from console, "dsmetool -k /usr/bin/hildon-desktop" | 16:40 |
| freemangordon | and then, as 'user': | 16:42 |
| freemangordon | CLUTTER_SHOW_FPS=1 maemo-summoner hildon-desktop.launch | 16:42 |
| freemangordon | oh, it is: | 16:42 |
| freemangordon | Option "Debug" "true" | 16:42 |
| Wizzup | ok | 16:43 |
| freemangordon | to disable resets: | 16:43 |
| freemangordon | 'touch /etc/no_lg_reboots' | 16:43 |
| freemangordon | this is not really needed, but just n case | 16:43 |
| freemangordon | if you have that, you can stop Xorg with no penalty :) | 16:44 |
| Wizzup | ok | 16:46 |
| Wizzup | btw | 16:46 |
| Wizzup | I got a crash in Xorg with 5.15, looks like it was because of a WARNING in kernel | 16:46 |
| freemangordon | on d4? | 16:47 |
| Wizzup | yes | 16:47 |
| Wizzup | kernel log: https://dpaste.com/A4FM5NZ7C | 16:47 |
| Wizzup | xorg log https://dpaste.com/2EZN6LR2E | 16:47 |
| Wizzup | it happened (I think) when I pressed the power key to unlock | 16:47 |
| freemangordon | hmm, weird | 16:48 |
| freemangordon | maybe some descriptor leak | 16:49 |
| Wizzup | could be yeah | 16:49 |
| freemangordon | ok, will have a look at it. these days :) | 16:49 |
| Wizzup | sure, just caught it is all | 16:50 |
| freemangordon | hmm, d4 doesn;t power off | 17:00 |
| freemangordon | while led stays lit | 17:00 |
| freemangordon | *white | 17:00 |
| Wizzup | yeah, we have some kernel things to solve | 17:10 |
| Wizzup | this happens I think because of an oops in uart | 17:11 |
| freemangordon | yeah, I am seeing that every time I reboot/poweroff from shell | 17:11 |
| Wizzup | yes, the same is present on n900 I think | 17:11 |
| Wizzup | there are also some issues with n900 kernel, but I'm also making some progress | 17:11 |
| Wizzup | the rest I reported upstream mostly (apart from wifi one) | 17:11 |
| Wizzup | my lab psu d4 currently reboots without no_lg, some upgrade... trying to figure that out first | 17:12 |
| Wizzup | then I'll check the hing you asked | 17:12 |
| freemangordon | ok, no hurry | 17:13 |
| Wizzup | it looks like some actdead script is being run | 17:14 |
| Wizzup | which contains sapwood with wrong path | 17:14 |
| Wizzup | oh: /etc/osso-af-init/sapwood-server.sh:PROG=/usr/lib/sapwood/sapwood-server | 17:31 |
| Wizzup | looks like parazyd removed that file in d0556aa0c1ad761ffc3c7ca2e007d7eb942301f0 | 17:33 |
| Wizzup | then why is it still on my system | 17:33 |
| Wizzup | what does this return for others? dpkg -S /etc/osso-af-init/sapwood-server.sh | 17:36 |
| Wizzup | parazyd: this is kinda messed up, any idea? | 17:36 |
| Wizzup | yeah so that stray file (/etc/osso-af-init/sapwood-server.sh) caused the problems | 18:19 |
| Wizzup | ok | 18:19 |
| Wizzup | both my dev n900 and dev d4 have dns problems still, and I thought we solved those by now, so that I'll also have to look at | 18:19 |
| Wizzup | uvos: btw, might be worth it to add rotation support to qt web browser in the form of telling h-d it accepts both | 18:22 |
| lel | MerlijnWajer opened an issue: https://github.com/maemo-leste/bugtracker/issues/588 (Create rsyslog maemo specific config/logging) | 18:27 |
| Wizzup | any opinions^ ? | 18:27 |
| _uvos_ | Wizzup: no | 18:57 |
| Wizzup | so what, the reset or the browser? | 18:58 |
| Wizzup | s/so what/to what/ | 18:58 |
| _uvos_ | browser | 18:58 |
| _uvos_ | its layout breaks bad if its h res is less than 640 | 18:59 |
| Wizzup | freemangordon: I don't think I have a xorg.conf file, let me check | 18:59 |
| Wizzup | _uvos_: ah, surprising | 18:59 |
| _uvos_ | really hildon should respect icccm h res and and aspect ratio limits via rotation but i degress | 19:00 |
| _uvos_ | (qtwebrowser sets both) | 19:00 |
| Wizzup | freemangordon: just horizontal desktop scrolling? | 19:02 |
| Wizzup | max fps I got was *** FPS: 53 *** | 19:03 |
| Wizzup | freemangordon: in portrait it is about *** FPS: 61 *** max | 19:04 |
| freemangordon | good | 19:04 |
| Wizzup | freemangordon: Xorg.0.log https://dpaste.com/2E3W2QPKH | 19:05 |
| freemangordon | I have to see why it is able to hit such high fps while 5.15 hitst up to 40 | 19:05 |
| Wizzup | wait that's not correct @ log | 19:05 |
| freemangordon | Wizzup: hmm please enable debug | 19:05 |
| Wizzup | I have, sec | 19:05 |
| freemangordon | yeah, llok in /tmpo | 19:05 |
| freemangordon | ttyl | 19:05 |
| Wizzup | I scp'd from thw wrong ip | 19:06 |
| Wizzup | lol | 19:06 |
| Wizzup | 44.100 is my droid, 44.101 is my other droid | 19:06 |
| Wizzup | freemangordon: https://wizzup.org/Xorg.0.log.gz | 19:07 |
| Wizzup | freemangordon: assuming you don't need more tests, I'll look at moving to experimental with a propre pkg | 19:11 |
| freemangordon | OMAPDRI2CreateBuffer:238 pDraw=0x618950, attachment=32769, format=34325258 | 19:20 |
| freemangordon | tripple-buffering that is ;) | 19:20 |
| Wizzup | freemangordon: from my log? | 19:21 |
| freemangordon | mhm | 19:21 |
| freemangordon | see 'attachment' | 19:21 |
| Wizzup | check | 19:21 |
| freemangordon | attachment=32769 | 19:21 |
| freemangordon | seems pvr blobs allocate third buffer | 19:21 |
| Wizzup | uvos: how do you think we best handle the lanes change here? https://github.com/maemo-leste/droid4-linux/commit/128570d6c51e1ff167095f32a577d515156c91c8 | 19:43 |
| Wizzup | and memory of course | 19:43 |
| Wizzup | I don't think it is right that the mapphone-common dtsi assumes the ram to be 1021MB | 19:44 |
| Wizzup | should I send a rfc patch to linux-omap perhaps? | 19:44 |
| uvos | Wizzup: you can just overwrite the nodes in your dts | 21:26 |
| uvos | for xt86x | 21:26 |
| uvos | but yeah we need to think more about how to struture this | 21:27 |
| uvos | lots of stuff needs to go for xt86x | 21:27 |
| uvos | touchscreen-buttons etc | 21:27 |
| Wizzup | uvos: ok, I'll start with that for my unified build | 21:27 |
| Wizzup | let me try that now in fact | 21:28 |
| uvos | gets even worse with mz6xx | 21:28 |
| Wizzup | yeah, I think it might not be super hard/annoying really, we just need to decide | 21:28 |
| uvos | memory node lacks a lable | 21:28 |
| uvos | btw | 21:28 |
| uvos | so you cant override | 21:28 |
| uvos | it | 21:28 |
| Wizzup | right, I think that's why I did it there | 21:30 |
| uvos | just add one | 21:30 |
| uvos | dsi allready has one so thats fine | 21:30 |
| Wizzup | uvos: so I do that by adding memory0: in front of it? | 21:31 |
| uvos | shoud work yeah | 21:32 |
| uvos | Wizzup: wrt the logs | 21:33 |
| uvos | Wizzup: that setup looks fine | 21:33 |
| uvos | Wizzup: but we need to rotate more often | 21:33 |
| Wizzup | yes, but the majority of log spam is (1) debug statements in connui-cellular and (2) ke-recv usb on mapphones | 21:33 |
| Wizzup | we just need to fix that | 21:33 |
| uvos | whats ke-recv logging? | 21:33 |
| Wizzup | usb bouncing | 21:34 |
| uvos | that often? | 21:34 |
| uvos | ok | 21:34 |
| uvos | what about ofonod.log? | 21:34 |
| Wizzup | sure, if it is fully charged it happens every few seconds | 21:34 |
| uvos | and h-s-m | 21:34 |
| Wizzup | ofonod.log is large because I run it with debug from /etc/init.d | 21:34 |
| uvos | both of those seam also pretty insane | 21:34 |
| uvos | ok | 21:35 |
| uvos | i gues one problem with h-s-m is that any plugin can cause it to log lots of glib-critical | 21:35 |
| Wizzup | sorry, what is h-s-m? | 21:36 |
| uvos | 61M Nov 28 16:31 hildon-status-menu.log | 21:36 |
| Wizzup | yeah | 21:36 |
| Wizzup | well, the point of splitting this out is precisely to find those problems | 21:36 |
| uvos | it might make sense to slowly port some of the plugins to StatusNotifierItems to make h-s-m more robust. any of the plugins thats just a button an icon and 2 lines of text (one white one blue) might as well be a StatusNotifierItem, that way it cant crash h-s-m or cause it to missbehave and the plugin in question can also be used in other enviornments than hildon | 21:38 |
| Wizzup | uvos: like this? https://github.com/maemo-leste/droid4-linux/commit/9d21cecab4a09df5de676b4dd9f144c1f056e043 | 21:38 |
| uvos | no | 21:39 |
| uvos | or yes that would work too | 21:39 |
| uvos | but why not just overide the endpoint? | 21:39 |
| Wizzup | ah | 21:42 |
| uvos | i havent been able to catch a reboot on uart btw | 21:43 |
| Wizzup | I fear there might be nothing | 21:43 |
| Wizzup | but I can try to catch it | 21:43 |
| uvos | i think its becasue having dmesg on uart blocks idle | 21:43 |
| Wizzup | uvos: so this? https://github.com/maemo-leste/droid4-linux/commit/546882f43b687d39bb5d4661304223be76969aa2 | 21:43 |
| uvos | so whatever is the problem dosent trigger | 21:43 |
| Wizzup | uvos: dmesg -w | 21:43 |
| uvos | Wizzup: yeah that might work | 21:43 |
| uvos | but the chance of geting the last lines is pretty low | 21:44 |
| uvos | that way | 21:44 |
| Wizzup | yes, we need a proper way to attach serial when idle.. | 21:44 |
| uvos | looks sane @dts | 21:44 |
| Wizzup | on status menu and notifiers, I haven't really looked at all yet, sorry | 21:48 |
| Wizzup | I will try to later, but my mind is on getting n900/d4/etc on same kernel and new 3d in place and packaged in -devel, and then this tp stuff | 21:49 |
| uvos | yeah no worrys | 21:49 |
| Wizzup | I was hoping to use the n900 modem because ofono is more stable there, but of course the nokia-modem has dma problems now :D | 21:49 |
| uvos | yeah | 21:50 |
| uvos | anyhow wrt the status-menu i just think having the status menu items in seperate proceies via the xdg interface makes more sense than having them as plugins in a single process from a robustness perspective | 21:51 |
| uvos | ofc this will use a bit more ram | 21:51 |
| uvos | so idk, depends on how mutch we want to hold onto the n900 in the long run. | 21:51 |
| Wizzup | probably true, we'll have to evaluate and depends on n900 ... yeah | 21:51 |
| * Wizzup mumbles something about prying the n900 from his cold dead hands :P | 21:52 | |
| uvos | :P | 21:52 |
| sicelo | what's the context of n900 relevance? ofono? status menu? | 21:54 |
| uvos | sicelo: using more ram in the name of robustness | 21:54 |
| uvos | sicelo: in this case making things like hildon-status-menu and -home use seperate processies | 21:54 |
| sicelo | ok | 21:55 |
| uvos | so that one application crashing dosent bring down the whole thing | 21:55 |
| uvos | s/application/plugin | 21:55 |
| Wizzup | uvos: I don't know if you see this but to me the d3 doesn't connect/disconnect as much when it is fully charged | 21:56 |
| Wizzup | maybe just a different (battery) limit or something, not sure | 21:57 |
| uvos | Wizzup: same with bionic | 21:57 |
| Wizzup | yeah | 21:57 |
| uvos | no idea why | 21:57 |
| uvos | the d4's rails are really noisy | 21:57 |
| uvos | that might affect the adc | 21:57 |
| uvos | the d4 is electricly just a bit marginal maybe | 21:57 |
| uvos | or its st vs on semi manufactured cpcap variants | 21:59 |
| uvos | maybe one of those works better | 21:59 |
| Wizzup | mhm | 22:00 |
| * Wizzup hoping this kernel will boot on his d3 | 22:00 | |
| Wizzup | of course it doesn't have the older ddk, so it won't boot to X probably, but hey :) | 22:00 |
| uvos | qrc:/qml/BrowserWindow.qml:34:1: module "QtQuick.Controls.Styles" is not installed | 22:25 |
| * uvos sigh | 22:25 | |
| Wizzup | hehe | 22:26 |
| uvos | on the brigt side qtwebrowser is reaaly nice on bionic | 22:29 |
| uvos | for some reason bionic still seams more fluid than d4 | 22:29 |
| uvos | probubly its dsi droping frames in d4 | 22:29 |
| Wizzup | [ 0.303497] cpuidle: using governor menu | 22:30 |
| Wizzup | [ 0.343139] No ATAGs? | 22:30 |
| Wizzup | [ 0.345520] hw-breakpoint: Failed to enable monitor mode on CPU 0. | 22:30 |
| Wizzup | :( | 22:30 |
| Wizzup | (droid3 not booting) | 22:30 |
| Wizzup | maybe the bootcfg is wrong, let me check... | 22:30 |
| Wizzup | no, looks correct, damn | 22:30 |
| uvos | hmm | 22:30 |
| uvos | maybe memory is special somehow | 22:30 |
| uvos | no wait | 22:30 |
| Wizzup | it got further now it seems | 22:31 |
| Wizzup | https://dpaste.com/D2B86P3EY | 22:32 |
| uvos | no that should be fine | 22:32 |
| uvos | hmm | 22:32 |
| uvos | Wizzup: pstore | 22:33 |
| uvos | did that work before on xt860? | 22:33 |
| Wizzup | oh, no, this should be disabled | 22:33 |
| Wizzup | did I forgot to do that, or did I disable it in config... | 22:33 |
| uvos | (tmlinds memory location for xt894 might be out of range) | 22:33 |
| uvos | ok | 22:33 |
| Wizzup | so how do I disable the ramoops, other than commenting it out? | 22:35 |
| Wizzup | alias and status = "disabled" or something? | 22:35 |
| uvos | you can delete nodes | 22:35 |
| uvos | from dts | 22:35 |
| Wizzup | really | 22:35 |
| uvos | yeah | 22:35 |
| uvos | i dont remember the syntax | 22:35 |
| Wizzup | I don't suppose you know how to :D | 22:35 |
| uvos | google it | 22:35 |
| Wizzup | mhm | 22:36 |
| uvos | ofc really you should figure out what ram region mbm preserves for ramoops on xt86x | 22:37 |
| Wizzup | first I think I want it to boot on 5.15 :)_ | 22:39 |
| Wizzup | ok, it boots | 22:45 |
| Wizzup | did find something interesting | 22:45 |
| Wizzup | https://dpaste.com/8NWBGVL2D | 22:45 |
| uvos | Wizzup: thats normal | 22:46 |
| Wizzup | oh | 22:46 |
| uvos | well not _normal_ | 22:46 |
| uvos | but its not unexpected | 22:46 |
| Wizzup | I thought maybe it is why it resets randomly | 22:46 |
| uvos | sre just took whatever the values on d4 where as the maximum voltages | 22:46 |
| uvos | the older sillicon needs higher voltages | 22:46 |
| Wizzup | anyway, so ramoops is to be figured out then I can maybe send a rfc patch | 22:46 |
| uvos | i had to move lots of maximums up for bionic too | 22:47 |
| uvos | but it dosent matter in reality | 22:47 |
| uvos | because mbm sets those | 22:47 |
| uvos | and the kernel dosent touch them | 22:47 |
| Wizzup | ok | 22:47 |
| uvos | it just gets confused because its not what it expects | 22:47 |
| Wizzup | so how did you figure out what the pstore range is for bionic? | 22:47 |
| Wizzup | I guess the answer is that it's the same as the d4? ;) | 22:47 |
| uvos | yes it is :) | 22:47 |
| Wizzup | so how do you think I can figure it out? | 22:48 |
| uvos | the andorid kernel uses this region too | 22:48 |
| uvos | so its in there | 22:48 |
| uvos | but idk where exactly tmlind found the current value | 22:48 |
| Wizzup | there is a comment on it in the dts | 22:48 |
| Wizzup | (the current one) | 22:48 |
| uvos | ok | 22:48 |
| Wizzup | but I still haven't been able to really decipher the old dts | 22:48 |
| Wizzup | hexreader or not | 22:48 |
| uvos | so its in dts? | 22:48 |
| uvos | ok | 22:48 |
| Wizzup | from the file: | 22:49 |
| Wizzup | The stock kernel has 2M@0xa0000000 for ram_console using the | 22:49 |
| Wizzup | old file format. That won't work for us, so let's ignore the | 22:49 |
| Wizzup | first 512K of that and just overwrite the rest and configure | 22:49 |
| Wizzup | only 384K instead of 2M. | 22:49 |
| uvos | let me look at xt894 stock dts sec | 22:49 |
| Wizzup | do you have dts or dtb? | 22:49 |
| uvos | you know whats really annoying | 22:49 |
| uvos | the damn low battery sond | 22:49 |
| Wizzup | I was not able to find dts, only dtb for droid 3 | 22:49 |
| Wizzup | in maemo? :D | 22:49 |
| uvos | i have the n900 runing in freemantle somewhere | 22:50 |
| uvos | and its low | 22:50 |
| Wizzup | hehe | 22:50 |
| uvos | and i cant find it | 22:50 |
| Wizzup | it's a sad sound too, right | 22:50 |
| uvos | yeah | 22:50 |
| uvos | can i have xt860 stock dts? | 22:51 |
| Wizzup | I don't have it | 22:51 |
| Wizzup | I only have a dtb, that's the problem | 22:51 |
| uvos | i mean dtb | 22:51 |
| Wizzup | and tony lost his tool to convert them | 22:51 |
| uvos | sry | 22:51 |
| Wizzup | (the patches) | 22:51 |
| Wizzup | ok | 22:51 |
| uvos | yeah i know | 22:51 |
| Wizzup | give me a moment to surface it | 22:51 |
| Wizzup | uvos: this _should_ be it https://wizzup.org/stock-dts.bin | 22:53 |
| uvos | thanks | 22:53 |
| Wizzup | (it says xt862) | 22:53 |
| uvos | but i cant find where its defined in xt894 stock dts either | 22:53 |
| uvos | so not sure what the comment is refering to | 22:54 |
| uvos | see http://uvos.xyz/maserati/stockinfo/dts/ | 22:54 |
| Wizzup | maybe android boot log has it somehow (probably not) | 22:54 |
| Wizzup | brb 10mins or so | 22:54 |
| uvos | http://uvos.xyz/maserati/stockinfo/dmesg/xt894.txt | 22:54 |
| uvos | thats xt894 stock dmesg | 22:54 |
| uvos | [ 1.871124,0] ram_console: got buffer at a0000000, size 200000 | 22:55 |
| uvos | yeah indeed | 22:55 |
| Wizzup | ok, I'll boot android in a bit | 22:55 |
| uvos | http://uvos.xyz/maserati/stockinfo/dmesg/xt862.txt | 22:55 |
| Wizzup | btw /delete-node/ ramoops0; | 22:55 |
| uvos | no need | 22:55 |
| Wizzup | + alias for ramoops shouldhelp | 22:55 |
| Wizzup | I will try that in a bit, and -then- try the pstore patch, but brb first | 22:55 |
| Wizzup | (stack of events :-) ) | 22:55 |
| uvos | xt862 dmesg | 22:56 |
| Wizzup | a there is no ram_console in there? | 22:56 |
| uvos | dosnet have ram_console | 22:56 |
| uvos | :( | 22:56 |
| Wizzup | well then I'll test my delete thing first | 22:56 |
| uvos | maybe old mbm lacks this feature? | 22:56 |
| Wizzup | brb for real | 22:56 |
| uvos | that would suck | 22:56 |
| Wizzup | doesn't look like the /delete-node/ works | 23:11 |
| uvos | hmm | 23:11 |
| Wizzup | - ramoops@a0080000 { | 23:11 |
| Wizzup | + ramoops0: ramoops@a0080000 { | 23:11 |
| Wizzup | and then in \ I have: | 23:12 |
| Wizzup | + /delete-node/ ramoops0; | 23:12 |
| Wizzup | maybe it needs & | 23:12 |
| * Wizzup tries | 23:12 | |
| Wizzup | nope it doesn't like that | 23:12 |
| uvos | maybe the fulls string? | 23:13 |
| Wizzup | it works with & outside of \ { | 23:13 |
| Wizzup | let me try that | 23:13 |
| uvos | by grepping in the kernel tree i think /delete-node/ &ramoops0; | 23:14 |
| uvos | is correct | 23:14 |
| Wizzup | we'll find out momentarily | 23:14 |
| Wizzup | yes, that's it | 23:15 |
| uvos | great | 23:15 |
| Wizzup | https://github.com/maemo-leste/droid4-linux/commits/wip/n900/maemo-5.15 | 23:16 |
| Wizzup | I'll add some comments to it in a bit | 23:17 |
| Wizzup | but at least now this can be integrated in the tree | 23:17 |
| uvos | compatible = "motorola,droid-bionic", "ti,omap4430", "ti,omap4"; | 23:17 |
| uvos | dont like this | 23:17 |
| Wizzup | yes, needs to be fixed | 23:17 |
| Wizzup | but that requires changes in kernel src | 23:17 |
| uvos | please add the other compatabil in cpcap src | 23:17 |
| uvos | so? | 23:17 |
| Wizzup | no, I will :) | 23:18 |
| Wizzup | it was just inconvenient when I was testing just the dts | 23:18 |
| uvos | ok ok | 23:18 |
| Wizzup | I'll do it now | 23:18 |
| uvos | also what about ts-buttons | 23:19 |
| uvos | you need to delete the node | 23:19 |
| uvos | or figure out what the correct values are for the button placement | 23:19 |
| Wizzup | yes, that does need to happen, maybe deleting is better until other things are in place | 23:19 |
| Wizzup | I think I just disabled it in udev for now | 23:20 |
| uvos | for figureing out what the values are: its just the ones in evtest | 23:20 |
| Wizzup | right now there's still the problems with backlight and keyboard leds that I need to figure out (the i2c stuff) | 23:20 |
| uvos | ie for d4/bionic i just clicked what the top of the button should be in my opionon | 23:20 |
| Wizzup | I understand | 23:21 |
| uvos | and then in x direction its just seperated into 4 equal quads | 23:21 |
| uvos | ok :) | 23:21 |
| uvos | /* Side buttons, KEY_VOLUMEDOWN and KEY_PWER are on CPCAP? */ | 23:22 |
| uvos | also fix this comment please | 23:22 |
| Wizzup | uvos: fix how? I'd need to check what I meant... | 23:31 |
| uvos | KEY_VOLUMEDOWN | 23:32 |
| uvos | is not on cpcap | 23:32 |
| uvos | on xt86x | 23:32 |
| uvos | also the question mark can go | 23:32 |
| uvos | or add the camera button and add the question mark again :P | 23:32 |
| Wizzup | lol | 23:33 |
| Wizzup | it looks like they are on keypad yes | 23:33 |
| Wizzup | uvos: honestly I think the ts buttons might just be fine | 23:48 |
| uvos | great | 23:53 |
| Wizzup | (they work as expected) | 23:54 |
| uvos | great | 23:54 |
| Wizzup | https://github.com/maemo-leste/droid4-linux/commits/wip/n900/maemo-5.15 | 23:54 |
| uvos | the mapphone touchscreens are really consistant | 23:54 |
| Wizzup | btw, I can see modem in dmesg | 23:55 |
| Wizzup | (I still have n_gsm debug on) | 23:55 |
| uvos | looks fine @dts | 23:55 |
| Wizzup | so clearly it's mostly just working | 23:55 |
| uvos | yeah just a gipo move proubly | 23:55 |
| uvos | *gpio | 23:55 |
| uvos | *moved | 23:55 |
| Wizzup | not sure if relevant, just saw this: | 23:55 |
| Wizzup | [Sun Nov 28 23:53:23 2021] pwrdm state mismatch(l4per_pwrdm) 3 != 1 | 23:55 |
| uvos | *probably | 23:55 |
| uvos | i should think then write :P | 23:55 |
| Wizzup | I have the same problem | 23:56 |
| uvos | yeah we have that on every device @l4per_pwrdm | 23:56 |
| uvos | even on non mapphone omaps | 23:56 |
| uvos | according to tmlind | 23:57 |
| uvos | so no idea on that one | 23:57 |
| Wizzup | ok | 23:58 |
| Wizzup | also interesting: | 23:58 |
| Wizzup | [ 2481.369293] phy-mapphone-mdm6600 usb-phy@1: modem status: 5 asleep | 23:58 |
| Wizzup | [ 2510.909301] phy-mapphone-mdm6600 usb-phy@1: modem status: 5 asleep | 23:58 |
| Wizzup | [ 2599.519256] phy-mapphone-mdm6600 usb-phy@1: modem status: 4 awake | 23:58 |
| Wizzup | [ 2599.589294] phy-mapphone-mdm6600 usb-phy@1: modem status: 5 asleep | 23:58 |
| uvos | dose qmictl work on that modem? | 23:59 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!