| uvos | freemangordon: ? | 00:55 |
|---|---|---|
| uvos | freemangordon: no that dosent exist on fremantle either | 00:55 |
| uvos | must be something you added localy..... | 00:55 |
| uvos | freemangordon: yeah wierd @x11perf | 00:59 |
| uvos | same here on amdgpu + xephyr | 00:59 |
| uvos | funny it goes away if you compose (tested with kwin_x11) | 01:00 |
| uvos | with Xephyr -resizeable | 01:01 |
| uvos | you can kinda see whats going on here | 01:02 |
| uvos | x11perf looks to be rendering in blocks | 01:02 |
| uvos | and fails to work correctly if a block is partially off screen | 01:02 |
| uvos | that might be as intended | 01:02 |
| uvos | its copywinwin after all | 01:03 |
| uvos | cant copy a 100x100 block if the display isent that large | 01:03 |
| uvos | happens on copypixwin too | 01:06 |
| uvos | so idk | 01:06 |
| uvos | wierd | 01:06 |
| freemangordon | uvos: for sure there is "end current task" on fremantle | 07:42 |
| freemangordon | ctrl-backspace doesn't work either | 07:54 |
| freemangordon | wtf? | 07:54 |
| freemangordon | oh, it seems glmark2-es2 --fullscreen does not create window, somehow | 07:55 |
| freemangordon | hmm, it does not create even in non-fullscreent | 07:56 |
| freemangordon | how is that possible? | 07:56 |
| freemangordon | yay, no more rendering artefacts in h-d with pvr EXA :) | 08:41 |
| Wizzup | :) | 09:01 |
| freemangordon | yeah, will clean-up the code a bit and will push | 09:02 |
| Wizzup | freemangordon: fwiw I have end current task on leste | 09:02 |
| freemangordon | modest scrolls with ~30fps vs 19 without pvr exa | 09:02 |
| Wizzup | freemangordon: we will get it built today :) | 09:02 |
| freemangordon | Wizzup: glmark2-es2? | 09:02 |
| Wizzup | freemangordon: n900 or d4? | 09:03 |
| freemangordon | d4 | 09:03 |
| Wizzup | freemangordon: your code | 09:03 |
| freemangordon | hmm? | 09:03 |
| freemangordon | didn;t get that last one | 09:03 |
| freemangordon | afk, breakfast | 09:03 |
| Wizzup | freemangordon: I said we'll build it once you clean it up | 09:04 |
| tmlind | freemangordon: maybe the flicker is caused by racy vblank handling, maybe on n900 see if the flicker disappears if you temprorarily revert 860382142f5b ("drm/omap: Fix drm_handle_vblank() handling for command mode panels") | 09:07 |
| tmlind | reverting that should stop updating the command mode lcd on d4 though, but if it causes races it would explain the issue | 09:08 |
| freemangordon | tmlind: ok | 09:12 |
| freemangordon | tmlind: still, as I said, I think it is not kernel that shall force-update the display | 09:13 |
| freemangordon | userspace knows when to do it, not kernel | 09:13 |
| freemangordon | for example - I modified omap-video driver to flush the framebuffer on render operation being done | 09:14 |
| freemangordon | but yeah, will see if it works fine on n900 with this reverted | 09:14 |
| freemangordon | tmlind: do you know, if there is any 'drm' way to know if display is manually updated? | 09:16 |
| freemangordon | Wizzup: keep in mind, what I am going to push will work corrctly on d4 only | 09:22 |
| freemangordon | there are 2 things that have to be done to have n900 supported: | 09:22 |
| freemangordon | somehow detect command-mode displays and force-flush only on those | 09:23 |
| freemangordon | and the second one is VRFB :) | 09:23 |
| tmlind | freemangordon: no idea on how the manual update is supposed to happen, probably userspace | 09:31 |
| tmlind | we already call omap_crtc_flush() that's a nop except for command mode displays, then 860382142f5b | 09:33 |
| tmlind | commit attempts to simulate vblank | 09:33 |
| freemangordon | tmlind: yeah, but I would still like to avoid unnecesarry ioctls if possible | 09:33 |
| tmlind | agreed yeah | 09:33 |
| freemangordon | lemme push what I have done so war and then will look at this | 09:34 |
| tmlind | the weston timeout config options might give clues how it's supposed to work, sounds like weston has a timer to force refresh if it did not happen earlier | 09:34 |
| freemangordon | tmlind: this sounds like a hack to me, but well, if there is no option | 09:35 |
| tmlind | yeah but maybe you're right and kernel does not even know except for the framebuffer stuff | 09:36 |
| freemangordon | I would avoid unnecessary wakeups (timer-based flushed) if possible | 09:36 |
| tmlind | right, event triggered refresh would be the best | 09:36 |
| freemangordon | I don;t see how kernel could possibly know when a render op is complete | 09:37 |
| freemangordon | imagine - it could be IVA that renders, not SGX | 09:37 |
| freemangordon | 'renders' - like drawing to front buffer | 09:37 |
| freemangordon | it will be ugly, I know, but possible in practice | 09:38 |
| tmlind | yeah | 09:38 |
| freemangordon | how is omapdrm supposed to know that IVA has finished? | 09:38 |
| tmlind | no idea, dma callback done seems like the only trigger | 09:38 |
| freemangordon | not to say I don;t see any fences support in omapdrm, but it could be that it counts on drm code for that | 09:39 |
| tmlind | not even sure iva uses dma, it might be bus mastering with it's internal dma | 09:39 |
| freemangordon | I forgot the details | 09:39 |
| freemangordon | but it is not relevant | 09:39 |
| freemangordon | the point is that it is userspace that has the information on when a flush, flip, swap, whatever shall happen | 09:39 |
| tmlind | well reverting 860382142f5b and seeing if it fixed flicker on n900 might be a good test to narrow this down | 09:40 |
| freemangordon | yeah, will do, just lemme push what I have done so far :) | 09:40 |
| tmlind | yeah will be offline for most part, but will read the results at some point :) | 09:40 |
| freemangordon | ok | 09:40 |
| freemangordon | Wizzup: done | 09:49 |
| freemangordon | LMK when we have a kernel that produces SGX headers | 09:50 |
| freemangordon | tmlind: with 860382142f5b reverted neither d4 nor n900 boot | 10:24 |
| freemangordon | oh, wait | 10:24 |
| freemangordon | I have one more change | 10:24 |
| freemangordon | lemme revert it and retry | 10:24 |
| freemangordon | ok, n900 boots now | 10:32 |
| Wizzup | freemangordon: ok, some time today | 10:49 |
| freemangordon | ok | 10:49 |
| uvos | freemangordon: yeah i do have end current task on leste | 11:03 |
| uvos | but not on fremantle n900 maybe its something you added in cssu | 11:03 |
| uvos | wrt ctrl-backspace | 11:03 |
| uvos | i made this configurable per device, and unquley to the mapphones its configured to be the home button instead | 11:03 |
| uvos | ofc you aperantly dont have ts-buttons in your kernel so its nothing now | 11:03 |
| freemangordon | we should have consistent behaviour | 11:04 |
| freemangordon | device-specific should be addition, not replacement | 11:04 |
| freemangordon | anyway, gtg now | 11:04 |
| uvos | right that was the plan | 11:04 |
| freemangordon | ah, ok | 11:05 |
| uvos | but we cant bind multiple keys to one action yet | 11:05 |
| freemangordon | ok | 11:05 |
| Wizzup | freemangordon: so this is ready for building? https://github.com/maemo-leste/droid4-linux/commits/droid4-pending-pvr-omapdrm-v5.15 | 12:38 |
| uvos | Wizzup: any luck with asking whats up with gitorious,org? | 16:56 |
| uvos | (just curious no pessure) | 16:56 |
| freemangordon | Wizzup: yes | 17:55 |
| freemangordon | tmlind: reverting 860382142f5b doesn't help | 18:00 |
| Wizzup | uvos: completely forgot... | 18:15 |
| Wizzup | note to self http://web.archive.org/web/20130816141615/http://gitorious.org/droid | 18:16 |
| bencoh | well, I just ran apt-get upgrade on a droid4 (haven't upgraded for a few months I think), and it looks like xorg turned itself off (I guess) | 18:28 |
| bencoh | I think it's trying to reboot | 18:28 |
| bencoh | is that supposed to happen? | 18:28 |
| uvos | no | 18:33 |
| bencoh | well ... | 18:33 |
| uvos | dsme is broken with apt | 18:33 |
| bencoh | huhu | 18:33 |
| uvos | you have to disable lifeguard | 18:33 |
| uvos | or its just broken | 18:33 |
| bencoh | I guess I just broke my rootfs then :D | 18:33 |
| uvos | any daemon that dosent start after upgrade for any reason will break the system | 18:33 |
| bencoh | usb doesn't work properly here, so .... | 18:33 |
| uvos | by dsme shuting down while apt is still upgrading | 18:34 |
| bencoh | ohwell | 18:34 |
| uvos | in recent times this was ke-recv | 18:34 |
| Wizzup | I think dsme stop is a no-op, no? | 18:34 |
| uvos | Wizzup: no thats not the problem | 18:35 |
| uvos | Wizzup: any deamon that dosent start (in this case it was just ke-recv not starting becasue of a small bug that sometimes caused the init script to fail if restarted to fast) will break the entire system becaus lifeguard then reboots while apt is till upgrading | 18:36 |
| Wizzup | right, but why would init scripts fail | 18:36 |
| uvos | bencoh: just touch /etc/no_lg_reboots to disable lifeguard | 18:36 |
| uvos | Wizzup: they should not, but dsme breaking the entire system becasue one deamon failed to restart during an upgrade is not ok | 18:37 |
| uvos | bencoh: you can usually avoid reinstalling by booting into recovery shell and finishing the upgrade | 18:37 |
| uvos | bencoh: depdens on what broke exactly ofc. | 18:38 |
| Wizzup | dsme does the right thing because if for example mce fails to start (10 times mind you) the device cannot be locked or unlocked, the ts is never enabled/disabled and a lot more is insanely broken | 18:39 |
| freemangordon | :nod: | 18:39 |
| uvos | Wizzup: landing in a boot loop in this case is less usefull than a running system you can debug | 18:39 |
| uvos | but this isent even about that | 18:39 |
| bencoh | uvos: I think we should do that or something similar in every preinst/postinst | 18:39 |
| uvos | its abou dsme rebooting _DURING AN APT UPGRADE_ | 18:40 |
| uvos | this dsme should _NEVER_ do under any circumstances | 18:40 |
| uvos | because it breaks the system way more and way more permanently than some failing deamon | 18:40 |
| bencoh | alright, let's forcehalt it then | 18:40 |
| bencoh | I guess it at least finished writing buffers by now | 18:41 |
| Wizzup | uvos: yeah maybe we can do something with apt upgrades | 18:41 |
| Wizzup | nokia had special moved for that iirc | 18:41 |
| Wizzup | modes* | 18:41 |
| uvos | i still think dmse rebooting is less usefull than it not doing anything | 18:41 |
| uvos | if the deamon is failing more than 10 times | 18:42 |
| uvos | a reboot wont help most likely | 18:42 |
| uvos | and it just forces an endless reboot loop | 18:42 |
| uvos | really dsme should send a libnotfy notification | 18:42 |
| uvos | with oh shit this deamon is broken seek help | 18:42 |
| uvos | that would accualty be usefull | 18:42 |
| Wizzup | doesn't help in your pocket | 18:43 |
| Wizzup | or for X | 18:43 |
| Wizzup | but yes some way to assess system health would be nice | 18:44 |
| uvos | the reboot dosent help either | 18:44 |
| freemangordon | no, what is actually failproof and useful is to *not* restart daemons on upgrade | 18:44 |
| uvos | no its not | 18:44 |
| freemangordon | critical ones that is | 18:44 |
| uvos | deamons have resources | 18:44 |
| Wizzup | yeah this is a sad debianism | 18:44 |
| freemangordon | no, this is set in debian/rules fille | 18:45 |
| freemangordon | what to do on upgrade (start/restart or not) | 18:45 |
| uvos | i def deamons should restart | 18:45 |
| uvos | its silly to have to reboot after upgrade | 18:45 |
| freemangordon | no, if you do system upgrade, you better restart the whole device | 18:45 |
| freemangordon | this is not 24/7 server | 18:45 |
| freemangordon | even you beloved android restarts on system upgrade ;) | 18:46 |
| uvos | not haveing to reboot after upgrade is a usefull and well regarded feature on any device | 18:46 |
| freemangordon | anyway, have to cook | 18:46 |
| Wizzup | what does sphone do on upgrade? does it kill itself and start the new version? | 18:46 |
| uvos | i dont like android, why do you think im here | 18:46 |
| freemangordon | :p | 18:46 |
| freemangordon | ttyl | 18:46 |
| bencoh | apt-get said nothing to be done from emergency shell ... let's see | 18:46 |
| parazyd | lmao why would you have to restart the whole system for a single daemon upgrade | 18:47 |
| uvos | Wizzup: no it fails to work | 18:47 |
| parazyd | You should only be rebooting on kernel upgrades | 18:47 |
| uvos | Wizzup: but thats not hwo its supposed to be ofc | 18:47 |
| bencoh | wow, it booted to hildon | 18:47 |
| bencoh | not *that* broken after all | 18:47 |
| uvos | bencoh: lucky | 18:47 |
| bencoh | yeah | 18:48 |
| bencoh | well, I should probably start debugging that usb thing, but .... | 18:48 |
| bencoh | (host says [1297603.744934] usb 2-1: USB disconnect, device number 33 after 3 seconds) | 18:49 |
| Wizzup | bencoh: this is exactly what someone else experieced a few days ago as well | 18:51 |
| bencoh | I've been seeing this here since I moved to leste | 18:52 |
| freemangordon | parazyd: only when upgrading critical stuff like mce or Xorg, for example | 18:53 |
| bencoh | Picking 'droid4-linux' as source package instead of 'linux-image-droid4' | 18:53 |
| bencoh | E: Unable to find a source package for droid4-linux | 18:53 |
| bencoh | when running apt-get source linux-image-droid4 | 18:53 |
| bencoh | I dunno if that's expected | 18:53 |
| uvos | i made sure mce survives restart just fine | 18:53 |
| uvos | please restart it on upgrade | 18:54 |
| parazyd | bencoh: Did you add a deb-src in sources.list? | 18:54 |
| bencoh | deb-src http://maedevu.maemo.org/leste beowulf main contrib non-free droid4 | 18:55 |
| bencoh | I might be missing a repository, but ... | 18:55 |
| uvos | do we do source pacakges? | 18:55 |
| bencoh | $ apt-cache show droid4-linux | 18:55 |
| bencoh | N: Unable to locate package droid4-linux | 18:55 |
| bencoh | this might explain the issue I guess | 18:55 |
| parazyd | bencoh: ah it's not there indeed | 18:56 |
| parazyd | Maybe because it's built a bit differently (using kernel scripts) | 18:56 |
| uvos | bencoh: its here btw https://github.com/maemo-leste/droid4-linux | 18:58 |
| uvos | if you need it | 18:58 |
| Wizzup | freemangordon: yeah xorg also has abi | 18:58 |
| Wizzup | if we upgrade it and the input drivers change, then this can quickly become a problem | 18:59 |
| Wizzup | especially since we disabled devices as well | 18:59 |
| bencoh | uvos: yeah I'll just fetch from there, thx | 19:00 |
| bencoh | I wanted to check what was used to build it actually, but ... let's see :) | 19:00 |
| Wizzup | there's also 5.15 branch we're working on now | 19:04 |
| bencoh | how do you guys handle kernel upgrades / debugging on droid4? | 19:07 |
| uvos | bencoh: what do you want to acchive exactly? | 19:08 |
| bencoh | debug usb ... but I'd be happy with just a quick/easy way to downgrade in case I really mess the kernel | 19:08 |
| uvos | im not sure what the problem is | 19:09 |
| uvos | build your debugging kernel | 19:09 |
| uvos | copy it to the device | 19:09 |
| uvos | and make a new boot entry | 19:09 |
| uvos | then you can just switch when your new debugging/dev kernel fails for some reason | 19:09 |
| bencoh | ah, it's that easy with kexecboot? alright | 19:10 |
| uvos | yeah | 19:10 |
| uvos | like grub really :P | 19:10 |
| uvos | (bootentrys are in /boot/boot/booot.cfg btw) | 19:11 |
| bencoh | (yeah, just found that, thx :) ) | 19:11 |
| bencoh | looks nice | 19:11 |
| bencoh | uh, I don't really understand why the maemo branch contain only the debian folders tbh | 19:18 |
| parazyd | 19:10 <parazyd> ok so: | 19:24 |
| parazyd | 19:10 <parazyd> $ git checkout maemo-5.15 | 19:24 |
| parazyd | 19:10 <parazyd> $ git checkout maemo/beowulf-experimental debian | 19:24 |
| parazyd | 19:10 <parazyd> $ gbp buildpackage --no-sign --git-ignore-branch --git-ignore-new | 19:24 |
| parazyd | 19:10 <parazyd> (I think that's more or less how Jenkins does it too) | 19:25 |
| parazyd | bencoh: ^ | 19:25 |
| bencoh | thx | 19:25 |
| bencoh | is that the debian recommended way to manage kernel packages (debian/ in a separate branch with an "upstream" tag)? | 19:28 |
| bencoh | (the 5.10.9 tag points to a 5.10.30 kernel, btw) | 19:28 |
| uvos | uh | 19:30 |
| parazyd | Sometimes, there's no definite standard really | 19:30 |
| uvos | this is stupid | 19:30 |
| uvos | we increment the version | 19:30 |
| uvos | independent of mainline | 19:30 |
| parazyd | The tags are a mess but that's gonna change now with 5.15 | 19:30 |
| uvos | great | 19:30 |
| uvos | i hated that | 19:30 |
| uvos | bencoh: also generaly check if your usb issue is in 5.15 even | 19:31 |
| bencoh | parazyd: any reason why we don't keep a debian/ folder in the regular branch and just rebase/merge/whatever onto mainline everytime we need to? | 19:32 |
| uvos | bencoh: you can just build the droid4-pending-5.15 branch and boot the emergency shell with it | 19:32 |
| uvos | (it wont boot the gui ofc | 19:32 |
| uvos | ) | 19:32 |
| bencoh | is usbnet supposed to work without any config from userspace? | 19:33 |
| bencoh | (do we use configfs?) | 19:33 |
| parazyd | bencoh: One (of a few) reasons is that the Linux kernel has its own build scripts and also has a .gitignore for debian/ by default. | 19:33 |
| parazyd | bencoh: But you can easily checkout the directory when you're on the maemo-5.y branch | 19:34 |
| bencoh | yeah that's what I did :) | 19:36 |
| bencoh | ah, we use configfs | 19:37 |
| freemangordon | ugh, glmark2-es2 sets swap_interval to 0, which I guess means - 'do not wait for vsync', however, dri2 code understands this as 'blit to front buffer' | 20:02 |
| freemangordon | that's why result on n900 is 28 vs 37 for -drm | 20:03 |
| Wizzup | ah | 20:03 |
| freemangordon | but, knowing this doesn;t help much with flickering | 20:03 |
| freemangordon | I suspect this is something in omapdrm, but have no idea how to chase it | 20:04 |
| freemangordon | hmm, if I disable page-flip path in DDX (so it blits) there is no flickering | 20:43 |
| freemangordon | and this is the reason why glmark does not flicker, but h-d does | 20:46 |
| freemangordon | h-d takes the fast route (page-flip_ | 20:46 |
| freemangordon | unfortunately it is as slow as blit and flickers on top | 20:46 |
| freemangordon | so it is something on omapdrm | 20:46 |
| freemangordon | somewhere in page-flip code | 20:46 |
| Wizzup | getting there it sounds like :) | 21:34 |
| freemangordon | unfortunately no | 21:46 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!