Wizzup | bencoh: ok I need thiscp -v /usr/bin/qemu-arm /var/cache/lxc/devuan/partial-beowulf-armhf/usr/bin/ | 00:41 |
---|---|---|
bencoh | Wizzup: tbh I'm still amazed it works here without qemu in the lxc rootfs | 00:51 |
bencoh | back in the days (when I did it manually with chroots) I had to copy it there | 00:51 |
bencoh | sorry I didn't mention it | 00:52 |
bencoh | (it really works without it here on debian though) | 00:52 |
Wizzup | surprising | 00:56 |
bencoh | find /var/lib/lxc/maemo-leste-armhf/rootfs -iname "*qemu-arm*" returns nothing | 00:58 |
bencoh | and it definitely works | 00:58 |
bencoh | I guess gentoo does it slightly differently | 00:58 |
Wizzup | yeah could be binfmt reg | 01:03 |
Wizzup | where does | 01:10 |
Wizzup | this come from: /wrapper/amd64-divert.sh | 01:10 |
freemangordon | on n900, glmark2 Score: 24, using 3d blit | 10:07 |
freemangordon | will try with 2d blit, to see if there will be any difference | 10:07 |
Wizzup | freemangordon: from the targetfs, which device do we want | 10:35 |
Wizzup | ti443x ? | 10:35 |
Wizzup | or do you want to different ones for the n900? | 10:35 |
Wizzup | e.g. ti343x | 10:36 |
freemangordon | yes, we want different ones per device | 10:37 |
freemangordon | d4 - 443x | 10:37 |
freemangordon | n900 - 343x | 10:37 |
Wizzup | ok | 10:44 |
Wizzup | so there's headers, shared objects, ahd maybe pvrsrvinit (although you said we don't need it) | 10:45 |
freemangordon | we don;t need the headers from there | 10:45 |
freemangordon | only libs | 10:46 |
Wizzup | https://github.com/maemo-leste/pvr-omap4/blob/master/debian/control#L119 do you think we need this split? | 10:46 |
freemangordon | headers are mesa headers | 10:46 |
freemangordon | no, everything comes from mesa | 10:46 |
freemangordon | besides blobs and SGX specific headers | 10:46 |
Wizzup | or shall we just make it sgx-ddk-1.17-443x-libs | 10:46 |
freemangordon | yes | 10:46 |
Wizzup | ok | 10:47 |
freemangordon | we need only the blobs from that repo | 10:47 |
Wizzup | ok, but - | 10:47 |
Wizzup | please let me know which blobs we don't want | 10:47 |
freemangordon | IOW: | 10:47 |
freemangordon | we want only those with 1.17.xxxxxx in the name | 10:48 |
Wizzup | ok, so we don't want libEGL | 10:48 |
freemangordon | no | 10:48 |
Wizzup | and no libgdm | 10:48 |
freemangordon | comes from mesa ;) | 10:48 |
Wizzup | ok, that's clear | 10:48 |
Wizzup | ty | 10:48 |
Wizzup | isually libGLES_CM also comes from mesa :p | 10:48 |
Wizzup | oh actually that does also come from mesa here | 10:48 |
Wizzup | juts libGLES_v1_PVR_MESA does not | 10:48 |
freemangordon | yes | 10:48 |
Wizzup | ok, so I will make -dev have the stuff in targetfs/ti443x/include and targetfs/ti443x/lib/pkgconfig | 10:49 |
Wizzup | do you want the drirc.d packaged anywhere? I guess nit part of this | 10:49 |
Wizzup | s/nit/not/ | 10:49 |
freemangordon | no | 10:49 |
Wizzup | ok | 10:49 |
Wizzup | easy | 10:49 |
freemangordon | re -dev: | 10:49 |
Wizzup | I'll start with this | 10:49 |
lel | MerlijnWajer created a repository: https://github.com/maemo-leste/sdx-ddk-um | 10:49 |
freemangordon | we don't want anything from here, besides libpvr2d.so, for example | 10:49 |
Wizzup | I don't undenrstand what you mean, there is no pkg-config or specific header for it there | 10:50 |
Wizzup | oh, right, the gl/khr headers also come from mesa | 10:50 |
freemangordon | yes, you shall create one (pkg-config) | 10:50 |
freemangordon | but, headers in -dev package (an maybe libs) are those I pushed yesterday in omap-vide | 10:51 |
lel | MerlijnWajer renamed a repository: https://github.com/maemo-leste/sgx-ddk-um | 10:51 |
freemangordon | and they are not device specific | 10:51 |
Wizzup | freemangordon: those are shared for device? | 10:51 |
Wizzup | ok | 10:51 |
freemangordon | yes | 10:51 |
Wizzup | well let me get blobs packaged first | 10:52 |
Wizzup | then I will worry about libpvr2d and -dev and headers from omap ddx | 10:52 |
freemangordon | ok, but do not include .so files, besides libpvr_dri_support.so | 10:52 |
freemangordon | hmm, hmm | 10:53 |
freemangordon | scratch that | 10:53 |
Wizzup | I don't understand - you don't want the symlinks? | 10:53 |
Wizzup | ok | 10:53 |
freemangordon | I think .so symlinks belong to -dev package | 10:53 |
freemangordon | not .so.1, but .so only | 10:53 |
freemangordon | but I am not sure what links to what | 10:53 |
Wizzup | $ ls -lsh targetfs/ti443x/lib/libglslcompiler.so | 10:54 |
Wizzup | 4.0K lrwxrwxrwx 1 merlijn merlijn 31 Nov 14 10:37 targetfs/ti443x/lib/libglslcompiler.so -> libglslcompiler.so.1.17.4948957 | 10:54 |
Wizzup | $ ls -lsh targetfs/ti443x/lib/libglslcompiler.so.1 | 10:54 |
Wizzup | 4.0K lrwxrwxrwx 1 merlijn merlijn 31 Nov 14 10:37 targetfs/ti443x/lib/libglslcompiler.so.1 -> libglslcompiler.so.1.17.4948957 | 10:54 |
freemangordon | and for sure we need libpvr_dri_support.so in binary package | 10:54 |
freemangordon | links are clear | 10:54 |
Wizzup | > 10:54 < freemangordon> and for sure we need libpvr_dri_support.so in binary package | 10:54 |
freemangordon | yes, because pvr_dri dload()'s it | 10:55 |
Wizzup | I was going to include it anyway per your instructions to include *.so*1.17* | 10:55 |
Wizzup | oh right | 10:55 |
Wizzup | I see now, symlink wise | 10:55 |
freemangordon | mhm | 10:55 |
Wizzup | shall I just do all then | 10:55 |
Wizzup | I think it makes more sense than special casing | 10:55 |
freemangordon | yes, better do | 10:55 |
Wizzup | ok | 10:55 |
freemangordon | yeah | 10:55 |
freemangordon | also, make sure that every binary package you build provides sgx-ddk-um and sgx-ddk-um-1.17.4948957 (for example) | 10:57 |
freemangordon | so that -dev package deps to sgx-ddk-um-1.17.4948957 and (maybe) omap-video deps to sgx-ddk-um to be satisfied nop matter the device package installed | 10:58 |
Wizzup | ok, I'll try | 11:03 |
Wizzup | both src/pvr/hwdefs/ and src/pvr/include4/ - do you want them in /usr/include/sgx/ or something? | 11:05 |
freemangordon | hmm, seems 2d blit is faster | 11:14 |
freemangordon | Wizzup: not sure, see how is kernel tree | 11:14 |
freemangordon | we better follow it | 11:15 |
Wizzup | kernel tree? | 11:15 |
freemangordon | TBH, this -dev package shall come from the kernel build | 11:15 |
freemangordon | yes, headers kome from PVR kernel driver | 11:15 |
freemangordon | *come | 11:16 |
freemangordon | sec | 11:16 |
freemangordon | Wizzup: https://github.com/tmlind/linux_openpvrsgx/tree/droid4-pending-pvr-omapdrm-v5.15/drivers/gpu/drm/pvrsgx/1.17.4948957/eurasia_km/include4 | 11:19 |
freemangordon | not sure if all kernel headers shall be packaged | 11:19 |
freemangordon | but we already have something similar, so maybe check how it is packaged there | 11:19 |
freemangordon | have to run, ttyl | 11:19 |
Wizzup | ok, pvr-omap4 doesn't have these headers at least (our old droid4 ddk pkg) | 11:20 |
freemangordon | we have some pvr ddx | 11:21 |
freemangordon | for omap3? | 11:21 |
freemangordon | not ddx, but blobs | 11:21 |
freemangordon | for omap3 I think there is a package with headers | 11:21 |
freemangordon | ttyl | 11:22 |
freemangordon | but again, I think -dev shall come from kernel build | 11:22 |
bencoh | Wizzup: I included a copy of the -divert scripts at the end of that notes file | 11:23 |
Wizzup | ah.. | 11:28 |
Wizzup | # cat /wrapper/amd64-divert.sh | 11:29 |
Wizzup | cat: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory | 11:29 |
Wizzup | looks like it's propertly hosed now | 11:30 |
Wizzup | heh | 11:30 |
bencoh | hm | 11:30 |
bencoh | you should setup the lib folders first though :] | 11:30 |
Wizzup | if you mean the amd64 symlinks, I did that already | 11:31 |
Wizzup | the dash divert did something to my lib paths it looks like | 11:31 |
bencoh | hmm ... if you want you can probably try that version http://bencoh.notk.org/maemo/maemo-leste-armhf-lxc-crossbuilder.tar.xz | 11:32 |
bencoh | it's slightly old and probably misses a few optimizations | 11:32 |
bencoh | (ie a few diverts) | 11:32 |
bencoh | well, diverting dash means dash is now amd64 | 11:33 |
Wizzup | maybe I just need to restart the shell | 11:33 |
Wizzup | # lxc-attach maemo-leste-armhf | 11:33 |
Wizzup | /bin/bash: error while loading shared libraries: libtinfo.so.6: cannot open shared object file: No such file or directory | 11:33 |
bencoh | yeah, something's missing then | 11:33 |
bencoh | I remember having that error back when I started | 11:33 |
bencoh | you know what, maybe I should try building one from scratch again | 11:34 |
Wizzup | would appreciate i t | 11:35 |
Wizzup | I was going to use it to try the mesa packaging mostly, but I'll do the pvr ddk stuff first | 11:36 |
bencoh | duh, my laptop (host) is running debian, and looks like upgrading to stable messed with the devuan keys again ... that's sill | 11:37 |
* dreamer running updates | 11:38 | |
dreamer | heuhm. the d4 just decided to reboot .. | 11:44 |
Wizzup | if you haven't upgraded in a long time, that's an old issue that's hopefully solved | 11:44 |
bencoh | hmm, I'll have to update the devuan repositories btw | 11:45 |
dreamer | month or two at most | 11:45 |
dreamer | hmm | 11:48 |
dreamer | The following packages have been kept back: hildon-meta | 11:48 |
dreamer | have we moved to chimaera yet? | 11:48 |
Wizzup | dreamer: try dist-upgrade wrt meta | 11:49 |
Wizzup | wrt chimaera no, that's a while out I think | 11:49 |
dreamer | yes, thnx | 11:49 |
dreamer | yeah just checking | 11:49 |
dreamer | do I need to restart hildon now? | 11:50 |
Wizzup | I don't think so if it was just the meta | 11:51 |
Wizzup | but you could I guess | 11:51 |
dreamer | is there an idea how to fix the annoying charge notification *woosh*? it randomly keeps doing that :# | 11:52 |
dreamer | I'm on silent profile | 11:53 |
Wizzup | on silent profile it should not make that noise, and no, if it is fully charged it will feel switching between discharging and charging atm | 11:54 |
Wizzup | s/feel/keep/ | 11:54 |
dreamer | I hear all desktop sounds/notifications | 11:54 |
Wizzup | maybe a reboot is in order them, uvos changed the gconf keys for those | 11:54 |
Wizzup | s/them/then/ more coffee | 11:55 |
dreamer | hmm. ok :) | 11:55 |
dreamer | still wooshing and notifying | 12:06 |
dreamer | I guess I'll just mute the audio then | 12:06 |
Wizzup | weird, I don't have this problem on mine | 12:08 |
Wizzup | maybe it's a -devel thing (not sure) | 12:08 |
dreamer | are there any recommended build flags for the d4? | 12:27 |
Wizzup | dreamer: for what in particular | 12:32 |
dreamer | I want to build gl4es :) | 12:32 |
dreamer | it uses cmake | 12:32 |
Wizzup | https://github.com/maemo-leste-upstream-forks/gl4es | 12:32 |
Wizzup | is it not in -extras ? | 12:32 |
dreamer | oh hey, indeed it is | 12:32 |
dreamer | Version: 1.1.4-1+2m7.4 | 12:33 |
dreamer | didn't expect that somehow. thnx parazyd ;) | 12:33 |
dreamer | (saw he packaged it hehe) | 12:33 |
Wizzup | yeah we worked on it a long time ago | 12:34 |
Wizzup | still, maybe check debian/rules and see if it uses the right flags/defines | 12:34 |
Wizzup | iirc gl4es can be quite device specific | 12:35 |
dreamer | yeah it has all kinds of tweaks | 12:35 |
dreamer | but some things you can overload with envvars | 12:35 |
Wizzup | looks like we're quite a bit behind on upstream too | 12:42 |
dreamer | yeah, although on latest release | 13:00 |
dreamer | loading it in LD_LIBRARY_PATH seems to work though :) | 13:00 |
dreamer | hard to test (using pd+Gem) if it works properly though | 13:00 |
dreamer | is there an easy way to fullscreen applications? ie `alt+f11` on typical xorg | 13:08 |
Wizzup | https://github.com/maemo-leste/leste-config/pull/15/files#diff-e01d3125cf1b7163e8ed35e1fce06e7ff2620d9b1e2b508b02b8039a0f38fead doesn't look like there is fullscreen | 13:10 |
dreamer | ah, libgl is automatically overloaded already. well the testpatch I got from buZz is super smooth :) | 13:11 |
buZz | dreamer: alt+f11 isnt xorg specific, just something common in different window managers | 13:13 |
dreamer | ja ok | 13:13 |
dreamer | but it's "typical" shortcut | 13:14 |
buZz | hmhm | 13:14 |
dreamer | something like it for hildon would be nice | 13:14 |
dreamer | <shift><ctrl>f maybe? | 13:14 |
dreamer | and lol @ `hildon-dekstop` | 13:28 |
buZz | hmm, does hildon-connectivity-wlan now depend on libicd-network-wpasupplicant-dbus-n900 ? | 14:06 |
Wizzup | might depend on the device? | 14:06 |
buZz | maybe .. | 14:07 |
buZz | seems i have a flaky install now | 14:07 |
Wizzup | d4? | 14:07 |
buZz | 'sudo reboot' seems to not reboot my d4 , or at least take a very long time to do so | 14:07 |
Wizzup | are you on -devel? | 14:07 |
buZz | yeah, and just installed a bunch of updates from apt | 14:08 |
freemangordon | n900, glmark2 Score: 28 :D | 14:08 |
freemangordon | and, this is with close-to-zero CPU load | 14:08 |
buZz | nice :) | 14:08 |
freemangordon | -drm is 37 | 14:09 |
buZz | ah, after a long time it -does- reboot | 14:10 |
buZz | wonder if its just some watchdog triggering :P | 14:10 |
Wizzup | freemangordon: amazing | 14:11 |
Wizzup | buZz: watchdog kicks in quickly | 14:11 |
Wizzup | buZz: I have the same problem on devel kernel, there is some oops perhaps | 14:11 |
Wizzup | I wouldn't bother with it right now since we will go to 5.15 momentarily | 14:12 |
dreamer | indeed `hildon-connectivity-wlan` seems to be upgradable but won't | 14:18 |
bencoh | Wizzup: well, got the same issue | 15:23 |
bencoh | I guess I forgot something there ... | 15:23 |
bencoh | (diverting dash breaks everything) | 15:24 |
Wizzup | right | 15:26 |
Wizzup | thanks for looking into it | 15:26 |
bencoh | I wonder if I patched the loader as well and forgot about it | 15:26 |
bencoh | Wizzup: ln -s /amd64/usr/lib/x86_64-linux-gnu /usr/lib/ | 15:28 |
bencoh | looks like this is enough | 15:28 |
bencoh | hmm, yeah, I had that link in my previous container as well | 15:28 |
bencoh | my bad :( | 15:28 |
bencoh | I updated http://muarf.org/~bencoh/maemo/leste/leste-lxc-crossbuilder/ accordingly | 15:31 |
Wizzup | ok, I'll retry in a bit again | 15:31 |
Wizzup | thanks | 15:31 |
tmlind | freemangordon: so do you want me to apply omap3 prm patch and your posted omapdrm and sgx patches into droid4-pending-pvr-omapdrm-v5.15? | 16:51 |
freemangordon | yes | 16:52 |
tmlind | ok | 16:52 |
freemangordon | thanks | 16:53 |
freemangordon | it seems omapdrm will need more patches, for example it refuses to export dma (not cma) allocated memory | 16:53 |
freemangordon | IOW-if a buffer is not contiguous or tiled, omapdrm will not export it | 16:54 |
freemangordon | I don't see the reason for that, it will be perfectly valid do construct scatterlist and provide it to the importer | 16:54 |
freemangordon | if importer can handle non-contiguous memory is out of scope of omapdrm, no? | 16:56 |
tmlind | yeah i guess | 16:57 |
tmlind | so two sgx fixes and one omapdrm fix for now? | 16:57 |
freemangordon | yeah | 16:57 |
freemangordon | and I am yet to touch VRFB :D | 16:58 |
freemangordon | tmlind: I think I found a way to allocate TILER buffers through GBM | 16:58 |
tmlind | ok, will apply, then we can update again later based on comments etc | 16:58 |
tmlind | oh cool | 16:58 |
freemangordon | it will need omapdrm patch ofc | 16:58 |
freemangordon | gbm has 3 flags to set a BO format: | 16:59 |
freemangordon | GBM_BO_USE_LINEAR, GBM_BO_USE_RENDERING and GBM_BO_USE_SCANOUT | 17:00 |
freemangordon | so, my idea is - if GBM_BO_USE_LINEAR is not provided, allocate TILER buffer | 17:00 |
freemangordon | desription of this flag is : "Buffer is linear, i.e. not tiled." | 17:01 |
freemangordon | so, if it is not set, allocate tiled buffer | 17:01 |
freemangordon | does that make sense to you? | 17:01 |
freemangordon | or on the opposite | 17:02 |
tmlind | yeah ok, not that i know much about it at all, but sounds like at least worth trying that :) | 17:32 |
bencoh | freemangordon: in your opnion who is supposed to set the LINEAR flag then? | 17:35 |
tmlind | freemangordon: pushed out updated droid4-pending-pvr-omapdrm-v5.15 to github with stable v5.15.2 merged in | 18:05 |
uvos | dreamer: system sounds should be slient on the silent profile | 18:12 |
uvos | (and works for me) | 18:12 |
uvos | also i did not change anything about this, they where always part of the profile and not related to gconf | 18:12 |
uvos | if it dosent work, please changing the volume of the sounds in settings->profile->general | 18:13 |
uvos | maybe your silent profile is broken some how | 18:13 |
uvos | please share your profile.ini if this works but silent dose not | 18:14 |
uvos | Wizzup: dont forget to binary patch the blobs for old libc | 18:14 |
dsc_ | uvos: Re: QML performance; you previously said something like "opengl copies the whole buffer each time" <-- is this a software/driver issue or just how QML works, thus it will never perform well on older hardware? | 18:14 |
uvos | driver issue | 18:15 |
dsc_ | gotcha | 18:15 |
uvos | but not sure if qml will ever be fast on n900 | 18:15 |
uvos | its pretty resource intensive either way | 18:15 |
uvos | maybe try it | 18:15 |
bencoh | qt4/qml on n900 (fremantle) wasn't exactly fast, but it was bearable for most apps | 18:16 |
uvos | yeah but he is writing the conversations ui | 18:16 |
bencoh | (except that it kept the device awake way more that it should) | 18:16 |
uvos | this will probubly allways be in ram | 18:16 |
uvos | so not sure if its a good idea | 18:16 |
uvos | needs profileing first | 18:16 |
bencoh | in that case, I'd rather not use qml, yeah | 18:17 |
dsc_ | QtWidgets would be most performant but am time limited atm | 18:17 |
bencoh | (unless for stuff limited to UI only) | 18:17 |
uvos | rather than dissmissing it out of hand i think checking it out make sense | 18:17 |
uvos | performance wise | 18:17 |
uvos | qt5 should be a bit better than 4 | 18:17 |
uvos | if the qt company is to be belived | 18:18 |
uvos | perf wise | 18:18 |
dsc_ | yeah some QML performance changes between the minor versions too | 18:18 |
dsc_ | we're on 5.11 | 18:18 |
dsc_ | thats somewhat recent | 18:18 |
dsc_ | anyway, for now this is just a MVP | 18:18 |
bencoh | well, if they fixed the idling (or lack of) issues, then it might be worth a try yeah | 18:18 |
bencoh | (and/or if it doesn't impact our usecase) | 18:19 |
uvos | yeah def check for if it idles well | 18:19 |
uvos | if not thats k.o. | 18:19 |
dsc_ | ill keep business logic on the C++ side so switching out the renderer is not a huge undertaking :P | 18:21 |
bencoh | :) | 18:22 |
bencoh | if you really follow MVP I guess one could always replace the QML parts with 'native' qt bit by bit once it works anyway, assuming we feel the need to | 18:23 |
dsc_ | MVC you mean? Yeah something like that. Not going to claim I am an expert in C++/Qt, more of an UI person, but yeah switching to QtWidgets wont be as painful | 18:24 |
dsc_ | ive been on projects where most business logic is in QML | 18:25 |
dsc_ | so you can never drop it for something else unless you rewrite everything | 18:25 |
bencoh | yeah I've seen such apps | 18:25 |
dreamer | uvos: hmm. I'll have to try that indeed | 18:49 |
dreamer | uvos: made a new profile with all sounds turned off -> still hear the woosh | 18:51 |
dreamer | no wait, it keeps switching back to General | 18:52 |
dreamer | yeah ok, if I turn everything off in General profile it's silent | 18:53 |
dreamer | the problem is that it doesn't save the profile change. it just resets back to General | 18:53 |
uvos | how are you changing profiles? | 18:54 |
dreamer | `Settings > Profiles` | 18:55 |
dreamer | select one. done? | 18:55 |
uvos | dreamer: that dosent change prfiles | 18:55 |
uvos | your just selecting one to edit | 18:55 |
dreamer | then how? | 18:55 |
uvos | click the battery item | 18:56 |
uvos | *icon | 18:56 |
uvos | in the status bar | 18:56 |
uvos | and change it in hildon-status-menu | 18:56 |
dreamer | oh derp | 18:56 |
uvos | or open the power menu | 18:56 |
dreamer | I haven't been on maemo for too long -_- | 18:56 |
uvos | and click silent there | 18:56 |
uvos | profilesx is a bit wierd yeha | 18:56 |
uvos | but thats works as intended | 18:56 |
dreamer | yeah, sorry | 18:56 |
dreamer | what is "power menu"? | 18:57 |
dreamer | bbl, food | 18:57 |
uvos | the one where you switch off the deive | 18:57 |
uvos | *device | 18:57 |
uvos | also has a "silent" that changes the profile | 18:57 |
dreamer | ah yes | 18:57 |
dreamer | ok, check. gotta re-learn old habbits (or rather: I set my maemo profile once ~decade ago and never changed it. I hate all forms of notification sounds and vibrations) | 18:58 |
sicelo | or you can do it via dbus if you don't mind the long string (setting silent ... unless things work differently now) | 19:00 |
sicelo | dbus-send --type=method_call --dest=com.nokia.profiled /com/nokia/profiled com.nokia.profiled.set_profile string:"silent" | 19:03 |
uvos | that should also work yeah | 19:07 |
sicelo | freemangordon: there's a Lucas Fryzek in the openpvrsgx ml. i wonder if he also would have some insight for anything you still need :-) | 20:21 |
Wizzup | uvos: freemangordon says we do not need bin patching with mesa | 20:24 |
uvos | parazyd: Wizzup: in what pacakge are the maemo icons? | 20:24 |
uvos | im particularly looking for the sms/phone icon | 20:25 |
Wizzup | themes? | 20:25 |
uvos | to use with sphone outside of maemo | 20:25 |
uvos | oh ok | 20:25 |
Wizzup | try dpkg -S filepath | 20:25 |
uvos | i dont know the filepath either :P | 20:25 |
uvos | Wizzup: are you sure i had to patch some for use with chromeos mesa | 20:25 |
Wizzup | he told me irl just now | 20:27 |
uvos | ok | 20:27 |
Wizzup | we'll see I guess | 20:27 |
uvos | wierd | 20:27 |
uvos | https://github.com/IMbackK/pvr-omap4 these are the exact blobs i use, you can diff arm-linux-gnueabihf-untainted and arm-linux-gnueabihf to see what i had to patch | 20:27 |
uvos | there are deff. some glibc symbol version tags in there that are newer than ours | 20:28 |
uvos | so no idea how that should work | 20:28 |
Wizzup | do you use the zeus ranch? | 20:39 |
Wizzup | branch* | 20:39 |
uvos | its ti-img-sgx/zeus/1.17.494857 @ 551665bf9c321bc3e7721416e6ebbc9f65c18155 | 20:42 |
uvos | *ti-img-sgx/zeus/1.17.4948957 | 20:42 |
uvos | actually those 2 branches share a head | 20:43 |
Wizzup | we use a different one I think | 20:49 |
Wizzup | fmg does at least | 20:49 |
uvos | ok | 20:49 |
uvos | that explains it | 20:49 |
Wizzup | fmg told me to use 1.17.4948957-next | 20:49 |
uvos | that dident exist last time i fetched | 20:49 |
uvos | looks like | 20:49 |
uvos | we asked someone to rebuild agains older glibc some time ago | 20:50 |
uvos | maybe they finaly did :P | 20:50 |
Wizzup | hehe | 20:51 |
freemangordon | no, they didn;t | 21:04 |
freemangordon | it is just that blobs that depend on newer glibc are replaced by the ones we have in MESA | 21:04 |
Wizzup | right | 21:06 |
freemangordon | Wizzup: oh, there *is* this: https://github.com/maemo-leste/pvr-omap4/blob/master/usr/lib/xorg/modules/drivers/omap_pvr_drv.so | 21:07 |
freemangordon | that's why it is so fast ;) | 21:07 |
uvos | freemangordon: except thats not true objdump -T libglslcompiler.so.1.17.4948957 | 21:08 |
uvos | GLIBC_2.29 pow | 21:08 |
uvos | this is for 551665bf9c321bc3e7721416e6ebbc9f65c18155 | 21:08 |
freemangordon | hmm, is it? | 21:08 |
uvos | ofc -next might differ | 21:08 |
freemangordon | I doubt | 21:08 |
freemangordon | well, my bad then | 21:09 |
freemangordon | btu at least we shall not LD_PRELOAD anythibng | 21:09 |
uvos | yeah | 21:09 |
freemangordon | *anything | 21:09 |
uvos | because pvr_dri is fine | 21:09 |
freemangordon | mhm | 21:09 |
freemangordon | so, omap_pvr_drv.so is what I am now REing into 1.17 | 21:19 |
uvos | sgx accell plugin for -video-omap? | 21:19 |
freemangordon | yes, this is what d4 uses with ddk 1.9 | 21:19 |
uvos | wel no | 21:19 |
freemangordon | wel,, yes | 21:19 |
uvos | because its compiled against old xorg api | 21:19 |
Wizzup | freemangordon: ah | 21:20 |
uvos | hmm it dosent load | 21:20 |
freemangordon | no, this is not pvr_drv.so | 21:20 |
freemangordon | ah | 21:20 |
Wizzup | freemangordon: ./usr/lib/debug/usr/lib/xorg/modules/drivers/omap_pvr_drv.so | 21:20 |
freemangordon | well, no idea then | 21:20 |
freemangordon | Wizzup: yes, I know | 21:20 |
Wizzup | ok | 21:20 |
freemangordon | uvos: may I see Xorg.log from d4 with ddk 1.9? | 21:21 |
uvos | yes ofc | 21:21 |
freemangordon | oh, maybe you are right | 21:21 |
freemangordon | well, I have no idea then | 21:21 |
uvos | http://uvos.xyz/maserati/xorg.log | 21:22 |
uvos | so what dose omap_pvr_drv.so contain that we need? | 21:22 |
uvos | /want | 21:23 |
freemangordon | Failed to load module "omap_pvr" (module does not exist, 0) | 21:23 |
uvos | yeah | 21:23 |
freemangordon | how does it rotate then? | 21:23 |
uvos | tiler | 21:23 |
uvos | that part works for sure | 21:23 |
uvos | you can see it in debugfs | 21:23 |
freemangordon | not with 1.17 | 21:23 |
uvos | sure | 21:23 |
uvos | i mean in ddk1.9 | 21:23 |
freemangordon | why? | 21:23 |
uvos | why what? | 21:23 |
uvos | why dose it work | 21:23 |
uvos | no idea :D | 21:23 |
freemangordon | yes, why does it work and why it doen;t with 1.17 | 21:24 |
uvos | i dont know | 21:24 |
freemangordon | are you sure we don;t have some omapdrm pacthes with 1.9 kernel? | 21:24 |
uvos | maybe it uses one of the ioctls omapdrm ioctls shiped with the sgx kernel driver removed in ddk1.14 | 21:24 |
uvos | sure the ddk1.9 has omapdrm patches | 21:25 |
freemangordon | hmm | 21:25 |
freemangordon | which tree is that? | 21:25 |
uvos | so tmlind allways claims (this is why he wanted to drop this version for new kernels, since omapdrm changed lots over time) | 21:25 |
uvos | sec | 21:25 |
uvos | https://github.com/tmlind/linux_openpvrsgx/tree/droid4-pending-pvr-omapdrm-v5.10 | 21:26 |
uvos | i gues you should diff the drm driver folder | 21:26 |
freemangordon | this is for ddk 1.17 | 21:26 |
uvos | no | 21:27 |
uvos | v5.10 also still has ddk1.9 | 21:27 |
uvos | and ddk1.17 too | 21:27 |
freemangordon | we have the same patches in 5.15 | 21:27 |
uvos | https://github.com/tmlind/linux_openpvrsgx/tree/droid4-pending-pvr-omapdrm-v5.10/drivers/gpu/drm/pvrsgx/1.9.2253347 | 21:27 |
freemangordon | uvos: so, this^^^ is the tree on d4? | 21:27 |
uvos | yes | 21:27 |
uvos | well no we patch it more | 21:28 |
freemangordon | hmmm | 21:28 |
uvos | but this is where we get the ddk1.9 from | 21:28 |
freemangordon | but no omapdrm patches, right? | 21:28 |
uvos | we dont patch any gpu/ stuff after this | 21:28 |
uvos | no | 21:28 |
freemangordon | yeah | 21:28 |
freemangordon | weird | 21:28 |
freemangordon | ok | 21:28 |
uvos | tmlind: ^^^^^ | 21:35 |
uvos | he should know | 21:35 |
uvos | github search is really fustratingly bad | 21:46 |
uvos | like you can copy a string from the file your looking at into the search and have it search "this repository" and it wont find the string | 21:47 |
uvos | like how can you even manage to fail this badly | 21:47 |
Wizzup | yeah | 21:51 |
tmlind | hmm so what part of the old ddk-1.9 hacks are you guys missing? hopefully none.. | 21:56 |
freemangordon | tmlind: no idea, but somehow rotation works without my TILER fixes | 21:57 |
tmlind | heh | 21:57 |
uvos | really some detail on what these hacks entail might help | 21:58 |
freemangordon | mhm | 21:58 |
tmlind | well should we revert some of the hacks then? | 21:58 |
uvos | tmlind: some pointers as to what commits contain these hacks i think is in order | 21:59 |
freemangordon | tmlind: how to know, without knowing what those hacks are :) | 22:00 |
tmlind | heh right :) | 22:00 |
freemangordon | building 5.15.2 ATM | 22:00 |
tmlind | well we could add a comment saying "acceleration with rotation works mysteriously" :) | 22:01 |
freemangordon | tmlind: it is not about acceleration | 22:01 |
tmlind | ah right just tiler rotation? | 22:02 |
freemangordon | mhm | 22:02 |
tmlind | could it be the sgx code just masks in the rotation bit to the address to change it? | 22:02 |
freemangordon | why sgx? | 22:03 |
freemangordon | it has nothing to do | 22:03 |
freemangordon | plain 2d stuff | 22:03 |
tmlind | ah ok | 22:03 |
freemangordon | oh, wait | 22:04 |
freemangordon | actually it works | 22:04 |
freemangordon | plain 2d that is | 22:04 |
freemangordon | hmm | 22:04 |
uvos | maybe on ddk1.9 tiler usage goes through sgx driver | 22:05 |
freemangordon | no | 22:05 |
uvos | look at services4/srvkm/env/linux/mm.c | 22:05 |
freemangordon | what there | 22:05 |
uvos | make two separate allocations via the tiler omap_ion_tiler_alloc | 22:05 |
freemangordon | no ion here | 22:05 |
uvos | ok | 22:05 |
freemangordon | this is android thing | 22:05 |
uvos | ok | 22:06 |
uvos | no idea what is #if defined(CONFIG_ION_OMAP) :P | 22:06 |
freemangordon | "ION is a generalized memory manager that Google introduced in the Android 4.0 ICS " | 22:06 |
freemangordon | something like CMA, IIUC | 22:07 |
uvos | ok | 22:07 |
uvos | there are also some ifdefs that react to CONFIG_TI_TILER | 22:09 |
uvos | not sure what they contain | 22:09 |
uvos | looks like translateing tiler addresses | 22:09 |
tmlind | omap_framebuffer_update_scanout() is not what you are trying to find is it? | 22:09 |
jk_0 | hello! newbie here ^^ ehm... how can I connect to my wlan over command line | 22:11 |
uvos | hi | 22:12 |
uvos | why? is something wrong with the gui? using wpa_cli works, but i think there is a dbus interface you can use too | 22:12 |
uvos | Wizzup: should know about the dbus interface ^^^^ | 22:12 |
Wizzup | https://wiki.maemo.org/Phone_control#Connect_to_specific_saved_connection | 22:13 |
jk_0 | uvos: ehm, yes, I can't get into hildon after trying to apt full-upgrade | 22:14 |
uvos | oh thats bad | 22:14 |
uvos | what device | 22:14 |
jk_0 | :) | 22:14 |
jk_0 | droid4 | 22:14 |
uvos | and what where you upgrading to | 22:14 |
uvos | devel or regular | 22:14 |
jk_0 | regular | 22:14 |
uvos | ok | 22:14 |
uvos | so what happens exactly? | 22:14 |
jk_0 | everything seemed normal | 22:15 |
jk_0 | but at some point while eiher installing unpacking or setting up I had a black screen and a white led | 22:16 |
uvos | how old was your install | 22:16 |
jk_0 | very :) 2020 | 22:16 |
jk_0 | may? | 22:16 |
uvos | ok this is a known issue i think | 22:16 |
uvos | we had this problem where a deamon failed and caused dsme to reboot the device during an upgrade | 22:17 |
uvos | you need to finish the upgrade | 22:17 |
jk_0 | alright | 22:17 |
Wizzup | can you log in over ssh with usbnet? | 22:17 |
Wizzup | https://leste.maemo.org/Status/USB_Peripheral | 22:17 |
uvos | jk_0: if you have the new emergency shell boot mode | 22:17 |
jk_0 | I have the amazing rescue shell :) | 22:18 |
uvos | that should work too | 22:18 |
uvos | great | 22:18 |
tmlind | nice if that works :) | 22:18 |
Wizzup | cool | 22:18 |
uvos | tmlind: works even on bionic :) | 22:18 |
jk_0 | yes, I'm all ears. what do I do next? | 22:18 |
uvos | Wizzup: remember how to make dpkg finish configuring pacakges | 22:18 |
uvos | ? | 22:18 |
tmlind | dpkg-reconfigure -a maybe? | 22:19 |
Wizzup | yes | 22:19 |
jk_0 | let me try... | 22:19 |
jk_0 | nope | 22:19 |
uvos | Unknown option: a | 22:20 |
uvos | yeah thats not it | 22:20 |
jk_0 | I did a successfull $ dpkg --configure -a before connecting here | 22:20 |
Wizzup | no errors? | 22:20 |
jk_0 | whith reconfigure I got the help-info | 22:21 |
Wizzup | what does 'apt upgrade' say | 22:21 |
jk_0 | with --configure -a I saw no errors. 80% secure cuz I only scaned stout | 22:21 |
jk_0 | then I rebooted and "boot loop" persists | 22:22 |
jk_0 | wizzup: donde,done 0 installed, 0 upgraded, 0 to remove, 0 not upgraded | 22:23 |
Wizzup | so it reboots when exactly? | 22:23 |
jk_0 | it does the normal loadig of ... hat I think is openrc | 22:24 |
jk_0 | then it goes balck and I suppose it tries to load hildon | 22:24 |
uvos | dose it reboot with or without white led? | 22:25 |
jk_0 | but goes back to console and shows some erros | 22:25 |
jk_0 | the white led was only the 1st time. the boot-loop is w/o led | 22:26 |
uvos | thats quite wierd | 22:26 |
uvos | either its happening before mce loads or its not the maemo stack innitaing the reboot | 22:26 |
jk_0 | let me see what I can type here from the console before reboot | 22:27 |
uvos | you could look at /var/log/daemon.log for errors too | 22:27 |
jk_0 | rebooting... | 22:28 |
jk_0 | ... how can I share an image here? | 22:32 |
uvos | only by uploading it somewhere public and posting the link | 22:33 |
jk_0 | what is the analog to paste.bin? | 22:33 |
Wizzup | maybe imgur? | 22:35 |
jk_0 | i'll have a look | 22:38 |
jk_0 | https://pasteboard.co/sB8JV58OpjBc.jpg | 22:40 |
jk_0 | https://pasteboard.co/3hoNm68LGsSE.jpg | 22:41 |
jk_0 | I hope these work | 22:41 |
uvos | nothing to see tehre | 22:42 |
Wizzup | hm, do you have more info up? | 22:42 |
Wizzup | the error is up | 22:42 |
Wizzup | daemon.log might be more interesting | 22:42 |
Wizzup | or perhaps rc.log | 22:42 |
jk_0 | so /var/log/rc.log?? | 22:43 |
Wizzup | if that contains useful stuff yes :) | 22:43 |
Wizzup | also if it reboots you can touch a specific file thatmakes it no reboot, then you can use the tty there | 22:44 |
Wizzup | from 'non emergency env | 22:44 |
jk_0 | ... sorry for the links full of advertising... | 22:44 |
jk_0 | ehm... I dont get the no reboot part. but I am comfotable in the console :) | 22:45 |
uvos | touch /etc/no_lg_reboots | 22:46 |
jk_0 | just,could I connect to mlan fromthe console? | 22:46 |
uvos | sure start wpa_supplicant | 22:46 |
uvos | and use wpa_cli | 22:46 |
uvos | the dbus stuff wont work | 22:46 |
uvos | in emergency env icd2 is not loaded | 22:46 |
Wizzup | I'd try usbnet | 22:46 |
Wizzup | that's much easier | 22:46 |
uvos | i would touch /etc/no_lg_reboots in emergency env | 22:47 |
uvos | then openrc default | 22:47 |
uvos | to switch runlevel | 22:47 |
jk_0 | is that $ touch /etc/no_lg_reboots with underscores? | 22:48 |
uvos | and then usbnet should work | 22:48 |
uvos | yeah like i wrote | 22:48 |
uvos | oh its echo 1 > /etc/no_lg_reboots | 22:48 |
Wizzup | you might need to load the gadget but we have bins to do that | 22:48 |
Wizzup | uvos: just touch is fine | 22:48 |
uvos | it needs the 1 in there i think | 22:48 |
uvos | ok | 22:48 |
jk_0 | my irc client earases the _ | 22:49 |
jk_0 | hexchat... | 22:49 |
uvos | we should make /etc/no_lg_reboots the default (yes again this) | 22:50 |
uvos | lifeguard is just painful | 22:50 |
jk_0 | so, echo 1 or no echo? | 22:50 |
uvos | dosent matter | 22:50 |
uvos | either is fine | 22:51 |
Wizzup | I think just touch is fine. | 22:51 |
Wizzup | but yeah | 22:51 |
jk_0 | ok | 22:51 |
jk_0 | rebooting... | 22:52 |
uvos | switching runlevel would have been fine | 22:52 |
jk_0 | ok. how do I switch run level? | 22:52 |
jk_0 | I was too slow to reboot | 22:53 |
uvos | openrc $(RUNLEVEL) | 22:53 |
uvos | default in this case | 22:53 |
jk_0 | read your message 1st | 22:53 |
jk_0 | ok. in progress | 22:54 |
Wizzup | when you get any kind of ssh access please share some part of daemon.log | 22:54 |
jk_0 | loading hildon... | 22:54 |
jk_0 | hildon has loaded! :D | 22:54 |
uvos | some deamon is still failing | 22:55 |
Wizzup | yeah, 'rc-status' might help | 22:55 |
Wizzup | although it could be part of startup too | 22:55 |
uvos | pstree | 22:55 |
uvos | maybe | 22:55 |
Wizzup | maybe wifi works | 22:55 |
uvos | or just look at deamon log | 22:55 |
Wizzup | let's see | 22:55 |
jk_0 | ehm... what do I do now to give you useful info? | 22:56 |
uvos | [22:54] <Wizzup> when you get any kind of ssh access please share some part of daemon.log | 22:56 |
jk_0 | ... system froze -__- | 22:57 |
Wizzup | wonder what happened | 22:57 |
uvos | it froze? | 22:57 |
uvos | thats unusual | 22:57 |
Wizzup | yeah that is | 22:57 |
Wizzup | maybe you can read the sdcard and share daemon.log | 22:58 |
Wizzup | or the last ~500 lines or so | 22:58 |
Wizzup | then we can probably help efficiently | 22:58 |
* Wizzup back in 10-15 mins | 22:58 | |
jk_0 | ok... well, this is way more than I expected from an # apt update && apt full-upgrade -y | 23:00 |
jk_0 | ^^ | 23:00 |
jk_0 | the full system is back and seems functional | 23:04 |
Wizzup | jk_0: interesting, just touching the file seems like it made it work for you - stiull something must be wrong | 23:23 |
Wizzup | maybe you can share ps xua or pstree so that we can see what is not running | 23:23 |
Wizzup | we'd probably want to know what's up so we can prevent it from happening to others | 23:23 |
Wizzup | and yeah, we're in >alpha< so occasionally things break :) | 23:24 |
Wizzup | have you been using it since 2020? that's nice | 23:24 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!