Danct12 has quit [Remote host closed the connection]
akossh has quit [Quit: Leaving.]
Danct12 has joined #maemo-leste
belcher has quit [Ping timeout: 258 seconds]
belcher has joined #maemo-leste
joerg has quit [Ping timeout: 260 seconds]
joerg has joined #maemo-leste
xmn has quit [Ping timeout: 264 seconds]
xmn_ has joined #maemo-leste
pere has quit [Ping timeout: 258 seconds]
panzeroceania_ is now known as panzeroceania
pere has joined #maemo-leste
<freemangordon>
hmm, xf86-video-omap loads, but there is nothing on the screen, even for 2d stuff
<freemangordon>
weird
xmn_ has quit [Quit: ZZZzzz…]
kona_ has joined #maemo-leste
meldrian_ has joined #maemo-leste
meldrian has quit [Ping timeout: 260 seconds]
kona has quit [Ping timeout: 260 seconds]
Wikiwide has quit [Ping timeout: 264 seconds]
Pali has joined #maemo-leste
mardy has joined #maemo-leste
Wikiwide_ has joined #maemo-leste
Pali has quit [Ping timeout: 260 seconds]
<freemangordon>
oh, ok, finally I was able to mmap gbm bo for writing :)
<freemangordon>
the same bo EGL renders to
<freemangordon>
uvos: so, how that helps us with dri3? :) hack modesetting to not use glamor and do 2D SW render to back buffer?
<freemangordon>
the other option is to use dri2 driver and do a PVR blit of gbm EGL bo
<freemangordon>
weh have to teach dri2 driver on dri3 ofc
<freemangordon>
but thats simple, more or less
<tmlind>
freemangordon: nice :) fyi, things are moving towards the /dev/dri/cardX being used only for allocation with the rest using the render node, but current pvr mesa seems to only work using the /dev/dri/card0 node
<tmlind>
that's to avoid all the permission issues
inky has joined #maemo-leste
<tmlind>
if there are other reasons for doing it, i don't know what they might be
<freemangordon>
tmlind: I don;t understand how's that relevant, sorry. all this dri/drm/ whatever stuff is still in a тхицк фог фор ме :)
<freemangordon>
oos
<freemangordon>
*still in thick fog for me
<freemangordon>
if you have an idea how thing should work (given that I can read/write bo's EGL renders to), please share
<freemangordon>
I mean - in terms of xorg that is
<freemangordon>
I would really love if we have zero-copy but not sure what rendering pipeline should look like
inky_ has quit [Ping timeout: 260 seconds]
<tmlind>
yeah i don't know how it works either :)
<freemangordon>
tmlind: BTW, definitely there is something wrong with the kernel, xf86-video-omap driver renders nothing on the screen, but pretends to work. *but* - it worked couple of times. 3 of 20, for example
<tmlind>
weird
<freemangordon>
the same happened yesterday with glmark
<tmlind>
which hardware?
<freemangordon>
d4
<freemangordon>
on n900 it seems there is no issue
<tmlind>
yeah ok d4 needs to update the command mode lcd also to refresh it
<tmlind>
that patch you reverted might fix it for d4?
<freemangordon>
but I have "drm/omap: Fix page fault handling and flush what framebuffe wants flushed" reverted there (on n900)
<freemangordon>
yeah, lemme try it
<freemangordon>
while we are at it :)
<tmlind>
ok, not sure what might be broken with that patch for n900.. and not even sure if that's the right fix for d4
<tmlind>
heading out here, bbl today at some point
<freemangordon>
ttyl, will let you know if it is better with that patch reverted
<tmlind>
yeah ok hopefully it works on d4, then we can figure out what's wrong with that patch
<bencoh>
do we have a properly working version of -omap?
<uvos>
sure
<Wizzup>
the d4 uses it now
<bencoh>
ah, alright
<uvos>
it works on d4 with sgx 1.9
<Wizzup>
but it has no DRI3
<bencoh>
yeah
<uvos>
and it works on just omapdrm
<Wizzup>
omap_dri.c is 672 lines
<bencoh>
I'd say it's the way to go
<bencoh>
especially if we plan on adding more omap-specific features at some point
<bencoh>
(video decoding anyone? :) )
<uvos>
lets not get ahead of ourselves
<uvos>
besides the ddx dosent do decoding
<uvos>
presentation maybe
<Wizzup>
I think exa can help with scaling but yeah
<Wizzup>
not the actual decode pipeline
<Wizzup>
but also the hw video decoders are kind of at the bottom of my list, I never watch videos on my phone
<Wizzup>
(but yeah, *my* list)
<Wizzup>
anyway
<bencoh>
right, but I vaguely remember it playing a role in the presentation part, and iirc one of the devs working on it had the ddx patched for that purpose
<bencoh>
but yeah, anyway :)
<Wizzup>
grepping for gri3 in glamor/ makes it look easy
<Wizzup>
dri3* even
<uvos>
modern ddx dont do video presenstaion either
<Wizzup>
is there some tool to create a defconfig, or shall I just commit my .config ?
<Wizzup>
I also need to push the dts, etc
<bencoh>
make savedefconfig?
<uvos>
indeed
<Wizzup>
ok
<uvos>
freemangordon: ok so sounds like adding a dri3 fallback path for modesetting using mmap is possible for its AccelMethod "none" case
<uvos>
adding this would be a great service to others
<uvos>
it would for instance also slove the pps issues
<freemangordon>
uvos: pvr2d does PVRSRVMapFullDmaBuf
<uvos>
so i twould do that
<freemangordon>
ok
<freemangordon>
PVRSRVMapFullDmaBuf just sets SGX MMU
<Wizzup>
uvos: didn't he say it would be slower though?
<Wizzup>
(but yeah I suppose it could still be useful)
<uvos>
well its mmaping and rendering via cpu
<uvos>
thats slow
<uvos>
but short of implementing exa on pvr2d i dont see how anything would be faster
<uvos>
and ofc thats something to be done later and not now
<uvos>
also current d4 works exactly like this
<uvos>
so it should not be unusably slow
<Wizzup>
the current d4 is kinda slow in 2d
<uvos>
i mean 2d on d4 is slow
<Wizzup>
esp scrolling is painful
<uvos>
but its not usage breaking
<uvos>
yeah
<Wizzup>
depends on who you ask
<Wizzup>
freemangordon might disagree :P
<bencoh>
terminal scrolling is atrocious
<Wizzup>
any scrolling is atrocious
<Wizzup>
there's many seconds in delay
<uvos>
well other than gpu accel
<uvos>
like qt stuff scrolls fine
<uvos>
because it uses gl instead of xorg primitves
<Wizzup>
I mean it's a good first step if we have a way to als omake 2d fast
<Wizzup>
otherwise perhaps the path makes less sense
<uvos>
it makes plenty of sense for pp i think, no one cares about xorg on it, we dont have the bandwith to also fix its 3d driver and its cpu is fast enough to make this ok
<uvos>
gets the mapphones working right now, and we can still investigate resurecting -video-omap or adding a accel plugin to replace glamor for modesetting-pvr
<freemangordon>
guys, we can implement it through mmap initially and then to pvr2d accel where possible
<Wizzup>
ok
<Wizzup>
I do not have a strong opinion, just trying to help
<Wizzup>
feel free to do what makes sense
<sicelo>
is there a big x11 issue with PP? there's sxmo, so i guess it's working reasonably okay for them
<uvos>
Wizzup: one for 3.0 kernel and one for 2.6 kernel
<uvos>
or do you want to do it in 2 branches?
<uvos>
i gues that makes sense too
<Wizzup>
branches or even directories
<uvos>
ok
<uvos>
ill do it as branches later
<uvos>
binaries makes no sense
<uvos>
those are in the main clownboot repo anyhow
<Wizzup>
ok, since I was not able to compile it ;-)
<uvos>
compileing it remains tough yeah
<uvos>
i have old gcc installed on my main machine but its not something i can easly just export
<freemangordon>
how old?
<Wizzup>
uvos: yeah so I commented out the aes disabled thing and now it suspiciously doesn't seem to boot
<freemangordon>
as the one in scratchbox is old too ;)
<Wizzup>
uvos: let me add it back in..
<uvos>
Wizzup: wierd
<uvos>
Wizzup: maybe there is some errata tmlind told you about
<uvos>
on old omap4 chips
<Wizzup>
uvos: yes that is what I recall vaguely
<Wizzup>
I can grep logs
<uvos>
ok would make sense
<Wizzup>
06:17 < tmlind> Wizzup: oh cool, you got it booting :) looks like aes2 is not accessible on those devices, try setting:
<uvos>
the d3 is a really early omap4 device
<uvos>
ok so what about the high 3mb
<Wizzup>
one by one please
<uvos>
the android kernel parameters sugesst all 512 are useable on d3
<Wizzup>
ok
<Wizzup>
something funny I think I have noticed, if serial is not in by the time the kexec mod probes (before actually calling kexec), the serial output is not visible until after the kexec
<Wizzup>
freemangordon: both uvos and I are suggesting to take say debian 6 or so
<Wizzup>
(I made that number up)
<Wizzup>
as opposed to using the maemo specific SB just to build a motorola kernel module
<Wizzup>
to be clear if it works I suppose it can be fine
<freemangordon>
ah
<freemangordon>
well yeah, you can install old debian in a VM
<Wizzup>
right
<freemangordon>
but, you can take the pre-build maemo SDK images
<uvos>
btw you can also use the android sdk to emerge the exact gcc version motorola used to complie the kernel
<uvos>
never done it
<uvos>
but should work
<Wizzup>
emerge - gentoo based?
<uvos>
no
<freemangordon>
as I am not sure old debian will still have repos alive
inky_ has joined #maemo-leste
<Wizzup>
I think that's just kind of confusing to suggest using scratchbox since it has for the most part outlived it's usefulnes and it mighr confuse people
<Wizzup>
quite some maemo folk I also speak to don't like sb
<Wizzup>
but yeah
<freemangordon>
that's why we us VM on leste :)
<uvos>
build/tools/make_standalone_toolchain.py
<uvos>
in android NDK
<Wizzup>
uvos: any way I can dump the accelerometer data?
<Wizzup>
my confusion is that I was expecting to find at least 12 gpios there
<Wizzup>
(under gpiochip6)
<Wizzup>
oh, maybe this is also off by one thing
<Wizzup>
so <&gpio6 12> == gpiochip 5, 12
<uvos>
right
<Wizzup>
looks like
<uvos>
so export pin 12
<Wizzup>
yeah that is 140
<Wizzup>
root@devuan-bionic:/sys/class/gpio/gpio140# echo 1 > value
<Wizzup>
-bash: echo: write error: Operation not permitted
<Wizzup>
truly has to fail every step of the way :P
<uvos>
heh
<Wizzup>
ah I guess I might need to set the direction
<Wizzup>
right
<uvos>
not sure on the interface sorry
<uvos>
but yeah makes sense
<Wizzup>
yeah, echo out > direction worked
<Wizzup>
not that it helped with i2c, but hey :)
<uvos>
is the chip on the bus
<uvos>
hmm
<uvos>
wait you did change value too
<uvos>
not just direction
<uvos>
its active high
<Wizzup>
value set to 1, with active_low set to 0
<uvos>
pulling it low wont help
<uvos>
ok
<uvos>
hmm
<Wizzup>
I think it might make more sense to look at android at this point
<Wizzup>
of course there we have the problem that the dts had the wrong endianness ;)
<uvos>
Heresy
<Wizzup>
maybe this is for another time then
<Wizzup>
what should i2cdetect show if it's present but not in use?
<uvos>
yes
<Wizzup>
literally "yes"?
<tmlind>
freemangordon: nice work, so you probably figured out ddk-1.17 no longer uses any of those proxied ioctls in omapdrm driver ddk-1.9 was using, whatever you do let's not add those back :)
<tmlind>
that was a pain to maintain with a big pile of extra patches against the mainline kernel
<Wizzup>
uvos: heh the kbd brightness is the screen
<Wizzup>
or something like that it seems..
<Wizzup>
this turns on the screen brightness: echo 1 > /sys/class/leds/lm3532\:\:kbd_backlight/brightness
<Wizzup>
(no diff between 1 and 255)
<uvos>
ok
<uvos>
just swap the channels in dts then
<Wizzup>
right
<Wizzup>
uvos: so that's the reg = <> or led-sources = <> ?
<uvos>
tmlind: btw reading the above
<uvos>
led-sources should be swaped
<uvos>
ie in the end
<uvos>
leds for backlight
<uvos>
the leds phandle should link to the one currently used by the keyboard backlight