xlab_ has quit [Remote host closed the connection]
egbert has quit [Read error: Operation timed out]
egbert has joined #linux-sunxi
xlab has joined #linux-sunxi
delusr_ has joined #linux-sunxi
BJfreeman has quit [Quit: had a good time]
delusr_ has quit [Quit: ChatZilla 0.9.90 [Firefox 20.0/20130329030832]]
tinti has quit [Quit: Leaving]
wingrime-android has quit [Ping timeout: 256 seconds]
rellla has joined #linux-sunxi
rellla2 has joined #linux-sunxi
rellla has quit [Ping timeout: 256 seconds]
shineworld has joined #linux-sunxi
<oliv3r>
Turl: ram, mmu etc doesn't matter to BROM. It doesn't use any of that. The BROM should (really it should) assume everything is dirty. It is initializing everything from an unknown state :)
ZaEarl has quit [Ping timeout: 255 seconds]
xlab has quit [Ping timeout: 248 seconds]
xlab has joined #linux-sunxi
eebrah has quit [Remote host closed the connection]
shineworld has quit [Ping timeout: 240 seconds]
shineworld has joined #linux-sunxi
vicenteH has joined #linux-sunxi
bfree has quit [Ping timeout: 252 seconds]
bfree_ has joined #linux-sunxi
xlab has quit [Remote host closed the connection]
xlab has joined #linux-sunxi
<rellla2>
hi all. i'm searching for good links, where i can start reading from, if i want to dig a little bit into this whole video/graphics/layer/rendering/gpu/vpu thing?
<rellla2>
i'm an absolutely noob and want to stop mixing up this things and wanted to get explained terms and relationships between that all.
<rellla2>
maybe there is something on the web, which can facilitate me the basics.
rellla2 is now known as rellla
wingrime-android has joined #linux-sunxi
eebrah has joined #linux-sunxi
wingrime-android has quit [Read error: Connection reset by peer]
wingrime-android has joined #linux-sunxi
wingrime-android has quit [Read error: Connection reset by peer]
wingrime-android has joined #linux-sunxi
<hipboi|cubie>
slapin_nb, pong
shineworld has quit [Quit: Leaving]
<slapin_nb>
hipboi|cubie: hi! could you please reply to that mail
<slapin_nb>
?
<hipboi|cubie>
:O
hipboi|cubie has quit [Read error: Connection reset by peer]
wingrime-android has quit [Remote host closed the connection]
<oliv3r>
rellla: if you speaking of general 2D/3D things, then there should be some docs online
<oliv3r>
rellla: for the A10 source bomb, it's one giant big mess :p
<oliv3r>
rellla: what are you most interested in? 2D, 3D? Video Acceleration?
paulk-desktop has joined #linux-sunxi
<rellla>
oliv3r: i want to read a litte bit about all that 2D,3D and video acceleration.
<paulk-desktop>
is there a way to set a boot splash from u-boot?
<rellla>
what are shaders, overlay, how is that going on with layers, what does gpu and vpu handle, how do they speak with another, how comes all to the framebuffer...
<rellla>
this are really really basic noob questions. i only want to understand a little bit more of it ;) i got dumb reading a10 xbmc/vlc source code. it's a mess, if you don
<lunra>
Best to learn these things from desktop gpu information, IMO
<lunra>
I mean, except for the specific things
<rellla>
a mess, if you miss the basics and are not weak with C even :P
<lunra>
But I'll tell you that basically a shader is a program that executes on a graphics card to render an image. Commonly you have a vertex shader and a fragment shader. A vertex shader is called once per vertex, and a fragment shader is called once per pixel
<lunra>
(as for the other stuff, I don't know, so I'm not very helpful ;) )
<rellla>
lunra: thanks. this it what i want to find in the web or in a book, where i can dig in, if i want.
wingrime-android has joined #linux-sunxi
<wingrime-android>
oliv3r: any positive reeults with dma?
<wingrime-android>
*results
<oliv3r>
rellla: oh that is all interesting reads, and I don't think its' all well documented
<oliv3r>
rellla: not that I know, if you do find something, share the links :D
<oliv3r>
rellla: I know a _little_ bit, what 2D is, what 3D is, but how the overlay sticks all that together, what is 'a' layer? etc etc, yeah I don't know all that either :)
<oliv3r>
rellla: I have a hard time understand the difference between, framebuffer, directFB and X in that regard too :)
<wingrime-android>
oliv3r:ping
<oliv3r>
wingrime-android: lo
<oliv3r>
wingrime-android: haven't done anything with DMA yet :( except for testing your patch that one time
<wingrime-android>
and some results?
<oliv3r>
paulk-desktop: I know my original firmware did it, but that was done from boot.axf. I don't know/think if u-boot currently can do ANYthing graphical with the A1x
<oliv3r>
wingrime-android: i posted those to you ages ago via paste.debian.com; very very small improvement, but not sure if it was relevant :p
<wingrime-android>
(
<wingrime-android>
oliv3r: can say anything about hw rnd gen?
<lunra>
The framebuffer is a block of memory that you write to that represents the entire display's image. DirectFB is a library that abstracts some of that writing. X is a major abstraction/list of hoops you have to jump through to, essentially, perform a naive memcpy()
* lunra
is't fond of X on platforms that don't reaaaally have working graphics drivers anyway (yes, it does work, but it's hard to get working)
<paulk-desktop>
oliv3r, too bad -- on omap3 devices, I know it's possible
<lunra>
But I have a feeling I just dumped a lot of info without really understanding what you wanted, in which case I'm sorry :|
<oliv3r>
wingrime-android: turl was working on it, but without DMA, i'm starting work on PWM now, and afterthat, if nobody has, will play with crypto as that looks like a fun driver, but will require DMA
<oliv3r>
paulk-desktop: i'm sure it's possible, I think we simply don't have drivers for it in u-boot :) patches welcome :D
<oliv3r>
paulk-desktop: the little android you see at boot, is by boot.axf which chainloads u-boot. I have seen a boot animation during u-boot/kernel load until the kernel takes over on my native firmware image
<oliv3r>
paulk-desktop: but i have no clue how u-boot was involved
<paulk-desktop>
yes I understood that
<oliv3r>
paulk-desktop: but a graphics patch, to show splash during u-boot would be awesome. to have it show animated png's would be even more awesome :)
<paulk-desktop>
ok
<paulk-desktop>
I'll look if I have time :)
<oliv3r>
:D
hansg has joined #linux-sunxi
<rellla>
lunra: it's very ok. i'll have to search the web on my own - after i read into the new cedarx-sources...
* rellla
tried to be humorous - nothing new here :P - seems i missed april fool's day
tinti has joined #linux-sunxi
shineworld has joined #linux-sunxi
<shineworld>
I'm trying to reduce boot time but there are some piece of code that I don't understand the mean, like this:
<shineworld>
in init_disp.c:
<shineworld>
int sec = 1;
<shineworld>
ERROR("to sleep %d seconds.\n",sec);
<shineworld>
ERROR("has waken up.\n");
<shineworld>
sleep(sec);
<shineworld>
none was done just a sleep of 1s after entry in init_initdisplay()
<shineworld>
there are also other places with similar code
<shineworld>
what do you think ? is safe to remove the delay ?
<shineworld>
In my app the boot must be very fast to accomplish customer needs
<wingrime-android>
some displays may be need that delay
<wingrime-android>
hdmi displays may be
wingrime-android has quit [Remote host closed the connection]
<shineworld>
uhm display will be enabled also before the init_initdisplay ?
<shineworld>
in fex I've catch, at end, that:
<shineworld>
[boot_disp]
<shineworld>
output_type = 3
<shineworld>
output_mode = 5
<shineworld>
auto_hpd = 1
<shineworld>
I don't understand where is used and not document at moment
wingrime-android has joined #linux-sunxi
eebrah has quit [Ping timeout: 264 seconds]
Yaku321 has joined #linux-sunxi
<shineworld>
checking on kernel (3.0.52) I haven't found use of [boot_disp]... perhaps is something have to do with nand bootloader ?
ZaEarl has joined #linux-sunxi
Yaku321 has quit [Disconnected by services]
Yaku-noob has joined #linux-sunxi
_BJFreeman has joined #linux-sunxi
_BJFreeman is now known as BJfreeman
tinti has quit [Ping timeout: 245 seconds]
tinti has joined #linux-sunxi
xlab has quit [Remote host closed the connection]
wingrime-android has quit [Remote host closed the connection]
focus has quit [Ping timeout: 245 seconds]
focus has joined #linux-sunxi
hansg has quit [Quit: Leaving]
Tartarus_ has quit [Excess Flood]
Tartarus has joined #linux-sunxi
tinti has quit [Ping timeout: 256 seconds]
theOzzieRat has quit [Ping timeout: 276 seconds]
theOzzieRat has joined #linux-sunxi
tinti has joined #linux-sunxi
n01 has quit [Remote host closed the connection]
Yaku-noob has quit [Ping timeout: 240 seconds]
<oliv3r>
shineworld: the fex may lie
<oliv3r>
shineworld: if you can not grep the name in the current source, it's not there :)
<oliv3r>
sometimes it sounds like script.bin is some magic thing that setups the soc. what it really is, is just options for the drivers to parse
Yaku321 has joined #linux-sunxi
<techn_>
shineworld: where you found init_disp.c?
<shineworld>
openbox/system/core/
<shineworld>
I two targets for this week:
<techn_>
oh.. that's android
<techn_>
you could ask that from Tom
<shineworld>
- add LCD support with actual HDMI, CVS, etc
<shineworld>
- reduce the boot time removing useless parts
<shineworld>
- run all (or possible in ram) so I can remove power without a full shutdown
rellla has quit [Remote host closed the connection]
_BJFreeman has joined #linux-sunxi
<shineworld>
I habit on android at moment
BJfreeman has quit [Ping timeout: 272 seconds]
<shineworld>
I don't know linux os enough to do something of good with Graphics...
<shineworld>
I don't know Tom
<shineworld>
Actually I don't know any here :)
n01 has joined #linux-sunxi
<oliv3r>
lol
<oliv3r>
well always remember, android still runs ontop of linux :p
<oliv3r>
android is nothing more then an application framework ontop of the linux kernel :)
Dreadlish has quit [Quit: WeeChat 0.4.0-rc2]
Dreadlish has joined #linux-sunxi
_BJFreeman is now known as BJfreeman
<techn_>
shineworld: hipboy :)
<techn_>
most likely knows something of that openbox android
<techn_>
or that matsonhall
<shineworld>
yes I know that, but I'm already able to create good GUI with android and I don't have enough knowledge to move to linux + somelib to do my things at moment
Undertasker has joined #linux-sunxi
<shineworld>
ok, I think is too much to ask Tom "Cubie" to follow my problems ;)
<shineworld>
Better to leave it to develop new boards ...
Yaku321 has quit []
san has joined #linux-sunxi
rz2k has joined #linux-sunxi
<ssvb>
libv, rz2k: has any of you attempted to get r3p2 mali kernel driver working on sunxi hardware?
Tartarus has quit [Excess Flood]
<rz2k>
hey ssvb
<rz2k>
I didnt try, but it will work with 99% chance
Tartarus has joined #linux-sunxi
<rz2k>
you only need to fill the new config.h replacement structure and declare what you want to do on driver bring-up (what was in your platfrom.c)
<rz2k>
it was enough to get it working on exynos
<rz2k>
any reason to go r3p2?
<rz2k>
exynos was forced to it because our r2p4 did hang all the time on it
<ssvb>
are you sure? config.h does not seem to work for r3p2 drivers anymore and they need to be initialized in a different way
<techn_>
do we have userspace libs yet?
<rz2k>
yes, you grab your settings from config.h, read the arm/ directory as an example and fill it with desired data. now you need to declare something like MALI_400_MP1(base address) and then it will calculate all the offsets itself
<ssvb>
r3p0 and r3p1 have a rather annoying bug which makes life difficult
<rz2k>
s/arm//platform/arm//
<rz2k>
that mali_400_mp1(stuff) define is actualy defined to the old config.h format, if you read the mali_utgard.h
<rz2k>
they just tried to do it better
<ssvb>
yes, I mean that the old config.h can't be used directly and needs some tweaks, and I wondered if somebody has done this already :)
<rz2k>
yeah, it cant be used
<rz2k>
but its easy to convert
<ssvb>
if not, then it's something for me to do
<rz2k>
check the exynos r3p2 and r2p4, they are in one directory in the odroid-3.0.y kernel
<rz2k>
also dont throw bricks at me if you will find some nasty fustercluck in the platform code, I just wanted to get it working :p
<ssvb>
techn_: theoretically even without the userspace mali blobs for sunxi, libv's lima can be tried as a test
<rz2k>
ssvb: we can grab the exynos ones if you dont care about the license
<rz2k>
they are covered with some weird eula
<rz2k>
that states not an exynos platform, but st-ericsson.
<ssvb>
yeah, we can probably try them as a test, but can't use for real
<rz2k>
they also can do the openvg
<rz2k>
thats the only ones that can do that, guys from hardkernel pushed on guys from ARM for openvg fixes and somehow got fixed libs :p
<ssvb>
rz2k: thanks for the hints about the kernel driver
<rz2k>
you are welcome
<rz2k>
I wanted to do it sometime in the future, but I'm now focused on other things. Need to get the damn a13 boot linux from nand
<rz2k>
allwinner-pack-tools gave me cancer.
<techn_>
rz2k: use sunxi-bsp :)
<rz2k>
but it cant do the nand
<rz2k>
or?
<techn_>
yes it can
<rz2k>
wat
<rz2k>
livesuit image?
<techn_>
it uses lichee-dev branch
<techn_>
or lichee-dev branches precompiled u-boot
<rz2k>
I need livesuit image or atleast lichee-dev u-boot and remapped /dev/nand*
<techn_>
notice that kernel modules goes to nanda.. you need to make symlink from nanda to /lib
<techn_>
havent had time to finish it :(
<techn_>
also scripts/mk_livesuit.sh can do also android style images
<rz2k>
./kill_me_pls.sh
<rz2k>
I've been working with dragon last three days
<rz2k>
didnt got much
<rz2k>
does sunxi-bsp swap the boot0/1 for sun4i/sun5i?
<techn_>
yes
<techn_>
those files are under allwinner-tools/livesuit/<soc>
shineworld has quit [Quit: Leaving]
<jinzo>
hm, the allwinner source drop - anything new?
Undertasker has quit [Quit: Leaving.]
paulk-desktop has quit [Quit: Ex-Chat]
san has quit [Quit: Leaving]
<ssvb>
rz2k: looking at the tables in the sunxi mali kernel driver (r3p0 for now), do we really need 64MiB of reserved memory for it? Can't just a single OS_MEMORY section be enough?
<rz2k>
you can play with that
<rz2k>
dedicated memory was faster on exynos
<rz2k>
you can also use os memory
<rz2k>
I'm not sure about how big the section should be
* rz2k
calls libv's emergency mali-400 support service
<ssvb>
rz2k: yes, I have already tried removing this reservation and everything still seems to work fine
UltraHatomiK has joined #linux-sunxi
<UltraHatomiK>
yo
<UltraHatomiK>
here you create R18 for linuxino A13 ?
<techn_>
rz2k: did sunxi-bsp help? :)
<techn_>
UltraHatomiK: hansg made that fedora release
<techn_>
he's offline but you could try to connect via linux-sunxi@googlegroups.com
tinti has quit [Read error: Connection reset by peer]
<ssvb>
rz2k: hmm, seems like a bit longer investigation is needed, while running glmark2-es2 memtester complained "Solid Bits : testing 39FAILURE: 0xffffffff != 0xff00ffff at offset 0x0b43e09c."
<libv>
ssvb: i have r3p2 working on odroid though
<libv>
but only locally
<libv>
no code has been pushed out yet, i am procrastinating on it, a bit :)
<libv>
and no
<libv>
r3p0 userspace definitely will not work on r3p2
<libv>
i have to bend over backwards in lima to make that work
<libv>
at runtime
rz2k has quit [Read error: Connection reset by peer]
<UltraHatomiK>
olinuxo A13 R18 is debian or ubuntu, no fedora
<libv>
UltraHatomiK: read the wiki
<libv>
but use the .fex from the olinuxino wiki
<libv>
FirstSteps describes how to do it
<libv>
although the howto still is pretty badly mangled
<ssvb>
libv: what about mali r3p1? are all the releases breaking compatibility every time? I know that they are bumping version numbers, but still wonder about the scope of the changes
<libv>
r3p1 is where the huge break happened
<libv>
r3p2 is just a small break
<libv>
i give it only 20% chance that it will work with a r3p1 kernel
<libv>
ssvb: the scope of the changes is mostly their inane usage of an enum for the ioctl numbers
<libv>
the even remove the entry _before_ API_VERSION in r3p1
<libv>
i really would love to find out who in arm introduced that code
<ssvb>
hmm, r3p2 is a major break in the way how the driver is initialized (resources mapping, etc.), so upgrading is not an obvious merge of sunxi changes :)
<libv>
ssvb: the driver we are now talking about is some completely different part than what this tom cooksey guy is dealing with
<libv>
ssvb: and airlied should stfu in this case.
<ssvb>
well, at least it looks like tom cooksey is responsible for the xf86-video-armsoc mess (totally botched 2d part)
<libv>
he is trying to play linus and likes to kick other peoples asses like linus does, but airlied lacks the clue for that
<libv>
and the moral backbone
<libv>
arm has big issues across the board
<libv>
not sure whether they are fixable
<libv>
wait and see...
<libv>
tom cooksey responds correctly though, in the way that airlied would like to world to respond to him
<libv>
sadly top posted...
<ssvb>
he is not in a good position for providing a rude reply
<libv>
airlied isn't in any position either, sadly the world hasn't been following all stories of the last decade as closely as some
<libv>
he still does not seem to have fully grasped the fact that throwing modesetting badly in with the rest of drm was a huge stupid mistake
BJfreeman has quit [Quit: had a good time]
<libv>
popular interfaces, which allow for differences in usage, will be abused, period.
<vgrade>
ssvb: yea , we're puzzled by the 1/2 frame rate
<ssvb>
vgrade: is the cpu usage 100%?
<vgrade>
have the Pi connected atm, but Stskeeps mentioned he;s seen the same on qualcom hw
<ssvb>
if there is memory copy somewhere, then such framerate is more or less expected
<vgrade>
I did try governor settings which made no differnce
slapin_nb has quit [Ping timeout: 246 seconds]
<vgrade>
we should not have any cpu buffer copies. I'll ping when I have device up
<ssvb>
ok
<vgrade>
what fps do you have with fully visible window
<ssvb>
right after the start and without trying to do anything it is ~45-50fps for 1280x720 window
slapin_n1 has joined #linux-sunxi
<ssvb>
vgrade: what is the mali clock speed divisor on your board?
<vgrade>
ssvb: reading down your mail further our intention is that hybris should not add any extra buffer copying just a tiny overhead in tranlating the calls from libc to bionic
<ssvb>
yes, I understand and fully support this
<ssvb>
you can find mali clock speed information in dmesg log
<ssvb>
in my case it is [ 860.930000] Mali: mali clock set completed, clock is 320000000 Hz
<vgrade>
sec while I boot cubie
<vgrade>
same here
<vgrade>
which demo are you using ? The rpi one ?
<ssvb>
yes, with PathAnimation part commented out in content/Mainview.qml
<ssvb>
same as in your instructions
<ssvb>
just the width/height set to 1280x720 in Qt5_CinematicExperience.qml
n01 has quit [Ping timeout: 248 seconds]
<ssvb>
vgrade: is the cpu usage below 50% (with performance governor at 1GHz) when you are running this demo?
<vgrade>
sec
<vgrade>
100% with stock gov
* vgrade
finds page with guv settings
<vgrade>
still same with echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
gzamboni has quit [Read error: Operation timed out]
<ssvb>
do you have any profiling tools?
<ssvb>
the suxi kernel hassupports performance counters
<ssvb>
oops
<ssvb>
the kernel has performance counters enabled and they should be working fine
vicenteH has quit [Ping timeout: 245 seconds]
<vgrade>
not sure we are bulding perf tools for Mer
<ssvb>
but I think oprofile is not enabled in the kernel, only perf would work out of the box
<ssvb>
in any case I still suspect that some buffer copying may be there
<vgrade>
something is eating the cpu yes
<vgrade>
it looked so smooth I did not think to check cpu. I#m assuming Stskeeps is not seeing this with his qualcom and mali
<ssvb>
hmm, but why did you disable PathAnimation?
<ssvb>
I thought that this shooting start animation flying around might have been a bit jumpy with low fps ;)
<vgrade>
crashed with an assert
<vgrade>
sec
<vgrade>
assert: "i >=0 && i< elementCount()" in file painting/qpainterpath.cpp
<libv>
vgrade: why do you need libhybris?
<libv>
vgrade: we have fb and x11 binaries
<ssvb>
vgrade: I built Qt5 from qt-everywhere-opensource-src-5.0.2.tar.xz
<vgrade>
for platorms which dont have those
<libv>
vgrade: such as?
<libv>
we have nvidia hf binaries as well
<libv>
vgrade: what are you proving with sunxi?
<vgrade>
the process, as I know we have drivers for A10
<libv>
we have several sets of binaries for many mali kernel versions, for 2 different windowing systems
<libv>
btw, i was the one who handed mdfe sunxi stuff
<libv>
since he was down anyway, he was an easy victim (unlucky sod was in the hospital with an infection for a few days)
<vgrade>
he's done a good job with the Jenkins
<libv>
he was bored, sadly he's been inundated with work since :)
<libv>
anyway, please use libhybris on other hw, or, constantly remind people that we actually have working fb and x11 drivers, and that proper open source drivers are around the corner
<vgrade>
point taken
<vgrade>
how's lima work?
<ssvb>
libv: sunxi makes a nice target for testing libhybris because we can easily compare all these drivers
<libv>
ssvb: have you ever tested x11 versus fb?
<libv>
start there
<libv>
as fb really gives all that the mali hw has to give
<libv>
mali maps it directly
<libv>
no copies, libv certified.
<libv>
vgrade: i just brought lima up on r3p2 on odroid-x2
<libv>
146fps q3a at 720p, fully memory bound
<libv>
err, fully cpu bound
<libv>
126fps q3a at 1080p, fully memory bound
<libv>
i just starting my initial poking at mesa
<libv>
and just built a standalone swrast driver
<libv>
need to clean up the build still
<vgrade>
good to hear, always work to do
<libv>
vgrade: why has there been absolutely no demo of mer running on fb/x11?
<vgrade>
mer?
<vgrade>
do you mean nemo?
<libv>
or plasmactive or whatever
<libv>
whatever it was you showed of on libhybris
<vgrade>
could not get plasma fitted into my mele a1000 as it only has 512 RAM
<vgrade>
the hybris demo was shown on x11 by ssvb
<vgrade>
well the app I was runnig on libhybris
<ssvb>
it was not libhybris demo, it was the same Qt5 app on X11 to be precise
<libv>
...
<libv>
so the demo that circulated was not even running on top of libhybris?
<libv>
and had absolutely nothing to do with the story described?
<ssvb>
there is more than 1 demo
<libv>
tell me i misunderstood this
<vgrade>
there are two demos of the QT5 app, one on libhybris and one on x11
<ssvb>
one on libhybris, and one on x11
<libv>
ok... so the libhybris story failed to mention this also being possible on plain x11
<libv>
how does the performance of the two compare?
<vgrade>
not good
<libv>
my guess, pretty bad, as it seems we are always copying on xf86-video-mali
<libv>
did anyone try using fb?
<vgrade>
not fb
<libv>
any technical reason for that?
<vgrade>
no
<libv>
well, give it a go, it is just running 'make config EGL_TYPE=framebuffer' in sunxi-mali
<libv>
and then a make install ofcourse
<vgrade>
I will make a new package in Mer OBS
<ssvb>
my understanding is that vgrade is mostly trying to test libhybris as a universal solution for any GPU and also for enabling wayland
<ssvb>
that's why testing and fixing libhybris performance issues is important
<libv>
it can be a short term solution only
<libv>
just like with firefoxos and ubuntu phone
<ssvb>
it depends
<libv>
really?
<libv>
it's just a matter of time
<libv>
soon one of the vendors will fall
<libv>
and some others will follow
<libv>
actually, nvidia will fall soon
<libv>
ssvb: you should know, apparently, as some nvidia research guy very openly stated that at syysgraph
<vgrade>
libv: especially with great efforts of RE and libhybris putting pressured on
<vgrade>
wihtout that pressure we woud have the ststus quo
<libv>
vgrade: i do not see libhybris helping atm
<vgrade>
ok
<libv>
vgrade: especially on hw that has binary drivers, and with the other side being ignored
<libv>
vgrade: if a commercial entity like mozilla, canonical or jolla does it, then we can put that down to commercial pressures and blahblah
<libv>
but the open source folk should not occupy themselves with binary wrapper games and then try to sell it as "just as good as direct support"
<libv>
you might as well cut off your foot right now, the wound will be cleaner in the long run
<libv>
given that i made sure that sunxi-mali is useful today, and that i convinced mdfe to form the basis of what you worked off, this is especially, as the germans state it, "bitter"
<vgrade>
as I said above I take your point that using sunxi was a bad choice for me to test libhybris
<vgrade>
and I tried to give credit for the work I was using
<libv>
to what extent is libhybris still relevant, actually, nvidia tegra has x11 binaries, mali has many sets of binaries for different usecases
<libv>
freedreno is becoming almost useful
<vgrade>
there are still lots of cases I think where support is not complete in those, wayland for instance
<libv>
?
<libv>
and the solution that the android binaries and libhybris provide is...
<libv>
less hard to implement on the mali fb drivers?
<ssvb>
is odroid already providing mali fb drivers?
<libv>
ssvb: i think rz2k provided a howto for sunxi drivers
<libv>
ssvb: i think i remember r3p0 kernel support
<libv>
that means sunxi-mali should just work
<libv>
i should actually try that and see whether the command stream uses all PPs
<libv>
if not, the ioctl wrapper that achieves that is 200 lines.
<ssvb>
android is still the lowest common denominator no matter how you look at it
<libv>
ssvb: for those with unbelievably low standards and no hope or clue, yes
<libv>
but we've come a long way in the last two years
<libv>
and are not far away from our goal
<libv>
i really hate to see libhybris being used as a reason not to take provide some sort of open source strategy
<libv>
s/take //
<vgrade>
so you would need RE of all andriod blobs not only gfx
<vgrade>
to use any recent device
<libv>
vgrade: how does that tie in with wayland?
<libv>
vgrade: oh, and erm, amd just now provided uvd support
_BJFreeman has joined #linux-sunxi
<libv>
vgrade: now that they removed the prince of darkness and procrastination, john bridgman
<vgrade>
uvd?
<libv>
vgrade: 6ys ago, i was writing, together with egbert eich and matthias hopf, the document that AMD ended up following, the document with their open source strategy
<libv>
universal video decoder
<libv>
introduced in ati r600
<libv>
6y ago, give or take a few days
_BJFreeman is now known as BJFreeman
<ssvb>
yeah, that's good
<libv>
anyway, we'll always be disappointed
<libv>
but aim low, and achieve even less+
<libv>
so as for other blobs, what other blobs are there
<libv>
the big one is media
<ssvb>
I remember using ndiswrapper some years ago, just because otherwise wlan would not work
<vgrade>
wifi, gps, ril
<libv>
and guess what, it is not as big a stumbling block as 3d support
<ssvb>
now the wlan problem is more or less solved
<libv>
ssvb: because, or despite ndiswrapper?
<ssvb>
I don't think it was related
<libv>
ssvb: my feeling is that ndiswrapper slowed things down
<libv>
just like the competing amd video drivers made sure that neither properly supported all users.