| Wizzup | uvos: droid4 uses xserver-xorg-video-omap, n900 uses xserver-xorg-video-pvrsgx | 00:03 |
|---|---|---|
| Wizzup | so mm_width in output_info is also 0 | 00:06 |
| Wizzup | https://github.com/maemo-leste/n9xx-xf86-video-fbdev-sgx/blob/master/src/output.c#L791 | 00:07 |
| Wizzup | uvos: correction n900 uses xf86-video-pvrsgx | 00:15 |
| Wizzup | (repo) | 00:15 |
| Wizzup | but to be clear that is *not* n9xx-xf86-video-fbdev-sgx | 00:17 |
| lel | MerlijnWajer opened an issue: https://github.com/maemo-leste/bugtracker/issues/578 (N900: screen rotation segfaults in sgx_exa_update_pixmap) | 00:26 |
| Wizzup | I think xf86-video-pvrsgx might not be building with debug symbols | 00:27 |
| Wizzup | yu[ | 00:28 |
| Wizzup | we need to fix that | 00:28 |
| Wizzup | rebuild with debug symbols | 00:50 |
| Wizzup | ok so the qPixmap is a null pointer in sgx_exa_update_pixmap | 01:01 |
| Wizzup | maybe PVR2D_PostFBReset should not be calling that on zeroed pixmaps | 01:01 |
| Wizzup | yeah so the pixmaps are deleted pvr2d_flip_put_bufs and never re-allocated it looks like (on rotation) | 01:07 |
| Wizzup | I think I'm getting closer to the problems on the n900 wrt rotation | 02:22 |
| Wizzup | but it's bed time now :) | 02:22 |
| sicelo | Wizzup: that would be awesome. i see your ticket! | 08:12 |
| Wizzup | we'll see, I'm not super deep into this X stuff | 10:57 |
| Wizzup | heh: | 11:28 |
| Wizzup | /* SGX has a 2048x2048 maximum texture size limit */ | 11:28 |
| Wizzup | /* FIXME should be limited further based on the amount of vram */ | 11:28 |
| Wizzup | xf86CrtcSetSizeRange(pScrn, 1, 1, 2048, 2048); | 11:28 |
| Wizzup | might make sense to do that I think | 11:29 |
| uvos | Wizzup: hmm? | 12:22 |
| Wizzup | uvos: remind me? | 13:07 |
| uvos | "might make sense to do that I think" | 13:09 |
| Wizzup | the crtc seems too large for n900 but that is not the bug | 13:09 |
| uvos | xf86CrtcSetSizeRange | 13:10 |
| Wizzup | I decided to dive a bit into the rotate crash and why it crashes is obvious | 13:10 |
| uvos | even modern fat desktop gpus have that | 13:10 |
| Wizzup | the solution less so | 13:10 |
| uvos | with a 16k maximum | 13:10 |
| uvos | as thats the texture size limit on amd gcn for instance | 13:10 |
| Wizzup | mhm, it might not be relevant | 13:10 |
| uvos | its not | 13:11 |
| uvos | but anyhow geting rotation to work would be neat | 13:11 |
| Wizzup | uvos: unrelated, do you see ts buttons wake up device when it is locked | 13:11 |
| uvos | Wizzup: no | 13:12 |
| uvos | and they should not | 13:12 |
| Wizzup | hm, now I do not see it | 13:12 |
| Wizzup | weird, might be me | 13:12 |
| uvos | im not sure fixing video-pvrsgx makes sense | 13:12 |
| uvos | vs fixing -modesetting on ddk1.17 | 13:12 |
| Wizzup | it might be a relatively simple fix and sphone won't cause resets anymore ;) | 13:13 |
| uvos | sure | 13:13 |
| Wizzup | unless you want to hold back hildon-desktop xinput changes until 1.17 | 13:13 |
| Wizzup | since it also breaks ts | 13:13 |
| uvos | no but a sanity check would be ok | 13:14 |
| uvos | i just would avoid spending to muich time on it | 13:14 |
| Wizzup | agreed | 13:14 |
| Wizzup | I might have some questions a bit later wrt X | 13:14 |
| uvos | btw we cant move to ddk1.17 wihtout either fixing chromeos mesa pvr | 13:15 |
| uvos | or moveng to a debian 11 | 13:15 |
| uvos | base | 13:15 |
| uvos | so gconf blocks here too a bit | 13:15 |
| uvos | becasue mesa cant dlopen the pvr_dri plugin (because its compile agains later libc) | 13:17 |
| uvos | so even with weakend symbol versions you have to preload pvr_dri | 13:17 |
| uvos | but having it preloaded for everything (since how would you know what uses libgles when setting the envvar) | 13:18 |
| uvos | causes lots of funn issues | 13:18 |
| uvos | wrt symbol resolition in random binarys | 13:18 |
| uvos | and also stuff like cp sometimes segfaulting | 13:18 |
| uvos | this getting rid of gconf is pretty important | 13:19 |
| uvos | (or fixing foss pvr mesa pick your poison) | 13:19 |
| sicelo | how would a debian 11 base help? | 13:19 |
| uvos | it has newer libc | 13:19 |
| uvos | so mesa can dlopen binary pvr_dri.so | 13:20 |
| sicelo | ok | 13:20 |
| uvos | Chimaera i gues | 13:22 |
| uvos | i just mentiond debain 11 becaus idk how devuan versions line up | 13:22 |
| uvos | obv. it would be something devuan based. | 13:22 |
| Wizzup | another reason to first fix this ddx probably | 13:29 |
| Wizzup | root@devuan-n900:/sys/devices/platform/omapdss/display0# ls|grep rotate | 15:16 |
| Wizzup | rotate | 15:16 |
| Wizzup | root@devuan-n900:/sys/devices/platform/omapdss/display0# file rotate | 15:16 |
| Wizzup | rotate: ERROR: cannot read `rotate' (No such file or directory) | 15:16 |
| Wizzup | ugh | 15:16 |
| uvos | wtf is it doing | 15:17 |
| uvos | it should be using the drm interface | 15:17 |
| Wizzup | n900 is not omapdrmfb | 15:18 |
| Wizzup | with the powervr driver | 15:18 |
| Wizzup | I think the pvr kernel driver we use doesn't support it? | 15:18 |
| Wizzup | (not sure about that) | 15:18 |
| uvos | its runing on the old fb video interface? | 15:18 |
| uvos | ugh | 15:18 |
| Wizzup | yes | 15:18 |
| uvos | ok | 15:18 |
| Wizzup | so this seems to be the problem: https://github.com/maemo-leste/bugtracker/issues/578#issuecomment-938634862 | 15:18 |
| Wizzup | so the problem could be that the rotate just fails, which then makes that not work, but I need to check that | 15:19 |
| uvos | so ddk1.9 never was available for omap3? | 15:20 |
| uvos | at least its not this crusty | 15:20 |
| Wizzup | I don't think so | 15:23 |
| Wizzup | we could check, but no point in trying to go back | 15:23 |
| Wizzup | r = dss2_read_int(dss2_fb, idx, "mirror", &mirror); | 15:24 |
| Wizzup | if (r && errno != ENOENT) | 15:24 |
| Wizzup | goto error; | 15:24 |
| Wizzup | can_mirror = !r; | 15:24 |
| Wizzup | lol | 15:24 |
| Wizzup | uvos: I wonder if the zero width and height come from the other fb devices | 15:40 |
| Wizzup | https://wizzup.org/Xorg-rotate-fail.log | 15:54 |
| Wizzup | most of that logic seems to be in crtc_set_mode_major | 15:56 |
| Wizzup | maybe the problem is that the overlay rotate is 0 when it should not be? | 16:03 |
| Wizzup | yeah ovl_rotate is OMAP_ROTATE_0 when it should be OMAP_ROTATE_90 ? | 16:11 |
| Wizzup | none of this makes any sense | 16:20 |
| Wizzup | for example this call: | 16:23 |
| Wizzup | [ 882.456] fbdev_crtc_config_resize(0x5ab518, 480, 800) | 16:23 |
| Wizzup | why would it have this effect: | 16:23 |
| Wizzup | [ 882.485] overlay_update: putting fb_var_screeninfo xres 480 yres 480 | 16:23 |
| Wizzup | and for this call: | 16:23 |
| Wizzup | [ 882.501] crtc_set_mode_major(crtc=0x5ac358, mode=0xbeb69068, rotation=8, x=0, y=0) | 16:23 |
| Wizzup | [ 882.501] mode = 800x480 | 16:23 |
| Wizzup | I can imagine that maybe mode 800x480 with rotation=8 (RR_Rotate_270) means that the mode is actually 480x800 | 16:24 |
| Wizzup | but then a simple switch statement to set the omap mode to OMAP_ROTATE_90 just returns OMAP_ROTATE_0 | 16:24 |
| Wizzup | which I think is why the ovl does not fit | 16:24 |
| Wizzup | which makes the enable write fail | 16:24 |
| uvos | well in x screen mode scann mode and screen size are different things | 16:25 |
| uvos | 800x480 with rotation=8 makes perfect sense if the 800x480 is the scann mode | 16:25 |
| uvos | no idea how rotation works in the fbdev interface kernel side | 16:27 |
| uvos | the kernel itself dosent change any buffers when you rotate the console on fbdev | 16:27 |
| uvos | it just renders stuff sideways | 16:27 |
| uvos | in drm mode it changes how the frambuffer is scanned out to really rotate it | 16:27 |
| freemangordon | Wizzup: maybe ask tomi for help | 16:28 |
| freemangordon | this looks like a bug in omapfb | 16:29 |
| freemangordon | also, IIRC rotation was working on Pali's tree | 16:29 |
| Wizzup | yes, but this is one that spinal forked | 16:29 |
| Wizzup | I really don't know what/which version is newest/latest, etc | 16:29 |
| freemangordon | he forked which tree? Pali's? | 16:30 |
| Wizzup | I don't know | 16:30 |
| freemangordon | :) | 16:30 |
| Wizzup | this is it https://github.com/maemo-leste/xf86-video-pvrsgx/ | 16:30 |
| freemangordon | Wizzup: I mean - what kernel? | 16:30 |
| Wizzup | looks like it's a fork from some fbdev omap fork https://github.com/maemo-leste/xf86-video-pvrsgx/commit/219c3da7796ec82634cb459d24e4747065ed22a9 | 16:31 |
| Wizzup | freemangordon: 5.1 | 16:31 |
| freemangordon | mhm | 16:31 |
| freemangordon | oh, I see, we don;t have armhf meego binaries | 16:32 |
| Wizzup | yes | 16:32 |
| freemangordon | Wizzup: the ^^6 logs are from dmesg, right? | 16:33 |
| uvos | its X | 16:34 |
| Wizzup | the Xorg.log I pasted is from Xorg with pvrdrv with all debug on | 16:34 |
| Wizzup | the few lines in the github issue are from kernel | 16:34 |
| Wizzup | https://github.com/maemo-leste/bugtracker/issues/578#issuecomment-938634862 | 16:34 |
| freemangordon | ok | 16:35 |
| freemangordon | and, what happens if you try to rotate through sysfs? | 16:35 |
| Wizzup | with X on? | 16:36 |
| freemangordon | mhm | 16:36 |
| Wizzup | will try in a bit | 16:36 |
| Wizzup | I assume you mean the fb0/rotate file | 16:36 |
| freemangordon | right | 16:37 |
| Wizzup | will try, but everything with n900 takes time | 16:37 |
| freemangordon | :) | 16:37 |
| Wizzup | lots of time | 16:37 |
| freemangordon | hmm: | 16:40 |
| freemangordon | https://github.com/maemo-leste/xf86-video-pvrsgx/commit/04273d50383c035652b76e43886b5571ec09feb4 | 16:40 |
| freemangordon | https://github.com/maemo-leste/xf86-video-pvrsgx/commit/49ec10cb645b3d4ab368d959c9abf813534fd300 | 16:40 |
| freemangordon | unrelated, but still | 16:40 |
| freemangordon | Wizzup: hmm, rotate 270 is rotate 0 + mirror | 16:42 |
| freemangordon | isn;t it? | 16:42 |
| Wizzup | oh I see | 16:44 |
| Wizzup | so maybe it works with blit and flip was just always broken | 16:44 |
| Wizzup | those are kind of conflicting commits | 16:44 |
| freemangordon | no, wait, rotate 270 is not rotate 0 + mirror | 16:44 |
| freemangordon | yes, my point | 16:44 |
| Wizzup | it should just be rotate yes | 16:45 |
| Wizzup | in any case it looks like (still trying to figure it out) that the enable write fails (see kernel msg) because ovl_rotate = 0 | 16:46 |
| Wizzup | and it should not be 0 | 16:46 |
| Wizzup | there is other weirdness going on, but that seems to be the main reason | 16:46 |
| freemangordon | ok | 16:46 |
| Wizzup | apart from the segfault I fixed earlier | 16:46 |
| freemangordon | do you need any help with that? | 16:46 |
| Wizzup | (where they do not free the pixmap, and just null the pixmap pointers, and then try to access the pixmap pointers) | 16:46 |
| Wizzup | maybe you can read through my thoughts on the issue and comment here | 16:47 |
| Wizzup | in particular | 16:47 |
| Wizzup | https://github.com/maemo-leste/bugtracker/issues/578#issuecomment-938225337 | 16:47 |
| Wizzup | the suggested fix is not perfect, since it still needs to destroy the pixmaps before they get nulled, but that's an easy fix later on | 16:47 |
| Wizzup | and yes I would appreciate help if you have spare cycles | 16:47 |
| Wizzup | but if it's too much of a timesink I suggest we drop it and focus on new pvr stuff later | 16:48 |
| freemangordon | but, is it possible that because of those contradicting commits, half of the code tries to blit, the other half to flip? | 16:48 |
| Wizzup | yes, we can try to synchronise that first | 16:49 |
| freemangordon | mhm | 16:49 |
| Wizzup | first I need to fix my driver because I forgot a break; in a switch where it had default: assert(0) :p | 16:49 |
| freemangordon | :) | 16:50 |
| freemangordon | re new ddk - is there any change since I last tried | 16:50 |
| freemangordon | on 5.10 it was just freezing the device | 16:50 |
| Wizzup | probably nobody tried since | 16:50 |
| freemangordon | :( | 16:50 |
| Wizzup | I wasn't going to look at the old driver at all except that the new hildon-desktop rotation code breaks all touch on n900 | 16:51 |
| freemangordon | maybe I can try latest, if anybody points me to the latest | 16:51 |
| Wizzup | because it reports some size of (0, 0) and maps all touch input to 0, 0 | 16:51 |
| Wizzup | freemangordon: I'd ask uvos or tmlind | 16:51 |
| freemangordon | uvos: any clue which one is the latest pvr? | 16:52 |
| uvos | wdym? | 16:52 |
| freemangordon | what repo/branch | 16:53 |
| uvos | 5.11 (but realistcly you should use 5.10 because its lts) is the last version to support ddk 1.9 and 1.14 | 16:53 |
| freemangordon | 1.17 is what I mean | 16:53 |
| freemangordon | I want to build for n900 and see if it works | 16:53 |
| freemangordon | lat time I tried it was not | 16:53 |
| uvos | there is 5.15 rc | 16:53 |
| freemangordon | where? | 16:53 |
| uvos | https://github.com/tmlind/linux_openpvrsgx.git | 16:54 |
| uvos | the usual place | 16:54 |
| freemangordon | thanks | 16:54 |
| uvos | im pretty sure sicelo or someone tried 5.13 on n900 with ddk1.17 | 16:55 |
| uvos | and it worked | 16:55 |
| freemangordon | that would be great | 16:55 |
| freemangordon | going to try 5.15-rc | 16:56 |
| uvos | maybe he can comment | 16:56 |
| Wizzup | [ 130.343] fbdev_rr_to_omap_rotate rotation = 8 -> rotate= 1 | 17:08 |
| Wizzup | [ 130.343] ovl_mirror = 0, ovl_rotate=0 | 17:08 |
| Wizzup | lol | 17:08 |
| Wizzup | how | 17:08 |
| Wizzup | oh, I see... | 17:09 |
| Wizzup | freemangordon: doesn't look like the swap method makes xrandr work | 17:10 |
| Wizzup | uvos: re: ddk 1.17 and requiring chimeara | 17:11 |
| Wizzup | don't we have a way to weaking the symbols in the pvr libs? | 17:12 |
| Wizzup | weaken* | 17:12 |
| uvos | sortof helps partailly | 17:12 |
| uvos | but dlopen in mesa still fails | 17:13 |
| uvos | so you have to preload the dri componant | 17:13 |
| uvos | and that causes a bounch of other issues | 17:13 |
| Wizzup | ok | 17:13 |
| uvos | because you have to do it golbaly | 17:13 |
| Wizzup | well we can import gconf in chimeara I bet :) | 17:13 |
| uvos | maybe | 17:13 |
| Wizzup | I did the same for python-gconf and some other things iirc | 17:13 |
| uvos | parazyd mentioned its hard | 17:14 |
| uvos | becuase of dh involement not sure exactly | 17:14 |
| uvos | manwhile i also ported maemo-input sounds away from gconf | 17:14 |
| uvos | *meanwhile | 17:14 |
| Wizzup | it might make sense to start a tracking ticket for all of this stuff | 17:14 |
| Wizzup | like we did with beowulf | 17:14 |
| uvos | we have one | 17:14 |
| Wizzup | https://github.com/maemo-leste/bugtracker/issues/299 | 17:14 |
| Wizzup | ah, where is it? | 17:15 |
| uvos | for gconf | 17:15 |
| uvos | not for porting to chimera generally | 17:15 |
| Wizzup | do you have a link? | 17:15 |
| uvos | no just search gconf on the tracker | 17:15 |
| uvos | so i have mce, osso-applet-display, osso-applet-notificationlight, simple-brightness-applet and maemo-input-sounds ported away from gconf | 17:16 |
| uvos | all of these where just in the way when porting mce away really | 17:16 |
| Wizzup | https://github.com/maemo-leste/bugtracker/issues/481 this one? | 17:21 |
| uvos | yes | 17:21 |
| Wizzup | well we can decide to bite the bullet if the 3d sitation is better, otherwise I don't feel like doing it yet | 17:22 |
| Wizzup | is gsettings and dconf available on beowulf then as well? | 17:23 |
| freemangordon | is port trivial? | 17:23 |
| uvos | port what? | 17:23 |
| uvos | away from gconf? | 17:23 |
| freemangordon | gconf->gsettings | 17:23 |
| uvos | no idea i havent done it | 17:23 |
| Wizzup | so what did you port them to, if not to gsettings? | 17:23 |
| freemangordon | "(18,16,30) uvos: so i have mce, osso-applet-display, osso-applet-notificationlight, simple-brightness-applet and maemo-input-sounds ported away from gconf" ?!? | 17:24 |
| freemangordon | yep, same question | 17:24 |
| uvos | ok so with mce i ported to expose its external iterfaces that it has on gconf to also have getter/setter/notify methods on dbus | 17:25 |
| uvos | then the mce faceing applets i ported to these dbus interfaces | 17:25 |
| uvos | mce also has selectable config backends so it can save to gconf of just a ini file with gsettings bein wip (havent finnished that yet) | 17:25 |
| uvos | and then osso-applet-displa also set on other gconf key | 17:26 |
| uvos | the one that tells maemo-input-sounds to vibrate the with touchscreen presses | 17:26 |
| uvos | this is also the only gconf key it uses, with everthing else, (ie if a sound is to be played when the ts is touched etc) it gets from libprofile | 17:27 |
| Wizzup | so the ui can't set a value unless mce is running? | 17:27 |
| Wizzup | or do I misunderstand | 17:27 |
| Wizzup | freemangordon: so uh, writing to the fb0/rotate doesn't do much with X running | 17:28 |
| uvos | so i just added a touchscreen.vibrattion.enabled key to profiled | 17:28 |
| uvos | and now that is profile dependant same as touchscreen.sounds.enabled | 17:28 |
| uvos | whitch makes more sense anyhow | 17:28 |
| uvos | Wizzup: yeah mce needs to be running for the ui to change the setting, but i dont see how thats a problem, gconf also had to be running and both of those are system global deamons | 17:29 |
| Wizzup | yes but gconf is the config management system | 17:29 |
| Wizzup | and for example settings keys in the ci when building images was already tricky | 17:30 |
| Wizzup | if it requires mce to run it will get a lot more tricky | 17:30 |
| uvos | the main benefit with this is that now all mce interfaces are on dbus so they are allways availbe and dont change when mce changes settings backend. | 17:30 |
| uvos | well mce still stores the stuff soemwhere | 17:30 |
| uvos | so in ci you can just chagne the gconf or gsettings key | 17:30 |
| uvos | i dont see the problem | 17:30 |
| uvos | or in the default ini file if you want to use the ini backend | 17:31 |
| uvos | but thats mainly intended to be a fallback | 17:31 |
| Wizzup | it just seems backwards to me that if an app wants to change a config key that it has to go through mce to set the config key, instead of mce listening to config key changes, I suppose | 17:32 |
| Wizzup | there is already a tool it needs to go through to changes, which is gconf/dconf iiuc | 17:32 |
| uvos | sortof | 17:32 |
| uvos | but if you look at the keys | 17:32 |
| uvos | only really the led ones are really config | 17:32 |
| uvos | its allso really backwards for the external application to request a change in lcd brightness by setting some config key | 17:33 |
| uvos | imo | 17:33 |
| uvos | and since the gconf interfaces are so few (only 3 unique ones) | 17:33 |
| uvos | it makes sense to just move everything to dbus | 17:33 |
| uvos | in this case | 17:33 |
| uvos | i do agree that moveing everything to dbus is not a solution in the general case | 17:33 |
| uvos | outside of mce | 17:33 |
| uvos | the main point here also is that mce can be used with different settings backends and its not ok that mce dependant applicaitons (also outside of maemo leste here) cant be sure that x interface will be available becasue the user decidede to use a different settings strorage backend | 17:34 |
| Wizzup | so in the current beowulf setup, the keys will just end up back in gconf, is that right? | 17:35 |
| Wizzup | via mce | 17:36 |
| uvos | yeah both interfaces are allways kept in sync by mce | 17:36 |
| uvos | ie a dbus request to change the lcd brightness will cause mce to store this in gconf | 17:36 |
| uvos | (or in the ini file if you load that plugin instead) | 17:36 |
| uvos | and changing the gconf key with cause mce to notify its dbus clients of the change also | 17:37 |
| uvos | i would like to know if there are any remaining qualms about how this works... | 17:42 |
| Wizzup | all my qualms currently are with this fbdev clone :) | 17:45 |
| uvos | btw we could also consider | 17:46 |
| uvos | instead of moving to gsetttings | 17:46 |
| uvos | to minimally extending profiled to also provide profile independant keys (or even just using the override profile) and porting everthing to that since this accives independance from gnome wimms and we are lugging profiled around as a settings deamon anyhow | 17:47 |
| uvos | libprofile and gconf are really close in terms of api too | 17:48 |
| Wizzup | I think many things should not go in libprofile | 17:48 |
| Wizzup | like when the email client last updated | 17:48 |
| Wizzup | just check how many gconf keys there are for modest alone | 17:48 |
| uvos | yeah i mean profiled would need a special overarching noprofile profile | 17:49 |
| uvos | other than that i dont see the problem really | 17:49 |
| Wizzup | I think it's not a bad idea to port to gsettings | 17:49 |
| Wizzup | I hope the api will be similar (dconf) | 17:49 |
| uvos | the amount of keys seams not relevant | 17:49 |
| uvos | dconf dosent have stable api at all afaik | 17:49 |
| uvos | we should avoid using it directly | 17:50 |
| Wizzup | https://www.freedesktop.org/software/gstreamer-sdk/data/docs/2012.5/gio/GSettings.html | 17:50 |
| Wizzup | I mean it seems literally the same | 17:50 |
| uvos | sure yeah | 17:50 |
| Wizzup | %s/gconf/g_settings/g | 17:50 |
| Wizzup | default key handling seems different but we always did that anyway | 17:51 |
| uvos | yeah i dont think porting stuff to gesttings is hard | 17:54 |
| mighty17[m] | tmlind: wlroots + sway isnt working as well now :/ | 18:27 |
| mighty17[m] | https://paste.debian.net/1214779/ | 18:27 |
| mighty17[m] | wht sway version do you use? | 19:00 |
| Wizzup | freemangordon: I am going to stop looking at the ddx for a bit | 20:32 |
| Wizzup | (the old one) | 20:32 |
| freemangordon | ok | 20:39 |
| freemangordon | I am compiling 5.15-rc | 20:39 |
| uvos | Wizzup: if your not going to solve the ddx problem | 20:39 |
| MartijnBraam[m] | 5.15 for n900? :D | 20:39 |
| freemangordon | yes | 20:40 |
| uvos | please add a workaround to the h-d function that detects the ddx failure and avoids setting the transform matrix | 20:40 |
| freemangordon | I want to see if pvr driver is working | 20:40 |
| MartijnBraam[m] | the pmos n900 kernel is a bit behind :P | 20:40 |
| sicelo | not a bit :-) | 20:40 |
| freemangordon | so is leste | 20:40 |
| uvos | the leste kernel is more behind im sure | 20:40 |
| sicelo | i wanted to work on it (pmos), then ... the usual | 20:40 |
| freemangordon | sicelo: do you have working config around? | 20:41 |
| uvos | dose omap2plus_defconfig not work? | 20:41 |
| uvos | it should | 20:41 |
| uvos | pls report if it dosent.... | 20:41 |
| freemangordon | it didn;t last time | 20:41 |
| uvos | well thats a bug | 20:41 |
| freemangordon | also, it has a pile of stuff not used on n900 | 20:41 |
| uvos | just searching for some other defconfig is not a solution | 20:42 |
| uvos | so its just modules | 20:42 |
| freemangordon | could be, but my task is to check pvr, not omap2plus_defconfig | 20:42 |
| MartijnBraam[m] | I just remember skipping a few versions because the display was broken, and now we're still on 5.7 | 20:42 |
| uvos | we are on 5.1 so we win | 20:42 |
| sicelo | yes omap2plus should work. i also added a few more modules to it, and Tony kindly accepted my changes :-) | 20:43 |
| MartijnBraam[m] | oof | 20:43 |
| MartijnBraam[m] | are you really winning though? | 20:43 |
| sicelo | freemangordon: but let me quickly check what i have on my laptop | 20:43 |
| freemangordon | sicelo: so you think I should use omap2plus_defconfig to test pvr? | 20:43 |
| freemangordon | hmm | 20:43 |
| freemangordon | ok | 20:43 |
| sicelo | yes, should be fine | 20:44 |
| freemangordon | ok | 20:45 |
| uvos | freemangordon: maybe also try chromeos mesa while at it | 20:45 |
| freemangordon | lemme first have a kernel | 20:45 |
| Wizzup | MartijnBraam[m]: we had trouble forward porting 3d to 5.2+ | 20:45 |
| Wizzup | at least the old 3d | 20:45 |
| uvos | see https://github.com/maemo-leste/bugtracker/issues/524 for links | 20:45 |
| Wizzup | uvos: yeah ok @ workarounds, but not yet | 20:46 |
| Wizzup | uvos: if I add a workaround I will make sure that it also refuses to do xrandr so that sphone won't cause resets :P | 20:46 |
| freemangordon | uvos: this one does not require newer glibc, no? | 20:46 |
| uvos | right | 20:46 |
| freemangordon | so there is no hard dependency to chimaera, IIUC | 20:47 |
| uvos | no it works fine on beowulf | 20:47 |
| freemangordon | mhm | 20:47 |
| uvos | well aside the ususal bugs | 20:47 |
| freemangordon | yeah | 20:47 |
| * Wizzup curious | 20:50 | |
| Wizzup | if it doesn't just straight up hang the device I would be up for trying to help making it work somehow | 20:50 |
| Wizzup | brb | 20:51 |
| uvos | welcome to the fun times of messing with imagination hw | 20:51 |
| uvos | imagination - its what you need so see it working. | 20:52 |
| Wizzup | lol | 20:52 |
| freemangordon | and it does not compile :( | 20:54 |
| uvos | the kernel? | 20:54 |
| freemangordon | mhm | 20:54 |
| uvos | it compiles for sure | 20:54 |
| uvos | i do that often | 20:54 |
| uvos | gcc version maybe? | 20:54 |
| freemangordon | well, the branch I checked out | 20:54 |
| freemangordon | I compile in leste | 20:55 |
| uvos | what did you check out? | 20:55 |
| freemangordon | letux-pvrsrvkm-5.15-rc1 | 20:55 |
| uvos | i use mutch newer gcc | 20:55 |
| uvos | oh | 20:55 |
| uvos | why | 20:55 |
| freemangordon | why what? | 20:55 |
| uvos | use droid4-pending | 20:55 |
| freemangordon | for n900? | 20:55 |
| uvos | yeah | 20:55 |
| freemangordon | why? | 20:55 |
| freemangordon | last time it has droid patches which made it not boot on n900 | 20:55 |
| uvos | its best maintiained and there are not d4 specific hacks in there really | 20:55 |
| uvos | the droid4-pending sgx branch | 20:56 |
| freemangordon | could you provide link? | 20:56 |
| uvos | has nothing d4 specific | 20:56 |
| uvos | https://github.com/tmlind/linux_openpvrsgx/tree/droid4-pending-pvr-omapdrm-v5.15 | 20:57 |
| uvos | this contains just plain 5.15 with tmlinds latest sgx patches | 20:57 |
| uvos | https://github.com/tmlind/linux/tree/droid4-pending-v5.15 | 20:57 |
| uvos | this is where the real pending d4 specific patches are | 20:57 |
| uvos | ts-buttons and modem code and so on | 20:58 |
| uvos | cpcap charger | 20:58 |
| uvos | so i would checkout latest rc | 20:58 |
| uvos | and then merge droid4-pending-pvr-omapdrm-v5.15 | 20:58 |
| freemangordon | uvos: latest -rc is supposed to have sgx driver as well | 20:59 |
| uvos | ? | 20:59 |
| uvos | we are on 5.15 rc3 | 21:00 |
| uvos | er 4 now | 21:00 |
| freemangordon | ok | 21:00 |
| uvos | droid4-pending-pvr-omapdrm-v5.15 is rc2 | 21:00 |
| uvos | so checkout mainline 5.15 rc4 and merge in droid4-pending-pvr-omapdrm-v5.15 | 21:01 |
| freemangordon | hmm, only 1.17 is there | 21:01 |
| freemangordon | but that's fine | 21:01 |
| uvos | ofc | 21:01 |
| uvos | the old ones where dropeed with 5.11 because major rework is needed to get them to compile with omapdrm > 5.13 | 21:02 |
| uvos | becasue it tunnels the ioctls through it before ddk1.17 | 21:02 |
| freemangordon | thats fine as we are not interested in anything < 1.17 | 21:06 |
| Wizzup | right | 21:06 |
| freemangordon | same failur :( | 21:08 |
| Wizzup | it resets when? | 21:09 |
| Wizzup | hangs? | 21:09 |
| freemangordon | https://pastebin.com/SBGfKb0r | 21:09 |
| freemangordon | I cannot compile the kernel | 21:09 |
| Wizzup | you need newer uh | 21:10 |
| Wizzup | dtc | 21:10 |
| freemangordon | hmm? | 21:10 |
| Wizzup | actually, git reset --hard (save the config) | 21:10 |
| Wizzup | so I had this problem recently | 21:10 |
| uvos | or mrproper | 21:10 |
| freemangordon | I think I already did | 21:10 |
| uvos | it compiles fine for me | 21:11 |
| Wizzup | from old logs | 21:11 |
| Wizzup | 18:23 < uvos> mrproper aka rebuild everything helped in these cases | 21:11 |
| Wizzup | 18:23 < bencoh> yeah, mrproper is magic sometimes | 21:11 |
| Wizzup | 18:24 < Wizzup> ok, trying | 21:11 |
| Wizzup | 18:25 -!- Pali [~pali@user/pali] has joined #maemo-leste | 21:11 |
| Wizzup | 18:28 < Wizzup> I mean I don't really need a new dtb anyway | 21:11 |
| Wizzup | 18:30 < Wizzup> ah, no, it looks like the fdt.c errors are from the kernel needing libfdt to unpack the dts | 21:11 |
| Wizzup | 18:31 < Wizzup> I'm using droid4-linux droid4-pending-pvr-omapdrm-v5.11 | 21:11 |
| Wizzup | 18:32 < Wizzup> internet suggests git clean -xdf | 21:11 |
| Wizzup | 18:36 < Wizzup> that fixed it | 21:11 |
| freemangordon | ok, lemme try | 21:11 |
| freemangordon | ah, this is also known as -dfx :D | 21:12 |
| Wizzup | what's the joke? | 21:13 |
| freemangordon | Wizzup: no need to keep the config as I am using vanilla omap2plus_defconfig | 21:13 |
| freemangordon | Wizzup: I am using -dfx and was wondering what -xdf does | 21:13 |
| Wizzup | dfx is Don't FiX | 21:14 |
| freemangordon | or rather - I am used to -dfx | 21:14 |
| freemangordon | I see | 21:14 |
| Wizzup | (that was a joke) | 21:14 |
| Wizzup | (and not funny) | 21:14 |
| freemangordon | yeah | 21:14 |
| Wizzup | I try too hard | 21:14 |
| uvos | btw | 21:19 |
| uvos | charging light on n900 works again right? | 21:19 |
| freemangordon | ok, this time it compiles | 21:22 |
| sicelo | rgb led? i won't be surprised if it doesn't, because there are some issues with the lp55xx LED drivers. 'charging light' is h/w controlled, so that works at all times, unless i'm forgetting something | 21:22 |
| uvos | sicelo: this is about a spcific mce but i fixed | 21:24 |
| uvos | (and introduced in the first place) | 21:24 |
| sicelo | ok. no idea about *that*. if kernel driver doesn't work though ... | 21:26 |
| uvos | it works | 21:26 |
| uvos | (on 5.1) | 21:26 |
| freemangordon | hmm, latest u-boot should boot zImage, right? | 21:28 |
| freemangordon | *should be able to boot | 21:29 |
| uvos | theoreticly yeah | 21:30 |
| uvos | the new uboot that is | 21:30 |
| uvos | but i havent gotten it to work | 21:30 |
| uvos | but i also gave up almost immidatly | 21:30 |
| freemangordon | ok, will do with uImage | 21:30 |
| freemangordon | sicelo: hmm, with omap2plus_defconfig, shall I appned the dtb? | 21:35 |
| sicelo | yes, if you're using uImage | 21:36 |
| freemangordon | but, in kernel config this is not set. or, u-boot is smart enough? | 21:37 |
| sicelo | it isn't set? last i remember it was | 21:37 |
| freemangordon | in omap2plus_defconfig? | 21:37 |
| freemangordon | didn;t check but I doubt it is | 21:37 |
| uvos | cmdline is ofc not forced | 21:38 |
| sicelo | it is | 21:38 |
| sicelo | CONFIG_ARM_APPENDED_DTB=y | 21:38 |
| uvos | idk what you mean | 21:38 |
| sicelo | CONFIG_ARM_ATAG_DTB_COMPAT=y | 21:38 |
| uvos | oh that yeah | 21:38 |
| uvos | yes | 21:38 |
| freemangordon | ok | 21:38 |
| freemangordon | mkimage: Can't read zImage: Invalid argument | 21:39 |
| freemangordon | :( | 21:39 |
| freemangordon | any idea? | 21:39 |
| freemangordon | ok, PEBCAK | 21:40 |
| sicelo | :-) | 21:41 |
| * sicelo has his fingers crossed that the N900 will boot fine (to a working display) | 21:43 | |
| freemangordon | I doubt :) | 21:43 |
| uvos | i still find it kindof funny that the d4 with its locked bootloader ends up with more user frendly boot ergonimics | 21:43 |
| sicelo | freemangordon: the display is the most annoying part of booting a new kernel on N900. (i still need to build my console thingy for N900) | 21:44 |
| freemangordon | and... poweroff | 21:44 |
| uvos | mh | 21:44 |
| uvos | you have the debugkit right | 21:45 |
| freemangordon | no | 21:45 |
| uvos | hmm | 21:45 |
| uvos | great | 21:45 |
| sicelo | oh :-) i don't recall facing that one, but then, i haven't been building N900 kernels for too long | 21:45 |
| freemangordon | yeah :) | 21:45 |
| freemangordon | (debugkit) | 21:45 |
| Wizzup | uvos: latest u-boot for n900? the one I built should work fine? | 21:47 |
| Wizzup | uvos: yes, the mce fix worked for charging light | 21:47 |
| freemangordon | hmm, it has usb console | 21:48 |
| sicelo | i didn't find the uboot console super useful, since kernel disables it once it starts. and the problems are in the kernel. maybe there's a way to ask kernel to not disable it? | 21:49 |
| Wizzup | it is useful for testing / remote stuff | 21:55 |
| Wizzup | compared to typing on that keyboard... ugh | 21:55 |
| Wizzup | I mean I like the keyboard, but not in u-boot :) | 21:55 |
| sicelo | yeah | 21:59 |
| sicelo | it's just that most of the time, the real problems are in the kernel, not uboot :-( | 21:59 |
| sicelo | maybe we really should check if there's no way to have that console persist | 22:00 |
| freemangordon | ok, as expected, omap2plus_defconfig doesn;t boot | 22:02 |
| freemangordon | if anyone has a working config around, please share | 22:02 |
| sicelo | make the watchdog built in. that's one change i usually make to omap2plus | 22:06 |
| sicelo | +CONFIG_OMAP_WATCHDOG=y | 22:06 |
| sicelo | +CONFIG_TWL4030_WATCHDOG=y | 22:06 |
| freemangordon | I am trying leste config ATM | 22:06 |
| sicelo | we should get you its serial console - i want to build one (based on sre's design), but i don't know if i'll be able to understand issues it reports. at least you would | 22:10 |
| freemangordon | do you have the schematics around? | 22:12 |
| freemangordon | or, are those available to buy online? | 22:13 |
| sicelo | even though he didn't provide schematic, it's a bit straightforward. https://n900.elektranox.org/serial-adapter.html | 22:14 |
| freemangordon | hmm, I wonder if I can build something that can fit bellow the battery, so no external power to be needed | 22:19 |
| sicelo | i think so. something that could fit snuggly in the cutout under the battery, then have some thin/flexible wires or ribbon as a breakout | 22:24 |
| freemangordon | mhm | 22:24 |
| freemangordon | but I am not sure I want to take that as well | 22:25 |
| freemangordon | maybe tomorrow I will try to boot vanilla 5.15 | 22:25 |
| freemangordon | if it boots, then maybe a bisect | 22:25 |
| freemangordon | now going to have some sleep. good night! | 22:25 |
| sicelo | o/ | 22:26 |
| Wizzup | sicelo: weird idea but maybe we can get some made in china if the schematics are there | 23:06 |
| Wizzup | (yeah, I'm a bit lazy) | 23:06 |
| Wizzup | freemangordon: if you send me your kernel I can boot it with my serial | 23:07 |
| sicelo | :-) | 23:07 |
| Wizzup | (also modules pls) | 23:07 |
| Wizzup | uvos: do you test mce in a vm? | 23:39 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!