xmn has quit [Quit: ZZZzzz…]
sunshavi_ has quit [Read error: Connection reset by peer]
_inky has quit [Ping timeout: 260 seconds]
cockroach has quit [Quit: leaving]
xmn has joined #maemo-leste
_inky has joined #maemo-leste
Pali has quit [Ping timeout: 260 seconds]
joerg has quit [Read error: Connection reset by peer]
joerg has joined #maemo-leste
sunshavi has joined #maemo-leste
joerg has quit [Ping timeout: 268 seconds]
joerg has joined #maemo-leste
xmn has quit [Quit: ZZZzzz…]
xmn has joined #maemo-leste
Danct12 has quit [Remote host closed the connection]
<freemangordon> tmlind: uvos: I see absolutely no tearing on d4 HDMI with omap-video
<freemangordon> so it seems the tearing I see on n900, is not what you see on d4 with sway/weston or whatever you use
<freemangordon> hmm, seems my TV vsync is 50 Hz
<freemangordon> d4, 1920x1080 glmark2 Score: 30 :)
<freemangordon> not that this helps with n900
<tmlind> freemangordon: ok, yeah i see flicker on d4 hdmi but only after slowing down sgx clock rate as noted by uvos
<tmlind> maybe taking a video of the hdmi output might show some frames with black squares even at the normal sgx clock rate
<freemangordon> could you provide commands to slow down the device?
<freemangordon> or I shall wait for uvos?
Danct12 has joined #maemo-leste
<tmlind> looking at my notes pretty sure i use sudo rwmem 0x4a008164=0x1f to slow down sgx, can't check my test script right now
<tmlind> need to go, will drop by again later on
<freemangordon> ok
<freemangordon> tmlind: ok, yeah, I can repro now, thanks
Twig has joined #maemo-leste
<freemangordon> actually no need for HDMI
<freemangordon> it artefacts badly on DSI as well
<freemangordon> ok, good that I have a test case now
<freemangordon> hmm, ok, seems PVR driver attaches exclusive fense to each BO, bu I doubt omapdrm waits on it
<freemangordon> or. maybe it is core that shall wait, but it does not?
<tmlind> no idea, but the fact it also happens with hdmi means it's not related to the command mode lcd
<freemangordon> tmlind: ok, I think I have an idea what happens
<freemangordon> not sure though, but still
<freemangordon> PVR attaches exclusive fence to BOs it is about to render
<freemangordon> but, I don;t see where omapdrm waits for those fences to get signalled
<freemangordon> so, either PVR signals fences too early, or omapdrm does not wait for fence to be signalled
<freemangordon> this is when flip has been requested
<freemangordon> but, I would say it is omapdrm to blame, as pvr seems to obay its own fences
<freemangordon> like, there is not tear if blit through HW is done
<freemangordon> tmlind: I am trying to find where in omapdrm/drm kernel code is supposed this wait to happen
<freemangordon> so far no luck
<freemangordon> tmlind: also, look at 942d8344d5f14b9ea2ae43756f319b9f44216ba4
<freemangordon> I am not sure I understand the commit message :)
<tmlind> no idea about that stuff
Pali has joined #maemo-leste
The_Niz has joined #maemo-leste
<freemangordon> hmm, ok, it seems pvr driver sets fence to signalled too early
xmn has quit [Quit: xmn]
<freemangordon> tmlind: adding msleep(50); in omap_framebuffer_pin() makes flicker go away
<freemangordon> so, it seems pvr driver doesn't behave correctly in regards to fences
<freemangordon> afaik it should signal exclusive fence only *after* write ops have been completed
<freemangordon> I have no clue how to deal with that
<freemangordon> or, maybe the idea is to add GL fence before calling swap?
zhxt has joined #maemo-leste
<tmlind> freemangordon: interesting if you can make them go away with msleep, will give it a try when i can later on today or tomorrow
<tmlind> uvos might have some ideas based on that on what to fix, i sure don't
cockroach has joined #maemo-leste
<freemangordon> tmlind: well, flicker goes away, but fps is like 10 :)
<tmlind> heh
<Wizzup> building mesa for experimental now
zhxt has quit [Ping timeout: 268 seconds]
nohit has quit [Remote host closed the connection]
<Wizzup> freemangordon: i think it should be in the experimental repo in ~15 mins
<freemangordon> great
<freemangordon> hmm, what's wrong with usleep?
<freemangordon> usleep(500000); shall sleep for 500 ms, right?
<Wizzup> in C?
<Wizzup> as in userspace?
<bencoh> nah, usleep() wakes up from ALARM
<bencoh> you should use nanosleep
xes has quit [Ping timeout: 264 seconds]
panzeroceania has quit [Ping timeout: 260 seconds]
<freemangordon> hmm
<freemangordon> oh, ok
<bencoh> now I'm curious about the fact that you supposedly get an alrm signal, but ... :)
<Wizzup> man 3 usleep does not mention ALARM at all
<freemangordon> bencoh: hmm, I don;t see anyting like that here https://man7.org/linux/man-pages/man3/usleep.3.html
<bencoh> freemangordon: The interaction of this function with the SIGALRM signal [...]
* freemangordon reads
<bencoh> (yeah, ALRM, not ALARM)
<bencoh> anyway, it was even removed from posix-2008 :)
<freemangordon> I don't think I receive SIGALRM in xorg, but yeah, who knows
xes has joined #maemo-leste
<freemangordon> Wizzup: mesa seems ok
<Wizzup> cool
<Wizzup> there's still the libllvm thing
<Wizzup> but that's for later
<bencoh> what about it?
<Wizzup> our mesa uses/requires (tbd) libllvm8
<Wizzup> which is only in backports
<bencoh> oh so it builds but doesn't work then?
<bencoh> I mean, it looked like the mesa tests passed
<Wizzup> yes it works
<Wizzup> the package just depends on it
<Wizzup> I don't know what happens if you uninstall the libllvm8 package
<Wizzup> maybe it just works and the control is just overley whiney
<Wizzup> overly*
<Wizzup> or maybe it just works if it's built in CI
<Wizzup> I can't test atm
<Wizzup> man, it's a _royal_ pain to build our droid4-linux locally
<Wizzup> the build scripts seem to be in debian/patches which makes it also really hard to modify :D
<Wizzup> the instructions provided by parazyd also don't work for me
<Wizzup> actually it might work if you manually remove the .pc directory
<Wizzup> nope..
<Wizzup> it's so insane, I did a clean checkout of the branch and manually applied the patches
<Wizzup> but quilt still manages to complain!
<freemangordon> using nanosleep to sleep 40 msecs before requesting flip makes, in omap-video, makes flickering go away on d4
<freemangordon> ok, so, obviously a fence is missing
<freemangordon> or is wrongly signaled when it should not be
<Wizzup> btw, the pvr headers we want in kernel, I think all we need to do is to make sure they are considered to be headers to export in the kernel build system itself
<Wizzup> so probably we should not modify the debian packaging but rather the kernel build system
<freemangordon> so, we'll need kernel-headers package to build ddx?
<Wizzup> yes that seems the most sensible solution to me if you want them from the kernel specifically
<freemangordon> ok
<Wizzup> btw, if you can test briefly, does mesa complain if you remove the libllvm8 pkg you installed from backports earlier?
<Wizzup> the one from repos might not need it
<bencoh> Wizzup: ha, so I'm not the only one suffering from droid4-linux? :D
<Wizzup> insanely
<Wizzup> It just works sometimes with various incantations of git clean -fd and other stuff
<bencoh> regarding llvm8, I think I'm missing something ... I don't recall fetching a newer llvm package and it still passed the tests in my lxc container
<Wizzup> yes so it could be that I had it when I build mesa and it just used that
<Wizzup> the CI might not need/depend on it
<Wizzup> I built in the CI a few hours ago
<bencoh> nd it failed?
<Wizzup> there seem to be a lot of droid 4 listings on ebay now
<Wizzup> bencoh: no the CI went fine
<bencoh> ah
<Wizzup> bencoh: we just need tdo check if we still need libllvm8 or not
<bencoh> alright
<bencoh> (moar d4)
<Wizzup> not that many
<Wizzup> I wonder if it's because we asked about it somehow
<Wizzup> they know to ask for more now it seems
<Wizzup> seems to be from the same guy
<Wizzup> ships from germany
<Wizzup> rr italy
<Wizzup> some of them say usb port defect hehe
<freemangordon> bencoh: do you have any knowledge on dmabuf fences?
<Wizzup> calebtheythem[m]: if you search for "motorola photon q" on ebay now there are about 6 phones for 30 usd each, they charge but 'do not turn on' according to the seller
<Wizzup> calebtheythem[m]: more like 10 it looks like
panzeroceania has joined #maemo-leste
nohit has joined #maemo-leste
<Wizzup> bencoh: looks like the CI happily pulls from backports: Get: 11 http://pkgmaster.devuan.org/merged beowulf-backports/main armhf libllvm8 armhf 1:8.0.1-3~bpo10+1 [12.0 MB]
<Wizzup> freemangordon: ok, I think I know how to add kernel headers
<Wizzup> so maybe they are already in there
<Wizzup> (building atm)
<freemangordon> ok, lets see
<Wizzup> will take ~1-2 hrs I tihnk
<freemangordon> heh
<lel> norayr opened an issue: https://github.com/maemo-leste/bugtracker/issues/586 (osso-xterm selects, instead of scrolling in portrait mode.)
Wikiwide_ has joined #maemo-leste
Wikiwide_ is now known as Wikiwide
Twig has quit [Ping timeout: 264 seconds]
freemangordon has quit [Ping timeout: 240 seconds]
freemangordon has joined #maemo-leste
Pali has quit [Ping timeout: 256 seconds]
elastic_dog has quit [Read error: Connection reset by peer]
elastic_dog has joined #maemo-leste