<uvos>
funny it goes away if you compose (tested with kwin_x11)
<uvos>
with Xephyr -resizeable
<uvos>
you can kinda see whats going on here
<uvos>
x11perf looks to be rendering in blocks
<uvos>
and fails to work correctly if a block is partially off screen
<uvos>
that might be as intended
<uvos>
its copywinwin after all
<uvos>
cant copy a 100x100 block if the display isent that large
<uvos>
happens on copypixwin too
<uvos>
so idk
<uvos>
wierd
uvos has quit [Ping timeout: 260 seconds]
Pali has quit [Ping timeout: 256 seconds]
joerg has quit [Ping timeout: 268 seconds]
joerg has joined #maemo-leste
xmn has quit [Ping timeout: 260 seconds]
<freemangordon>
uvos: for sure there is "end current task" on fremantle
<freemangordon>
ctrl-backspace doesn't work either
<freemangordon>
wtf?
<freemangordon>
oh, it seems glmark2-es2 --fullscreen does not create window, somehow
<freemangordon>
hmm, it does not create even in non-fullscreent
<freemangordon>
how is that possible?
linmob has quit [Ping timeout: 264 seconds]
<freemangordon>
yay, no more rendering artefacts in h-d with pvr EXA :)
linmob has joined #maemo-leste
pere has quit [Ping timeout: 256 seconds]
<Wizzup>
:)
<freemangordon>
yeah, will clean-up the code a bit and will push
<Wizzup>
freemangordon: fwiw I have end current task on leste
<freemangordon>
modest scrolls with ~30fps vs 19 without pvr exa
<Wizzup>
freemangordon: we will get it built today :)
<freemangordon>
Wizzup: glmark2-es2?
<Wizzup>
freemangordon: n900 or d4?
<freemangordon>
d4
<Wizzup>
freemangordon: your code
Twig has joined #maemo-leste
<freemangordon>
hmm?
<freemangordon>
didn;t get that last one
<freemangordon>
afk, breakfast
<Wizzup>
freemangordon: I said we'll build it once you clean it up
<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")
<tmlind>
reverting that should stop updating the command mode lcd on d4 though, but if it causes races it would explain the issue
<freemangordon>
tmlind: ok
<freemangordon>
tmlind: still, as I said, I think it is not kernel that shall force-update the display
<freemangordon>
userspace knows when to do it, not kernel
<freemangordon>
for example - I modified omap-video driver to flush the framebuffer on render operation being done
<freemangordon>
but yeah, will see if it works fine on n900 with this reverted
<freemangordon>
tmlind: do you know, if there is any 'drm' way to know if display is manually updated?
joerg is now known as DocScrutinizer
DocScrutinizer is now known as joerg
<freemangordon>
Wizzup: keep in mind, what I am going to push will work corrctly on d4 only
<freemangordon>
there are 2 things that have to be done to have n900 supported:
<freemangordon>
somehow detect command-mode displays and force-flush only on those
<freemangordon>
and the second one is VRFB :)
<tmlind>
freemangordon: no idea on how the manual update is supposed to happen, probably userspace
<tmlind>
we already call omap_crtc_flush() that's a nop except for command mode displays, then 860382142f5b
<tmlind>
commit attempts to simulate vblank
<freemangordon>
tmlind: yeah, but I would still like to avoid unnecesarry ioctls if possible
<tmlind>
agreed yeah
<freemangordon>
lemme push what I have done so war and then will look at this
<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
<freemangordon>
tmlind: this sounds like a hack to me, but well, if there is no option
<tmlind>
yeah but maybe you're right and kernel does not even know except for the framebuffer stuff
<freemangordon>
I would avoid unnecessary wakeups (timer-based flushed) if possible
<tmlind>
right, event triggered refresh would be the best
<freemangordon>
I don;t see how kernel could possibly know when a render op is complete
<freemangordon>
imagine - it could be IVA that renders, not SGX
<freemangordon>
'renders' - like drawing to front buffer
<freemangordon>
it will be ugly, I know, but possible in practice
<tmlind>
yeah
<freemangordon>
how is omapdrm supposed to know that IVA has finished?
<tmlind>
no idea, dma callback done seems like the only trigger
<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
<tmlind>
not even sure iva uses dma, it might be bus mastering with it's internal dma
<freemangordon>
I forgot the details
<freemangordon>
but it is not relevant
<freemangordon>
the point is that it is userspace that has the information on when a flush, flip, swap, whatever shall happen
<tmlind>
well reverting 860382142f5b and seeing if it fixed flicker on n900 might be a good test to narrow this down
<freemangordon>
yeah, will do, just lemme push what I have done so far :)
<tmlind>
yeah will be offline for most part, but will read the results at some point :)
<freemangordon>
ok
<freemangordon>
Wizzup: done
<freemangordon>
LMK when we have a kernel that produces SGX headers
Twig has quit [Ping timeout: 256 seconds]
Twig has joined #maemo-leste
<freemangordon>
tmlind: with 860382142f5b reverted neither d4 nor n900 boot
<freemangordon>
oh, wait
<freemangordon>
I have one more change
<freemangordon>
lemme revert it and retry
pere has joined #maemo-leste
<freemangordon>
ok, n900 boots now
<Wizzup>
freemangordon: ok, some time today
<freemangordon>
ok
uvos has joined #maemo-leste
<uvos>
freemangordon: yeah i do have end current task on leste
<uvos>
but not on fremantle n900 maybe its something you added in cssu
<uvos>
wrt ctrl-backspace
<uvos>
i made this configurable per device, and unquley to the mapphones its configured to be the home button instead
<uvos>
ofc you aperantly dont have ts-buttons in your kernel so its nothing now
<freemangordon>
we should have consistent behaviour
<freemangordon>
device-specific should be addition, not replacement
<freemangordon>
anyway, gtg now
<uvos>
right that was the plan
<freemangordon>
ah, ok
<uvos>
but we cant bind multiple keys to one action yet
<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)
<bencoh>
I think it's trying to reboot
<bencoh>
is that supposed to happen?
<uvos>
no
<bencoh>
well ...
<uvos>
dsme is broken with apt
<bencoh>
huhu
<uvos>
you have to disable lifeguard
<uvos>
or its just broken
<bencoh>
I guess I just broke my rootfs then :D
<uvos>
any daemon that dosent start after upgrade for any reason will break the system
<bencoh>
usb doesn't work properly here, so ....
<uvos>
by dsme shuting down while apt is still upgrading
<bencoh>
ohwell
<uvos>
in recent times this was ke-recv
<Wizzup>
I think dsme stop is a no-op, no?
<uvos>
Wizzup: no thats not the problem
<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
<Wizzup>
right, but why would init scripts fail
<uvos>
bencoh: just touch /etc/no_lg_reboots to disable lifeguard
<uvos>
Wizzup: they should not, but dsme breaking the entire system becasue one deamon failed to restart during an upgrade is not ok
<uvos>
bencoh: you can usually avoid reinstalling by booting into recovery shell and finishing the upgrade
<uvos>
bencoh: depdens on what broke exactly ofc.
<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
<freemangordon>
:nod:
<uvos>
Wizzup: landing in a boot loop in this case is less usefull than a running system you can debug
<uvos>
but this isent even about that
<bencoh>
uvos: I think we should do that or something similar in every preinst/postinst
<uvos>
its abou dsme rebooting _DURING AN APT UPGRADE_
<uvos>
this dsme should _NEVER_ do under any circumstances
<uvos>
because it breaks the system way more and way more permanently than some failing deamon
<bencoh>
alright, let's forcehalt it then
<bencoh>
I guess it at least finished writing buffers by now
<Wizzup>
uvos: yeah maybe we can do something with apt upgrades
<Wizzup>
nokia had special moved for that iirc
<Wizzup>
modes*
<uvos>
i still think dmse rebooting is less usefull than it not doing anything
<uvos>
if the deamon is failing more than 10 times
<uvos>
a reboot wont help most likely
<uvos>
and it just forces an endless reboot loop
<uvos>
really dsme should send a libnotfy notification
<uvos>
with oh shit this deamon is broken seek help
<uvos>
that would accualty be usefull
<Wizzup>
doesn't help in your pocket
<Wizzup>
or for X
<Wizzup>
but yes some way to assess system health would be nice
<uvos>
the reboot dosent help either
<freemangordon>
no, what is actually failproof and useful is to *not* restart daemons on upgrade
<uvos>
no its not
<freemangordon>
critical ones that is
<uvos>
deamons have resources
<Wizzup>
yeah this is a sad debianism
<freemangordon>
no, this is set in debian/rules fille
<freemangordon>
what to do on upgrade (start/restart or not)
<uvos>
i def deamons should restart
<uvos>
its silly to have to reboot after upgrade
<freemangordon>
no, if you do system upgrade, you better restart the whole device
<freemangordon>
this is not 24/7 server
<freemangordon>
even you beloved android restarts on system upgrade ;)
<uvos>
not haveing to reboot after upgrade is a usefull and well regarded feature on any device
<freemangordon>
anyway, have to cook
<Wizzup>
what does sphone do on upgrade? does it kill itself and start the new version?
<uvos>
i dont like android, why do you think im here
<freemangordon>
:p
<freemangordon>
ttyl
<bencoh>
apt-get said nothing to be done from emergency shell ... let's see
<parazyd>
lmao why would you have to restart the whole system for a single daemon upgrade
<uvos>
Wizzup: no it fails to work
<parazyd>
You should only be rebooting on kernel upgrades
<uvos>
Wizzup: but thats not hwo its supposed to be ofc
<bencoh>
wow, it booted to hildon
<bencoh>
not *that* broken after all
<uvos>
bencoh: lucky
<bencoh>
yeah
<bencoh>
well, I should probably start debugging that usb thing, but ....
<bencoh>
(host says [1297603.744934] usb 2-1: USB disconnect, device number 33 after 3 seconds)
<Wizzup>
bencoh: this is exactly what someone else experieced a few days ago as well
<bencoh>
I've been seeing this here since I moved to leste
<freemangordon>
parazyd: only when upgrading critical stuff like mce or Xorg, for example
<bencoh>
Picking 'droid4-linux' as source package instead of 'linux-image-droid4'
<bencoh>
E: Unable to find a source package for droid4-linux
<bencoh>
when running apt-get source linux-image-droid4
<bencoh>
I dunno if that's expected
<uvos>
i made sure mce survives restart just fine
<uvos>
please restart it on upgrade
<parazyd>
bencoh: Did you add a deb-src in sources.list?
<parazyd>
19:10 <parazyd> (I think that's more or less how Jenkins does it too)
<parazyd>
bencoh: ^
<bencoh>
thx
<bencoh>
is that the debian recommended way to manage kernel packages (debian/ in a separate branch with an "upstream" tag)?
<bencoh>
(the 5.10.9 tag points to a 5.10.30 kernel, btw)
<uvos>
uh
<parazyd>
Sometimes, there's no definite standard really
<uvos>
this is stupid
<uvos>
we increment the version
<uvos>
independent of mainline
<parazyd>
The tags are a mess but that's gonna change now with 5.15
<uvos>
great
<uvos>
i hated that
Daaanct12 is now known as Danct12
<uvos>
bencoh: also generaly check if your usb issue is in 5.15 even
<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?
<uvos>
bencoh: you can just build the droid4-pending-5.15 branch and boot the emergency shell with it
<uvos>
(it wont boot the gui ofc
<uvos>
)
<bencoh>
is usbnet supposed to work without any config from userspace?
<bencoh>
(do we use configfs?)
<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.
<parazyd>
bencoh: But you can easily checkout the directory when you're on the maemo-5.y branch
<bencoh>
yeah that's what I did :)
<bencoh>
ah, we use configfs
pere has quit [Ping timeout: 240 seconds]
uvos has quit [Ping timeout: 268 seconds]
<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'
<freemangordon>
that's why result on n900 is 28 vs 37 for -drm
<Wizzup>
ah
<freemangordon>
but, knowing this doesn;t help much with flickering
<freemangordon>
I suspect this is something in omapdrm, but have no idea how to chase it
System_Error has quit [Remote host closed the connection]
System_Error has joined #maemo-leste
<freemangordon>
hmm, if I disable page-flip path in DDX (so it blits) there is no flickering
<freemangordon>
and this is the reason why glmark does not flicker, but h-d does
<freemangordon>
h-d takes the fast route (page-flip_
<freemangordon>
unfortunately it is as slow as blit and flickers on top
<freemangordon>
so it is something on omapdrm
<freemangordon>
somewhere in page-flip code
doc has quit [Quit: Things to do]
pere has joined #maemo-leste
Daanct12 has joined #maemo-leste
Danct12 has quit [Read error: Connection reset by peer]
doc has joined #maemo-leste
Daaanct12 has joined #maemo-leste
Daanct12 has quit [Ping timeout: 260 seconds]
<Wizzup>
getting there it sounds like :)
xmn has quit [Quit: ZZZzzz…]
<freemangordon>
unfortunately no
xmn has joined #maemo-leste
elastic_dog has quit [Ping timeout: 240 seconds]
elastic_dog has joined #maemo-leste
The_Niz has quit [Remote host closed the connection]