DPA has quit [Quit: ZNC 1.8.2+deb2~bpo10+1 - https://znc.in]
DPA has joined #maemo-leste
DPA has quit [Client Quit]
DPA has joined #maemo-leste
xmn has quit [Ping timeout: 268 seconds]
cockroach has quit [Quit: leaving]
<mighty17[m]>
<uvos> "mighty17: wrt what works and..." <- Still the same, just fixed accl and added vibrator, display/bl issue still exist, and I don't know how to do audio
ikmaak has quit [Ping timeout: 268 seconds]
ikmaak has joined #maemo-leste
System_Error has joined #maemo-leste
System_Error has quit [Remote host closed the connection]
<freemangordon>
but here it becomes tricky, as there are 12 VRFB contexts max
<freemangordon>
so, I am not sure what is the correct time for attaching VRFB to FB
<freemangordon>
maybe only when rotation is requested
<Wizzup>
uvos: I see /dev/input/event7:Mapphone Audio Headphones - but I don't get plug events on it it seems
<freemangordon>
otherwise we may run out of contexts very quickly
<Wizzup>
freemangordon: hm, is this for a while fb or what?
<Wizzup>
whole*
<freemangordon>
also, it seems there is an issue with the rotation - IIUC, somehow PVR should see the rotated address
<freemangordon>
yes, the whole FB gets rotated
<Wizzup>
uvos: oh but pulse does pick it up
<freemangordon>
but, this makes sense
<freemangordon>
unless I don;t understand the question
<Wizzup>
freemangordon: well if we have 12, how many full framebuffers in rotation do we need active?
<Wizzup>
but really I'm just asking randomly
<freemangordon>
1, but we don;t know in advance which exactly one ;)
<Wizzup>
hm, ok, I don't know much about vrfb
<freemangordon>
it is simple
<freemangordon>
it basically provides you with for addresses to access one and the same memory block
<freemangordon>
s/for/four
<freemangordon>
for 0/90/270/360 degress rotation
<freemangordon>
*degrees
<freemangordon>
look into trm, it is well explained
<Wizzup>
ok
<freemangordon>
the point is that the resource is limited to 12 contexts (context defines image memory, size and rotation)
<freemangordon>
but, I don;t know how is that supposed to work in terms of PVR driver trying to access that memory
<freemangordon>
because PVR shall write to the 'rotated' range
<freemangordon>
oh, wait, PVR renders to another bo
<freemangordon>
which we are copying to the framebuffer bo
<freemangordon>
hmm, hmm, that must be it
<tmlind>
freemangordon: sounds like that's the part i was wondering about for a long time, where does the copying happen?
<freemangordon>
which driver?
<tmlind>
pvr bo copy to framebuffer bo
<freemangordon>
in modesetting, glamor does it
<tmlind>
Wizzup: sounds like d4 should be available used by the truck pellet by this time, maybe try contacting some electronics recycling warehouses in the usa?
<freemangordon>
by wrapping PVR bo into KHRImage, and then to textture
<freemangordon>
and then it renders that texture to FB bo FBO
<freemangordon>
FBO is GL FBO
<freemangordon>
do you parse or I shall rephrase?
<tmlind>
well so are you saying also wayland must copy pvr bo to fb bo at some point?
zhxt has quit [Remote host closed the connection]
<freemangordon>
yes
<tmlind>
ok so not done in the kernel
<freemangordon>
no
<tmlind>
that means likely the d4 artifacts are likely a missing flush on the pvr side before the bo gets copied to the fb bo
<freemangordon>
but! on fullscreen there should be no copy
<freemangordon>
PRESENT should just switch framebuffers on vblank
<freemangordon>
tmlind: I don;t think we can avoid the copy in non-fulscreen
<tmlind>
so what about running weston-simple-dmabuf-egl, where does that bo get copied?
<tmlind>
ok, just trying to understand how it works
<freemangordon>
what is weston-simple-dmabuf-egl?
<freemangordon>
tmlind: lets speck in terms of xorg, I don;t know what WL stuff does
<freemangordon>
though it should be similar/same
<freemangordon>
so, with modesetting: we have one scanout framebuffer, lets call it 'primary bo'
<tmlind>
freemangordon: that's the weston test app that fails like wlroots if trying to use the default render node
<freemangordon>
all the 2d rendering happens on 2d textures (which are basically offscreen pixmaps) which then glamor renders to that primary bo using GL
<tmlind>
mighty17[m]: sorry not really familiar with the audio stuff, just try to recycle and patch what's already there
<tmlind>
freemangordon: ok
<freemangordon>
for 3D - it is rendered to another bos (PVR GL GBM backed surface provides up to 3 buffers (bos) for double-buffering)
<freemangordon>
then the freshly rendered BO is being 'finished' by calling gbm_surface_lock_front_buffer (EGLSwapBuffers or similar does that, somewhere in MESA)
<freemangordon>
then this BO is being send to xserver by using the PRESENT extension
<freemangordon>
"being send" is simply passing dma_buf fd
<tmlind>
freemangordon: if you have some names for the pvr kernel module functions that get called around the bo copy to fb bo, i can try to debug the artifacts issue
<freemangordon>
no, this happens in userspace
<freemangordon>
in xorg/whatever userspace driver
<tmlind>
right but the flushing ioctl is still needed to scan out the pvr bo and that happens in kernel module?
<freemangordon>
I guess this is needed because of SGX MMU
<freemangordon>
in order SGX to be able to render to the memory
<tmlind>
sounds like we're now missing dma_sync_single somewhere in the pvr kernel driver after pvr userspace is done rendering to the pvr bo
<freemangordon>
you need to set-up its MMU, because we have no dedicated VRAM
<tmlind>
yup
<freemangordon>
tmlind: actually I think there is no "pvr bo" and "omapdrm bo"
<tmlind>
the artifacts are visible also with hdmi with uvos' sgx clock slow trick, we just don't notice them so easily as the screen gets repainted at 60hz
<freemangordon>
all bos are allocated by omapdrm
<freemangordon>
or rather by DRM engine
<tmlind>
freemangordon: right yes that's what i understand also, but pvr just uses a separate bo
<freemangordon>
which calls back omapdrm dma_buf callbacks
<freemangordon>
it can;t be separate, because FD is valid for all the kernel
<freemangordon>
also, define "separate
<freemangordon>
"
<tmlind>
hmm so maybe the missing flush is still somewhere in omapdrm, note that the pvr driver does it's own dma sync/invalidate calls
<freemangordon>
yes, but it does that from the SGX POV, iiuc
<tmlind>
yeah seems to mostly invalidate for sgx
<freemangordon>
it flushes what has been cached in SGX caches, no?
<tmlind>
not that i see
<freemangordon>
ah
<tmlind>
maybe that's the missing part
<tmlind>
i'm only seeing pvr_invalidate_range called sometimes
<freemangordon>
ok, seems I am missing the theory there
<tmlind>
me too
<freemangordon>
the point is:
<freemangordon>
we use WC memory for framebuffers, right?
<tmlind>
yeah
<freemangordon>
but, where the cache itself lives?
<freemangordon>
in DRAM controller?
<freemangordon>
I'll assume that
<tmlind>
well it's write-combine, i guess we could run some tests on non-cached too
<freemangordon>
noo, that'd run the performance even more
<freemangordon>
*ruin
<tmlind>
right but might be interesting to see for debugging if the artifacts go away
<freemangordon>
oh, it is write-combine, but the cached data stays in cache (so DSS reads stale data), until a flush happens
<freemangordon>
is that correct?
<tmlind>
if it works with uncached, then it rules out the missing flush for the write-combine buffer
<tmlind>
i suspect with the artifacts we get the pvr bo copy to fb bo before the pvr bo has been flushed out
<tmlind>
not easily visible at higher rates or on hdmi as the next frame already might be good
<freemangordon>
I need to re-read again my books on how WC works in terms of multiple devices accessing the memory bus
<freemangordon>
tmlind: agreed
<freemangordon>
but, there are fences, which looks to be used
<tmlind>
the reason sgx rate increase helps is the pvr bo is done earlier and more likely ready when pvr bo gets copied to the fb bo
<freemangordon>
mhm
<freemangordon>
sounds sane
<freemangordon>
tmlind: but, this is for 2d only
<tmlind>
is there some difference in the ioctls to trap when the userspace copies pvr bo to kernel bo?
<tmlind>
to add a dump_stack() call
<freemangordon>
tmlind: this is GL texture copy through shader
<freemangordon>
in terms of glamor that is
<tmlind>
hmm a stack trace would likely only show the ioctl to the call trace though, not what happens in the pvr driver earlier
<freemangordon>
tmlind: you can easily test by putting glFlush()
<tmlind>
what's the kernel ioctl that translates to?
<tmlind>
eventually
<freemangordon>
and setting fush behaviour to 2 in powervr.ini
<freemangordon>
oh, it is far from being that simple
<freemangordon>
(ioctl)
<freemangordon>
but, all this happens in the blobs, so not really sure how it's done
<tmlind>
ok, probably some pvr custom ioctl
<freemangordon>
I suspect they call blit on SGX mmu handles
<freemangordon>
BTW, every gbm bo can be kind of mmaped into SGX device address space
<freemangordon>
and you get a 'handle' to that
<freemangordon>
and then you can pass those handles to SGX, for various rendering ops
<freemangordon>
I suspect clsed blobs to the same/similar
<freemangordon>
ther is PVRSRVMapDmaBuf / PVRSRVUnmapDmaBuf that I was able to make working
<freemangordon>
tmlind: but again, to know the rendering is finished, one must call some "waitforopstocompete" or somesuch finction from the blobs
<freemangordon>
which, IIUC, reads some memory address that is visible by both SGX and CPU
<freemangordon>
non-cached memory I guess
<tmlind>
ok
<freemangordon>
tmlind: could you try to get tomi to help somehow for VRFB?
<tmlind>
freemangordon: probably best that you just send an email to the related mailing lists
<Wizzup>
maybe we should get the mesa and other stuff packaged for him so that it's perhaps easier to test/debug
<freemangordon>
I will take on the task to port VRFB to omapdrm, but I need some hints
<tmlind>
i doubt that tomi has much any cycles beyond dealing with current socs
<tmlind>
yeah tomi might have some good pointers
<freemangordon>
sure, that's why 'hints' :)
<freemangordon>
like, when is the best time to allocate VRFB context
<tmlind>
yeah worth trying to send an email
<freemangordon>
ok, need to pack, ttyl (next week) guys
<tmlind>
later enjoy your vacation :)
freemangordon has quit [Quit: Leaving.]
pere has quit [Ping timeout: 256 seconds]
pere has joined #maemo-leste
Pali has joined #maemo-leste
<Wizzup>
hey looks like pstore gets autologged to /var/log/pstore/*
<tmlind>
oh interesting, that means the uart was not clocked when that happened
<mighty17[m]>
<tmlind> "mighty17: sorry not really..." <- yikes, does noone know about audio? it is very confusing :P for now i'll try usb-otg and pvr egl issues
uvos has quit [Read error: Connection reset by peer]
uvos__ has joined #maemo-leste
uvos__ is now known as uvos
<uvos>
Wizzup: the evdev interface works
<Wizzup>
ok, but not on the -devel 5.11 kernel
<Wizzup>
I think
<uvos>
no :P
<uvos>
Wizzup: its just that plug detection only works when the cpcap audio device has been used in some way recently, ie your playing something, the modem is playing something or pa has a stream active
<uvos>
this is a power managment thing in cpcap
<Wizzup>
well pa picks it up regardless I think
<uvos>
that i dont fully understand yet
<uvos>
no
<Wizzup>
hmm
<uvos>
just have to figure out what enable register for what device in cpcap ends up also enabling plug detection
<uvos>
but it works in practice rn anyhow because as soon as you play something it kicks in and the device detects the hp
<uvos>
or if you open pavucontrol
<Wizzup>
ah, yeah, ok
<uvos>
i think thats how its supposed to be used acctually and its a pm optimiziation. ofc for mainline kernel we have to work around it and make it report even when there is no audio in use.
<uvos>
btw
<uvos>
you broke osso-xterm
<uvos>
since you rebuilt it and now .launch is an so
<uvos>
.launch being an so is needed for newer glibc
_inky has quit [Ping timeout: 256 seconds]
<uvos>
glibc broke it and mameo launcher dlopening a normal binary was a terrible hack in the first plae.
<uvos>
(well launcher is a terrible hack either way but i degress :P)
<tmlind>
Wizzup: i'll send an email with you in cc, let's see what we find
<Wizzup>
tmlind: ty :)
_inky has joined #maemo-leste
<Wizzup>
I got so used to using my d4 I was trying to insert the hp in the wrong side on my n900
<Wizzup>
good sign
<uvos>
heh
<tmlind>
Wizzup: ok mail sent to my old hmr usa friend, let's attempt to preserve as many as we can from recycling
<Wizzup>
tmlind: agreed!
<Wizzup>
thanks for that
<tmlind>
np
<Wizzup>
we can probably use some of the funding for it too
<tmlind>
great
<tmlind>
and if we manage to source few pellets full of them, we can probably get help from other non profit orgs for distributing to folks in the 3rd world countries too for reuse
<Wizzup>
yeah, that'd be great
<tmlind>
still few years of usage easily left even in gsm mode
<Wizzup>
we could try for the droid 3 too if those are still in circulation too, since they might even work in the us
<tmlind>
good idea, maybe reply to that mail
<Wizzup>
(with sigmakey unlock)
<uvos>
i mean you could look for d3s outside the us too
<uvos>
m3s, whatever
<tmlind>
yeah sure
<tmlind>
let's see what we can find, then maybe set up a new webpage for sourcing usable phones
<Wizzup>
uvos: I found it extremely hard to find any at all in europe
<Wizzup>
tmlind: yeah
<uvos>
Wizzup: they wernt sold in europe
<tmlind>
you'd assume it would be easy to find sponsors for something like that, maybe even verizon could be interested to sponsor that kind of reuse
<uvos>
they where sold in south america and china + south asia
<tmlind>
ok
<uvos>
at least in volume
<uvos>
i think you could order one from moto europe directly at some point
<Wizzup>
do we know anyone who works at verizon?
<tmlind>
don't think so, but these recycling folks probably do
<tmlind>
recycling must be a huge issue.. so shipping them to reuse outside your market would be good publicity stunt
<mighty17[m]>
so we can probably replace `EXT_read_format_bgra` with `IMG_read_format` in wlroots, and then we're only left with 1 missing extension? :D
<l_bratch>
awesome October update post :)
<Wizzup>
l_bratch: cheers
xmn has quit [Ping timeout: 268 seconds]
<Wizzup>
tmlind: I am not sure what you meant regarding part numbers, do you mean spare parts?
<Wizzup>
uvos: regarding osso-xterm, osso-xterm $(which ncmpcpp) seems to work
<Wizzup>
from console
<Wizzup>
oh right it's the x-terminal-emulator thing
System_Error has quit [Remote host closed the connection]
System_Error has joined #maemo-leste
pere has quit [Ping timeout: 256 seconds]
<Wizzup>
uvos: ok so maemo invoker and maemo launcher just appends .launch blindly and then tries $PATH
<uvos>
Wizzup: so it looks for x-terminal-emulator.path?
<uvos>
Wizzup: *so it looks for x-terminal-emulator.launch?
<Wizzup>
uvos: so first of all the symlink will have to change to osso-xterm from osso-xterm.launch
<Wizzup>
but secondly I need to change the code to do this:
<uvos>
yeah sure
<Wizzup>
* Then resolve symlink(s)
<Wizzup>
* Then run
<Wizzup>
* First resolve in PATH
<Wizzup>
* Then add launch
<Wizzup>
what it does right now is:
<uvos>
yeah
<Wizzup>
* append .launch if not absolute path
<Wizzup>
* search in PATH
<Wizzup>
* run
<uvos>
ok
<Wizzup>
so it makes it x-terminal-emulator.launch
<uvos>
ok
<Wizzup>
I'll fix it, I don't think this can break things even though it'll work slightly differently
<Wizzup>
we'll see
<uvos>
if you cant do it rn, maybe drop maemo-launcher support from osso-xterm build untill it works
<uvos>
since it breaks all the terminal=true applications
<Wizzup>
no, I will do it today or tomorrow
<uvos>
ok
<Wizzup>
it's been a long day though :)
<uvos>
no worrys
<uvos>
just if you want to do something else first
<Wizzup>
nah I'll do this first
_inky has quit [Ping timeout: 256 seconds]
<uvos>
Wizzup: so what do you want to do about the charge-mode problem?
<Wizzup>
I was going to test it this morning but forgot
<uvos>
ok
<uvos>
we need to either enable charge-mode
<uvos>
or disable battery guard i guess
<uvos>
but i dont like the latter because the battery can end up <3v
<uvos>
which is bad
<Wizzup>
does charge mode auto detect if it needs to charge? probably not right?
<uvos>
Wizzup: not sure what you mean
<uvos>
the device ends up in the charge-mode runlevel if it boots with the usb plugged in
<Wizzup>
what does boot.cfg look like in your proposed scenario
<Wizzup>
another entry with softlevel=charge-mode?
<uvos>
Wizzup: no
<Wizzup>
ok
<uvos>
the signle entry gets softlevel=charge-mode
<uvos>
the charging sdl then runs and checks machine state
<Wizzup>
ok
<uvos>
and boots another runlevel or shows the battery symbol depending on the conition it finds
<Wizzup>
let me try
* Wizzup
reboots
<uvos>
if usb is not plugged it boots to default
<uvos>
if usb is plugged but the battery is full it powers off
<uvos>
if the power button is pressed it boots default
<Wizzup>
18:30 < uvos> if usb is plugged but the battery is full it powers off
<uvos>
if an alarm fires it boots default
<Wizzup>
I have to question this I think
<uvos>
if the usb cable is removed it powers off
<Wizzup>
aha
<Wizzup>
well it booted to charge mode alright
<uvos>
right now you can unplugg to power of
<Wizzup>
battery shows low red, but it was full in h-d
<Wizzup>
does it turn off the screen eventually?
<uvos>
it tries to
<uvos>
but driectfb cant
<uvos>
with the drm sdl backend it works
<Wizzup>
so it'll maybe draw more power than it receives
<uvos>
no
<Wizzup>
(I just tried on d4)
<uvos>
it charges
<uvos>
but yeah its slow
<uvos>
(this will start working with ddk1.17 for free)
<Wizzup>
ok, so it's known not to close screen on d4
<Wizzup>
I thought that already drm
<Wizzup>
s/close/turn off/
<uvos>
no it runs on driectfb
<uvos>
becasue drm is broken on ddk1.9
<Wizzup>
hah I think because I used charge-mode ofono for once recognizes the sim properly
<uvos>
heh
<uvos>
beacuse it delays boot i gues
<Wizzup>
yes
<uvos>
the fbdev device on d4 is also buggt
<uvos>
those lines should not be there
<uvos>
thats a known issue
<uvos>
(also on the kernel m-l)
<uvos>
btw
<Wizzup>
ok
_inky has joined #maemo-leste
<uvos>
is a chache coherency issue with omapdrmfb
<kona_>
i did something unexpectedly inauspicious: i updated my n900 maemo-leste and now the ui acts strange in the following ways: apps don't launch, and if i launch them from ssh the windows show up but i can't switch between them (it always goes back to showing the home screen when i select one.)
kona_ is now known as kona
<buZz>
thats a interesting bug
<kona>
it's unexpected, for sure.
<kona>
Seems like maybe time to re-image :)
<uvos>
hmm wierd
<uvos>
are you on devel or stable?
<uvos>
can you click stuff in the apps you launch?
<uvos>
Wizzup: the issue with xorg reporting the wrong display size on n900 breaking hildons setting of the input transformation matrix was fixed right?
<kona>
uvos: it's sort of acting like the screen needs re-cal
<kona>
can't click in the apps
<uvos>
kona: could you paste xinput list-props $TOCHSCREENID?
<kona>
now i can manage my beowulf cluster from beowulf.
<kona>
or something :)
<Wizzup>
;)
_inky has joined #maemo-leste
<kona>
I celebrated the restoration of the touchscreen to working order in -devel by replacing the screen protector my n900 came with, it was peeling up one side
<Wizzup>
:)
<kona>
I don't think I've ever been so successful applying a screen protector before...