<Wizzup>
uvos: maybe look at the syncevolution stuff
<Wizzup>
not sure if it helps somehow
<uvos>
Wizzup: i think the syncevolution ui is what broke my setup like this
<uvos>
Wizzup: buy yeah we should fix it
<Wizzup>
what do you mean broke your setup
<uvos>
it added a bounch of stores
<uvos>
that dont work
<uvos>
and made them default i think
<uvos>
since i tried to use it several times before setting up evolution by hand
<uvos>
and it crashes out when you do that before finishing
<Wizzup>
weird, I did not have problems with syncevo and it did seem to sync the right rhings
<uvos>
you also setup the stores by hand
<Wizzup>
maybe you need more osso-abook support
<uvos>
and then just used syncevo ui to sync
<uvos>
osso-abook has exatcly the same problem on my device
<uvos>
(as it allso uses the default address book)
<uvos>
(as provided by evolution)
xmn has joined #maemo-leste
<Wizzup>
uvos: upgrading to latest sphone now :)
<Wizzup>
yeah so the contacts button doesn't do anything for me, but I don't think I tried to sync contacts yet
<Wizzup>
I could actually sync my fremantle contacts to this leste d4 using syncevo
<uvos>
it should not, that button just pushes to a datapipe thats supposed to open the contact in an external application (or implement a window itself). i have a tiny module that opens gnome-contacts, but there is nothing else behind there atm
<uvos>
the evolution contacts support is about displaying the right name etc
<uvos>
when a call comes in and sutch
<Wizzup>
aha
<Wizzup>
check
<uvos>
basicly this is placeholder for abook
<uvos>
on maemo
<Wizzup>
ok
<uvos>
upps
<uvos>
it built without contacts-evolution support on jenkins
<uvos>
sec
<Wizzup>
random note: if we turn on keyboard leds, let's also turn on ts buttons leds
<Wizzup>
(for als purposes)
<sicelo>
I think both you and I disabled that. Wasn't it that way before? :-)
<Wizzup>
hm, maybe yeah
<Wizzup>
or maybe before we had ts buttons
<Wizzup>
where it made less sense
<sicelo>
At least I found it distracting, and iirc I disabled it on my local install
<uvos>
Wizzup: yeah basicly it works that way by default in mce
<Wizzup>
oh
<Wizzup>
heh
<uvos>
there are some brigness values where the ts-buttons will be off but the kbd on
<uvos>
thats down to the fact that the ts-buttons are 1 bit
<uvos>
and the kbd is 8bit
<Wizzup>
I think I managed to send myself a zero char sms via sphone by accidenet
<uvos>
so mce can dim the kbd
<Wizzup>
then the window didn't really work anymore
<uvos>
but has to choose on or off for tsbuttons
<Wizzup>
doesn't really matter, just ran into it
<uvos>
Wizzup: hmm ok
<Wizzup>
right @ 1bit
<Wizzup>
uvos: I did receive the sms hehe
<Wizzup>
I regularly send myself smses to kick the modem for data connections
<uvos>
ok yeah the old backend might have stopped you from sending whithout text
<uvos>
so you want it to stay? i think its maybe not so great for most users.
<Wizzup>
it's not so great, but I plan to use the non existent conversations stuff
<Wizzup>
so it was more like a 'do not bother fixing it for me'
<uvos>
anyhow im rebuilding sphone hopfully with evolution module being built too
<uvos>
Hildon support enabled
<uvos>
Profiled support enabled
<uvos>
GStreamer support enabled
<uvos>
Pulseaudio support enabled
<uvos>
Evolution address book support enabled
<uvos>
looks like it worked now
<uvos>
ok so sphone in repos should be ok now
<Wizzup>
will update
<uvos>
i dident update the version number
<uvos>
so you have to reinstall
<Wizzup>
I think it would be nice to give it the x-maemo-icon and stuff, then ham will also show it
<Wizzup>
ow
<Wizzup>
I think we auto bump the epoch no?
<uvos>
no idea
<uvos>
i do we?
<Wizzup>
yup
<uvos>
mhh
<uvos>
ok
<Wizzup>
apt upgrade pulls it
<uvos>
wrt x-maemo-icon
<uvos>
its not in extras
<uvos>
so that wont work
<uvos>
also surely the intention is to have it in the metapackage as soon as n900 stops crashing with it
<Wizzup>
I think it should still work
<Wizzup>
for update purposes
<Wizzup>
as in, I do not think only happens for -extras
<Wizzup>
as far as ham knows it is just another repo
<uvos>
i thought it only read from hildon-application-manager.list
<Wizzup>
contacts button still does not open anything but I might not have the evo ui installed
<uvos>
thats correct behavior as mentioned before
<uvos>
there is no module that provides contactui in mainline sphone
<uvos>
atm
<uvos>
there is also no sutch thing as evo ui:P
SystemError has quit [Ping timeout: 276 seconds]
<Wizzup>
ah check
belcher has quit [Quit: Leaving]
Langoor has joined #maemo-leste
Langoor has quit [Changing host]
xmn has quit [Ping timeout: 260 seconds]
_inky has quit [Ping timeout: 260 seconds]
inky has joined #maemo-leste
inky_ has quit [Ping timeout: 260 seconds]
<freemangordon>
uvos: well, I was *expecting* ms to have back buffer
<freemangordon>
but, obviously it doesnt
_inky has joined #maemo-leste
<freemangordon>
so, those 'repeating frames' in the video are because of something else
<uvos>
yeah
<uvos>
but it tearing is no supprise
<freemangordon>
actually h-d scrolling does not tear
<freemangordon>
on fremantle it does
<uvos>
(altho with cm-mode display you could avoid taring by only updating it when your done with the front buffer)
<freemangordon>
but, it suffers from the same "frame repeat"
<uvos>
effectively using the display as the front bufer
<uvos>
what freemantle?
<freemangordon>
no
<uvos>
ok
<freemangordon>
on fremantle there is tearing
<uvos>
right
<freemangordon>
but no "frame repeat"
<uvos>
right
<freemangordon>
on 1.17 there is no tearing
<freemangordon>
as far as I can see
<uvos>
you should not expect tearing in compositing wm
<uvos>
if it vsyncs its gl buffers
<uvos>
anyhow
<uvos>
is there some other gles 2 compositing wm
<uvos>
?
<uvos>
to eleminate clutter/hildon having a bug
<uvos>
(tho i still mostly suspect the kernel)
<uvos>
looks like kwin has gles support
<freemangordon>
mutter?
<uvos>
no idea
<freemangordon>
yep, it uses clutter
<freemangordon>
but maybe it is no longer available
<freemangordon>
I wonder if it makes sense to RE the missing parts from pvr_dri
<uvos>
well we would want something that _dosent_ use clutter
<Wizzup>
freemangordon: could it be the flush behaviour you set to 2 somehow/
<freemangordon>
it will use clutter 1 anyways
<freemangordon>
Wizzup: I tried with different settngs for that, makes no difference
<Wizzup>
ok
<freemangordon>
actually this flush behavior tells PRV blobs what to do on glFlush()/glFinish()
<freemangordon>
by default they do nothing ;)
<uvos>
freemangordon: so do twm or x with built in wm have issuse on gles surfaces created by clients
<uvos>
?
<freemangordon>
lemme try twm
<freemangordon>
oh, I have to do that on n900 :(
<freemangordon>
btw, pvr-dri in blobs reports egl 1.5, chromeos 1.4
<uvos>
would make some sense if chromeos is based on older tree then ti blobs
<freemangordon>
mhm
<freemangordon>
for sure it is
<freemangordon>
there are differences in the code
<freemangordon>
that's why I think I shall RE the missing stuff
<freemangordon>
that way we will have working clmark on d4
<freemangordon>
*glmark
<freemangordon>
twm: unable to open fontset "-adobe-helvetica-bold-r-normal--*-120-*-*-*-*-*-*"
<freemangordon>
:(
<Wizzup>
compton can make things compositing
<uvos>
on gles?
<Wizzup>
oh, yeah..
<uvos>
i dont think there is any modern gles 2 compositing wm besides kwin
<uvos>
(from googling around the last couple of min(
<freemangordon>
running es2gears on d4 with twm, hxorg hangs as soon as I try to move the window
<uvos>
hmm :(
<freemangordon>
hangs == uses 100% cpu and is not responding
<freemangordon>
last frame in gdb is:
<freemangordon>
#3 0xb5bf0fbc in ?? () from /usr/lib/arm-linux-gnueabihf/libsrv_um.so.1
<freemangordon>
let me try on n900
<freemangordon>
same happens with closed blobs, on both d4 and n900
<uvos>
weeee bugs
<uvos>
dose the calls stack involve deleating or creating surfaces by anny chance?
<freemangordon>
I doubt, but I can check waht is the last call in 'my' ddx
<freemangordon>
well, in glamor replacement
<freemangordon>
ok, when I use 'slow path' to copy PRESENT textures, Xorg does not hang
<freemangordon>
with twm when moving es2gears that is
inky_ has joined #maemo-leste
inky has quit [Ping timeout: 260 seconds]
pere has quit [Ping timeout: 260 seconds]
<tmlind>
i've seen few small gray squares not getting updated still, much smaller than earlier and rarer
pere has joined #maemo-leste
lyubov has quit [Quit: WeeChat 3.0]
lyubov has joined #maemo-leste
elastic_dog has quit [Ping timeout: 264 seconds]
lyubov has quit [Quit: WeeChat 3.0]
lyubov has joined #maemo-leste
peetah has quit [Quit: -]
peetah has joined #maemo-leste
<freemangordon>
uvos: after all, it is modesetting driver causing those repeating frames, after disabling PageFlip it looks fine
<freemangordon>
I have to understand what this option is supposed to do
<freemangordon>
also, any hint how to fix font sizes?
<uvos>
freemangordon: pageflip was added for vrr
<uvos>
freemangordon: it changes the way x waits for vsync
<uvos>
i dont know how really
<uvos>
wrt font sizes
<uvos>
you need to break the dpi setting again
<uvos>
x as a commandline option for dpi
<uvos>
or you can override the size of the display
<freemangordon>
96x96?
<uvos>
yes
<freemangordon>
ok, thanks
<uvos>
esaiest way is to add DisplaySize to Section "Monitor" in xorg.conf
<uvos>
just caluclate what size the display would be at 96dpi
<uvos>
droid 4 would be 250 x 140mm
<freemangordon>
ok
<uvos>
so page flip not working suggests something is wrong in omapdrm
<uvos>
btw
elastic_dog has joined #maemo-leste
<uvos>
since this is all about adding a new path that was added to drm at a later iirc
<uvos>
*later date
<freemangordon>
not sure, because I am still to understand what exactly it tries to flip
<uvos>
ok
<uvos>
if the "legacy" path works
<uvos>
i would ignore this for now and work on the other bugs
<uvos>
unless you belive it intersects ofc
<freemangordon>
it lowers the performance for fulscreen applications it seems
<freemangordon>
though, I am not sure
<freemangordon>
but yeah, I am goingt o ignore this for now
<freemangordon>
I have another low-hanging fruit first, in terms of performance - 16 bpp
<uvos>
16 bpp will likely never be viable
<uvos>
i know you like it
<freemangordon>
Xorg starts and everything besides hildon-desktop works fine
<uvos>
but i belive its a waste of time
<uvos>
yeah but lots of x applications just assume 32bit
<freemangordon>
not in fremantle :p
<uvos>
and all they have as a fallback is converting 32bit to 16 to output the surface to x
<uvos>
so that absolutly kills perf
<freemangordon>
but, we have FPS doubling for 3d
<freemangordon>
have to cook, ttyl
<uvos>
ttyl
<bencoh>
fps doubling? what the heck
<uvos>
bencoh: well on ddk1.9 gears runs at 25fps
<bencoh>
ah, I see
<uvos>
fps doubling just means running ok :P
<bencoh>
nevermind :)
inky_ has quit [Ping timeout: 260 seconds]
_inky has quit [Ping timeout: 245 seconds]
<uvos>
yeah its on ddk1.9 its 26fps with hildon running and 50 without and 28 on llvmpipe :P
<uvos>
also dosent matter if you run gears or if you run something like neverball
<uvos>
everything gets the same fps
<uvos>
(ie its not related to render complexity its just how fast the cpu can copy the buffer to display in sw)
_inky has joined #maemo-leste
<Wizzup>
freemangordon: so if this is solved, the weird reverts, and the x11pers problems do not show in h-d, that's quite an achievement
<Wizzup>
x11perf
Danct12 has quit [Ping timeout: 260 seconds]
<freemangordon>
uvos: this is on d4?
<freemangordon>
Wizzup: yeah, seems x11perf problems are solved when it runs in h-d
<freemangordon>
but performance is low
<uvos>
freemangordon: YES
<freemangordon>
oh, that's nasty
<freemangordon>
something has to be fixed on d4, as h-d doesn;t render
<Wizzup>
freemangordon: how low?
<Wizzup>
oh
<uvos>
maybe because you disabled xorgs vrr support? try with hdmi...
<freemangordon>
on N900:
<freemangordon>
x11perf -comppixwin500:
<freemangordon>
120 reps @ 44.8331 msec ( 22.3/sec): Composite 500x500 from pixmap to window
<freemangordon>
gtkperf, n900:
<freemangordon>
Total time: 185.47
<freemangordon>
this is with every pixmap backed by a mmap-ed BO
Danct12 has joined #maemo-leste
<freemangordon>
and without any PVR 2D rendering
<Wizzup>
ok
<Wizzup>
I mean, it doesn't sound too bad, right?
* Wizzup
needs to find the old perf numbers
<freemangordon>
uvos: no matter what I do, h-d does not render on d4
<freemangordon>
but I suspect pvr_dri
<Wizzup>
is this a new problem?
<freemangordon>
no
<Wizzup>
ok
<freemangordon>
I mean - not from today :)
<Wizzup>
right
<Wizzup>
yeah I was asking when/if you recalled it working on ddk 1.17
<Wizzup>
meanwhile, I got to a place in sofia, and I need to find some food before things close
<freemangordon>
I don;t think it ever worked, because we didn;t have support for x11 in blobs
<Wizzup>
ok
<freemangordon>
and my shim is still missing some functions needed by glmar/h-d to run
<freemangordon>
also, I don;t think I should invest more time in shim, no?
<freemangordon>
I'd rather fix chromeos mesa
<Wizzup>
probably makes sense yeah, but I don't know I know enough to give an informed opinion
Danct12 has quit [Quit: Quitting]
Danct12 has joined #maemo-leste
<freemangordon>
well, no matter how good my shim is, it will never be as good as native support in mesa
<Wizzup>
agreed
<freemangordon>
the situation was desperate back then, that's why I started writing it
<Wizzup>
freemangordon: does it make sense for me to look at if we can package this for n900?
<freemangordon>
too early I guess
<freemangordon>
lets have something that works most of the time
<tmlind>
freemangordon: +1 for fixing the chromeos mesa
<freemangordon>
yeah, I am on it
<freemangordon>
hmm, seems blobg provide GL support too
<freemangordon>
*blobs
<tmlind>
so i'm getting PVR:(Error): PVRDisplayBufferCreate: Failed to create display buffer (err=13) [0, ] but can't find where PVRDisplayBufferCreate is
<tmlind>
not in mesa, not in blobs, not in kernel.. is that some generated name for PVRDisplayBufferCreate?
<freemangordon>
it should be in pvr_dri
<tmlind>
should
<freemangordon>
sec, my d4 needs some time to boot, I'll verify in a minute
<tmlind>
ah it is
<freemangordon>
no, it is not :)
<freemangordon>
at least not in the source code
<freemangordon>
tmlind: PVRDRIBufferCreate is imported by pvr_dri
<freemangordon>
maybe it is exported by libpvr_dri_support.so
<tmlind>
ok
Twig has joined #maemo-leste
<freemangordon>
oh, pvr_dri in blobs has mutex per drawable, this one is missing in chomeos mesa
<freemangordon>
hmm, actually it seems chromeos mesa pvr to be newer than the one in the blobs
<uvos>
idk where it comes from
<uvos>
(well the google repo)
<uvos>
but i mean what chome device
<uvos>
maybe we can get the newer blobs somewhere to examine?
<uvos>
they likely will be for the wrong core revision so we cant use them
<uvos>
bus still
<uvos>
looks like modern (ish) chomeos devices with pvr are MTK devices
<uvos>
that makes sense i dont think imtek has any customers left except mtk and sort of apple at least large scale