<Wizzup>
I don't know what the purpose of LEASE_PARAMS is there
<uvos>
impoverish the american middle class
<Wizzup>
uvos: huh? :p
<uvos>
was a joke, aperantly not a great one: the steriotype being that broke americans who get a decent job immidatly impoverish themselves again by leasing a mustang or somth. at terrible contractual conditions.
<uvos>
*stereotype
<Wizzup>
ah
<Wizzup>
yeah I figured it was a lease joke
<Wizzup>
hehe
<Wizzup>
anyway I think this resolv/dns problem is resolved
<uvos>
yay
<Wizzup>
I rely on sphone all the time for my 3g connections hehe
<Wizzup>
(I send myself a sms when I start activating the interface to make sure ofono wakes up)
<uvos>
oof
<uvos>
yeah ofono issues are another pressing concern
<uvos>
the interfaces sphone needs all work very well at least
<uvos>
i have never seen it not ring
<Wizzup>
yeah I think it's probably a relatively minor tweak
<Wizzup>
it could just be a matter of adding some g_at_chat_register to motorola_sms_probe
<Wizzup>
i.e. "kick" things
<Wizzup>
^^ above is not correct I think
<Wizzup>
as in it's ot the g_at_chat_register that's required
<Wizzup>
otherwise it wouldn't miss the sim changes I think
<Wizzup>
what I find surprising is the CIEV messages (set to 5,1,0 or something) when internet is being activated
<Wizzup>
maybe voicecall.c catched that and doesn't kick or something
<uvos>
but if i report on a different pin that dose exist like Headphone Jack
<uvos>
it dosent work
<uvos>
its just not reported to userspace
<uvos>
which is wierd
<uvos>
so yeah the patches are def wip
<uvos>
but they do work fine
<uvos>
this is related to how headset_jack_pins is defined
<uvos>
see sound/soc/codecs/cpcap.c
<uvos>
not sure why reporting on an existing widget dosent work
<uvos>
maybe ^^^ tmlind knows
<freemangordon>
Wizzup: one more functionm remaining, from blob pvr_dri
<uvos>
freemangordon: so your reing the differences from the blob into chomeos source?
<freemangordon>
yes
<freemangordon>
though it is more like total RE
<freemangordon>
but yeah
<freemangordon>
hopefully with that glmark will no longer hand and we'll have the correct x11 support
<freemangordon>
*hang
pere has joined #maemo-leste
<freemangordon>
kmscube works :D
<freemangordon>
so is glmark2 :)
<freemangordon>
ok, will clean-up the code a bit and will push
<uvos>
what remaining problem exist then?
<uvos>
xorg resize/move stil hangs?
<uvos>
what else?
<freemangordon>
no idea, I havent' tested with this pvr_dri
<uvos>
ok
<freemangordon>
I mean - I just made the very first test with it (kmscube and glmark)
inky has joined #maemo-leste
inky_ has quit [Ping timeout: 268 seconds]
sunshavi has joined #maemo-leste
<Wizzup>
freemangordon: nice work!
<tmlind>
freemangordon: nice job :)
<tmlind>
uvos: good to see the headset interrupt handler :)
<tmlind>
uvos: please check your patches with checkpatch.pl --strict to avoid pointless trivial comment noise on the mailing lists ;)
<tmlind>
uvos: then after -rc1, please send the asoc patches to the asoc list, morimoto san probably will provide comments and help to get the issue fixed
<uvos>
tmlind: im not going to try merging this yet
<uvos>
tmlind: see the issues wrt the affect dapm pin
<tmlind>
uvos: hmm let me check
<uvos>
also really
<uvos>
i dont know if the changes to graph-card are proper
<uvos>
i mean i call set_jack with NULL for user data
<uvos>
no idea if some codec that can be used either with graph-card or some sepical driver
<uvos>
wont strongly dislike the driver specific parameter being NULL
<uvos>
if so i dont see any way other than to fork graph-card/wirte a new cpcap driver
<uvos>
which is preferable anyhow
<uvos>
so not sure if it makes sense to try and upstream this, rather than just keeping it as a leste specific patch until the cpcap audio situation can be overhauled by granting mapphones a own driver
<tmlind>
uvos: well the good news is all the issues i had with the graph-card got promtly fixed after sending an attempted fix
<tmlind>
uvos: so yeah i think your patch is ok to send to discuss it on the lists for sure
<tmlind>
s/promtly/promptly/
<tmlind>
uvos: not sure how else to handle the dapm pin, either a gpio or device specific call is needed depending on the hardware
<uvos>
tmlind: hmm?
<uvos>
so snd_soc_jack reports a incomeing snd_soc_jack_report on a specific widget
<uvos>
you can see this in amixer -c0 controles
<uvos>
i can go and report on any widget i like
<tmlind>
uvos: but it currently expects a gpio right? and there are cases where it's not a gpio
<uvos>
no this is something else
<tmlind>
ok
<uvos>
currtently i report on the Headset Right Playback Route and Headset Left Playback Route and Headphones widget
<uvos>
this means that userspace gets a signal
<uvos>
that this widget has become available/unavailable when SND_JACK_HEADPHONE is reported through snd_soc_jack_report
<uvos>
the Headphones dosent really exist
<uvos>
so i get a warning
<uvos>
but only this widget really causes userspace to react
<uvos>
(ie pa/ alsa userspace)
<uvos>
not sure why
<tmlind>
no idea :)
<tmlind>
Wizzup: the voice call audio routing has issues where the linux driver has no clue whatsoever right now what's going beyond the hacked in set_tdm_slot function
<tmlind>
the solution there (and a nice project for somebody into patching linux audio stuff) is to make the cpcap voice call codec driver a child devices of the cpcap or cpcap audio codec instead of being a child of the mcbsp device
<tmlind>
then the voice call codec driver can communicate with the cpcap audio codec driver with set_tdm_slot etc
<tmlind>
freemangordon: so seems like with wayland the path is something like libmesa_dri_drivers.so -> libpvr_dri_support.so -> libsrv_um.so -> libdbm.so -> kernel dri, no pvr_dri involved there?
<freemangordon>
pvr_dri is a symlink to libmesa_dri_drivers.so ;)
<tmlind>
ah ok :)
inky has quit [Ping timeout: 245 seconds]
<freemangordon>
what do you think - shall I crate a commit on top of current uvos' mesa or shall I crate a new branch and add everything from scratch?
<freemangordon>
or maybe squash to a single commit?
<tmlind>
well uvos's branch is based on some imported patches too? i guess we have no commit from the chromeos guys?
<freemangordon>
yeah, we have no commit from them
<freemangordon>
ok, I'll squash everything to s single commit
<tmlind>
i'd do the patches against what jonathan bakker applied then if possible, maybe uvos used that as a base too
<freemangordon>
yes, this is what I made the changes against, however the change is so big I doubt it will be of any use as a commit on top
<uvos>
yes i just merged our mesa (ie debain/) with bakker
<uvos>
so really makes no difference
<tmlind>
maybe pick whatever makes most sense from git diff point of view :)
<freemangordon>
ok, I'll do another branch and will squash jonathan bakker commits with mine, to a single commit
<freemangordon>
glmark2 Score: 62
<uvos>
vsync?
<freemangordon>
yeah
<freemangordon>
this is on d4
<freemangordon>
most of the tests afre with fps of 82
<tmlind>
nice, 62 is very close to 63 i seem to have reported earlier with wayland
<freemangordon>
this is -drm tough
<tmlind>
terrain is the slowest for sure, something like 2fps right now :)
<freemangordon>
1fps here :)
<freemangordon>
but yeah
<freemangordon>
oh, I have to beutify one function before that
<freemangordon>
it is full of labels and gotos ATM
<tmlind>
hmm so why do you want to squash this with jonathan's changes? just add one or more patches on top?
<freemangordon>
also, x11 does not work with this pvr_dri
<uvos>
:(
<tmlind>
heh
<freemangordon>
that's to be expected
<freemangordon>
I mean - Xorg starts
<uvos>
?
<freemangordon>
but es2gears (for example) complains:
<freemangordon>
PVRImageDrawableGetNativeInfo: Image get buffers call failed
<freemangordon>
it could be a bug I introduced, btu, we have a working code for reference, not much of an issue
<uvos>
ok why is its behvior worse than chomeos pvr_dri
<uvos>
ok bug
<uvos>
ok
<freemangordon>
or, missing code
<freemangordon>
chromeos code somehow works, I will have to understand how
<freemangordon>
again, not a biggie, I will fix that
<freemangordon>
tmlind: oh, ok, but trust me, this commit will be huge nad more or less useless (in terms of history)
<freemangordon>
but ok
<uvos>
how different is your pvr_dri from chomeos now anyways
<uvos>
i gues i can see for myself wen you push it..
<freemangordon>
very
<freemangordon>
I mean - almost everyting is different
<freemangordon>
this meson/ninja/whatever is so stupid that it spins full rebuild on a simple configuration change in one of the subdirs :(
<Wizzup>
but... but... progress!
<freemangordon>
yeah
<freemangordon>
progree
<freemangordon>
*progress
lexik_ has quit [Read error: Connection reset by peer]
lexik has joined #maemo-leste
Wizzup has quit [Ping timeout: 244 seconds]
Wizzup has joined #maemo-leste
<Wizzup>
parazyd: want to try to libicd-network-ipv4 PR?
<Wizzup>
I tested it on wifi and it works well, gprs had some trouble I don't think that was related to the patch, but rather something in libicd-network-ofono, so no regression there
<Wizzup>
wireguard switching works as expected, and all the interface files are gone
<freemangordon>
I mean: it should be /usr/lib/arm-linux-gnueabihf/dri/pvr_dri.so
<tmlind>
musl
<freemangordon>
hmm?
<uvos>
arm-linux-musleabihf
<uvos>
i presume
<freemangordon>
well, yeah
_inky has joined #maemo-leste
<tmlind>
nah, just /usr/lib here
<freemangordon>
well /usr/lib/dri then
<freemangordon>
but make sure you dont have more blobs than needed :)
<uvos>
yeah
<tmlind>
yeah maybe i have some extra blob somewhere
mardy has quit [Quit: WeeChat 2.8]
<tmlind>
pvr_dri.so is in /usr/lib/xorg/modules/dri as configured, no extra one in /usr/lib/dri
<tmlind>
hmm
<uvos>
/usr/lib/xorg/modules/dri sounds very wrong
<freemangordon>
it should not be there
<uvos>
xorg dri is a thing but its mostly unrelated to this kind of dri
<tmlind>
just using what the distro config options
<freemangordon>
tmlind: maybe strace to see if the corrce lib is being loaded
<freemangordon>
*correct
<tmlind>
yeah will figure it out
<tmlind>
i guess no extra config options got added that needs meson --reconfigure or something?
<freemangordon>
no
<freemangordon>
only one more file was added in pvr directory
<uvos>
[5/753]
<uvos>
here we go
<freemangordon>
:)
<tmlind>
it's only a flesh wound :)
<uvos>
hopefully me disableing everything not needed for the pvr classic mesa driver is enough
<uvos>
to get a resonable time
<uvos>
btw classic mesa driver support (ie pvr_dir) is going away
<uvos>
so this stuff will only work with upstream mesa for a litte while longer
<tmlind>
weird so strace -o /tmp/glmark.log glmark2-es2-drm runs fine for me
<uvos>
thats the heisenbug the chomeos pvr_dir had
<freemangordon>
that means you;re loading chromeos pvr_dri from somewhere
<freemangordon>
tmlind: which branch did you compile?
<uvos>
clearly yours
<uvos>
since he had the errors
<freemangordon>
right
<freemangordon>
:)
<tmlind>
so strace shows open("/usr/lib/libpvr_dri_support.so", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 4
<freemangordon>
but there are some chromeos remnants still
<uvos>
[250/753]
<freemangordon>
tmlind: did you copy 'my' pvr_dri to /usr/lib/dri?
<freemangordon>
no, libpvr_dri_support.so is fine
<freemangordon>
this is opened by pvr_dri.so
<freemangordon>
the question is which pvr_dri.so gets opened
<tmlind>
oh right
<tmlind>
not seeing pvr_dri.so in strace output at all
<freemangordon>
that's strange
<freemangordon>
keep in mind it is dload()-ed
<freemangordon>
not linked
<tmlind>
hmm i did grep open /tmp/glmark.log
<freemangordon>
maybe run from gdb and pu a breakpoint in PVRDRIInitScreen
<freemangordon>
*put
<tmlind>
hmm does not run in gdb while it runs with strace, need to continue debugging sunday night earliest most likely
<freemangordon>
but, you can break in gdb and do 'info shared'
<tmlind>
ok just a sec
<tmlind>
seems to use the correct /usr/lib/xorg/modules/dri/omapdrm_dri.so
<freemangordon>
thid is not the correct module
<freemangordon>
*this
<freemangordon>
try with 'export MESA_LOADER_DRIVER_OVERRIDE=pvr'
<tmlind>
ah sorry getting tired
<tmlind>
ok
<tmlind>
ok now /usr/lib/xorg/modules/dri/pvr_dri.so
<freemangordon>
and? does it work?
<tmlind>
yes with that export it now works :) but why is that now needed?
<freemangordon>
no idea, but somehow mesa is unable to load the correctr dri driver
<tmlind>
weird
<tmlind>
maybe some version check for preference?
<freemangordon>
will have to investigate but that's of low prio TBH
<freemangordon>
have to fix the resource leak first :)
sunshavi has joined #maemo-leste
<uvos>
glmark2 Score: 72
<uvos>
(this is android)
<uvos>
(ddk1.9)
<tmlind>
fyi no luck with starting sway here with that export, sgx is found but complains about some dmabuf stuff
<freemangordon>
well, I removed some not supported stuff, maybe I shaved too much
<freemangordon>
will need steps to repro, to see what is missing
<uvos>
android results are interesing
<uvos>
some stuff is slower
<uvos>
some stuff is way faster
<uvos>
wierd
<uvos>
gets 28 fps on desktop with blur
<tmlind>
freemangordon: looks like the error with wlroots and sway is [wlr] [render/egl.c:718] Failed to query number of dmabuf formats, needs to check that it works with my old branch i guess
<freemangordon>
hmm, yeah
<freemangordon>
could I have removed more than have to
<tmlind>
anyways nice to see that at least glmrk2-es2-drm now finally works :)
<freemangordon>
keep in mind I reverted "egl_dri2: Don't expose EXT_image_dma_buf_import_modifiers" patch
<tmlind>
i guess i should try that with my old branch (jonathan's stuff) with the export
<freemangordon>
could be related
<tmlind>
i think i have that reverted too
<tmlind>
i also had few experimental backports from upstream mesa while debugging the render node usage issues with wlroots
<tmlind>
ah right no, jonathan added that because of wlroots, let me try adding it back
<tmlind>
yup with that added back sway now also works for me :)
<freemangordon>
:)
<freemangordon>
I only need to fix that memleak and we're fine
<tmlind>
looks like glmark2-es2-wayland no longer causes sgx oops, but a segfault now
<freemangordon>
heh
<freemangordon>
that's better, no?
<tmlind>
sure
<tmlind>
(gdb)
<tmlind>
#0 0xb6ef322e in wl_proxy_add_listener () from /usr/lib/libwayland-client.so.0
<tmlind>
#1 0xb6d27502 in wl_buffer_add_listener (data=0xb6d50840, listener=0xb6d44358 <wl_buffer_listener>, wl_buffer=<optimized out>) at /usr/include/wayland-client-protocol.h:1943
<tmlind>
#2 dri2_wl_swap_buffers_with_damage (disp=0xb6d4ece0, draw=0xb6d50840, rects=0x0, n_rects=0) at ../src/egl/drivers/dri2/platform_wayland.c:1105
<tmlind>
#3 0xb6d20304 in dri2_swap_buffers (disp=0xb6d4ece0, surf=0xb6d50840) at ../src/egl/drivers/dri2/egl_dri2.c:2001
<tmlind>
#4 0xb6d1888a in eglSwapBuffers (dpy=0xb6d4ece0, surface=<optimized out>) at ../src/egl/main/eglapi.c:1341
<freemangordon>
you should install debug symbols for /usr/lib/libwayland-client.so.0
<tmlind>
yeh will do that when i get a chance, early wakeup coming, ttyl
<freemangordon>
ttyl
<uvos>
wierd my build dident make pvr_dir.so at all
<uvos>
configure shows dri-drivers [pvr]
<uvos>
hmm
<uvos>
anyhow gn8
<freemangordon>
yes, it doesn;t
<freemangordon>
it does one huge so called mesa_drivers_something.so
<uvos>
oh ok
<uvos>
do builing it via dpkg-buildpackage must use other options
<freemangordon>
libmesa_dri_drivers.so
<uvos>
that builds the drivers seperate
<freemangordon>
you should rename that to pvr_dri.so
<freemangordon>
and copy it
<freemangordon>
hmm, somehow I fixed the memory leak :)
<freemangordon>
and xorg glmark now runs fine :)
<freemangordon>
glmark2 Score: 81
sunshavi has quit [Ping timeout: 268 seconds]
<uvos>
ok i can confirm glmark -drm works now
<freemangordon>
this score ^^^ is from glmark xorg
<uvos>
thats nuts
<uvos>
that exceeds android
<freemangordon>
drm shows less because of vsync
<freemangordon>
no java here ;)
<uvos>
wel glmark is a ndk application
<uvos>
but yeah newer drivers too
<freemangordon>
let me see what will be the result with --fullscreen
<uvos>
whait how big was that frame?
<uvos>
android result is fs ofc
<freemangordon>
default :)
<uvos>
ok android glmark can only do fullscreen
<freemangordon>
no idea what glmark/xorg use for default
<freemangordon>
it is slower on fullscreen
uvos has quit [Quit: Konversation terminated!]
inky has joined #maemo-leste
<freemangordon>
fullscreen glmark2 Score: 73
<freemangordon>
still more than android
<sicelo>
have you had a chance to check it out on N900? what's the performance like there?
<freemangordon>
no, will do tomorrow
<freemangordon>
but I expect similar results
<freemangordon>
I mean - not 73 ofc
<freemangordon>
but something like 40-45
<freemangordon>
too late here
<sicelo>
i really appreciate your work
<freemangordon>
:)
<freemangordon>
anyway, going to have some sleep
<freemangordon>
night!
<sicelo>
\o
Danct12 has quit [Remote host closed the connection]