<L84Supper>
isn't Ubuntu still pretty close to Linux? :)
Avernos has joined #arm-netbook
Avernos has joined #arm-netbook
alcides has quit [Quit: > SELECT * FROM users WHERE clue > 0]
Avernos_ has quit [Ping timeout: 256 seconds]
Avernos has quit [Read error: Connection reset by peer]
Avernos has joined #arm-netbook
Avernos has quit [Changing host]
Avernos has joined #arm-netbook
L84Supper has quit [Quit: <puff of smoke>]
Avernos_ has joined #arm-netbook
Avernos has quit [Ping timeout: 256 seconds]
stefanro1 has joined #arm-netbook
stefanro has quit [Ping timeout: 252 seconds]
L84Supper has joined #arm-netbook
Avernos_ has quit [Read error: Connection reset by peer]
<hramrach>
ssvb: anyway, if it was abuse of DRI2GetBuffers this hack should fix it but it does not for me: http://hpaste.org/82659
<hramrach>
this is the place where the buffers get deallocated
<hramrach>
DRI2GetBuffers has not format information so sets format to 0 which does not match any actual format
<hramrach>
this would also mean that the description in that email is incorrect becasuse ony attachments requested get allocated/re-allocated
<ssvb>
hramrach: yes, the format field is simply not used
<ssvb>
what exactly is incorrect?
Avernos has joined #arm-netbook
Avernos has quit [Changing host]
Avernos has joined #arm-netbook
<ssvb>
DRI2GetBuffers seems to be rather loosely defined, it has fields as "name" (actually gets used to store the secure id) and "flags" (actually gets used to store the offset in UMP buffer)
<ssvb>
how to interpret these fields is left to the DDX and the actual client application (mali blob)
<hramrach>
yeah, the format is passed verbatim to MaliDRI2CreateBuffer which just saves it so the actual buffer info will have 0 there
<hramrach>
so where is the logic that destroys the buffer on MaliDRI2CreateBuffer?
<hramrach>
when the buffer was allocated with DRI2GetBuffers rhather than DRI2GetBuffersWithFormat?
<ssvb>
that's a good question, I did not look that deep into the x server sources
<hramrach>
because the two do exactle the same thing except DRI2GetBuffers fills format with 0
<hramrach>
it would have to be in MaliDRI2DestroyBuffer presumably
<ssvb>
this code destroys the existing buffers and replaces them with the newly created ones
<ssvb>
hramrach: however even if you hack the x server to tweak this behaviour, some support code for correctly swapping buffers is still needed in the DDX
<hramrach>
but regardless of WithFormat
<hramrach>
yes, that part destroys the buffers but it does so on any GetBuffers* call afaict
<hramrach>
the ddx is out of that
<ssvb>
that part should somehow call ddx to do the real buffers destruction job
<hramrach>
It does
<ssvb>
in any case, I think that we have to add some hack to ddx in order to override the things done in "hw/xfree86/dri2/dri2.c" and manage the buffers the way how it is expected by the mali blob
<hramrach>
it calls MaliDRI2DestroyBuffer
<hramrach>
and how it is described in that mail with new protocol description
<hramrach>
or what does it say, exactly?
<hramrach>
that you can request buffers
<hramrach>
but not what will happen to buffers you have already requested
<ssvb>
that mail was a proposal for this new function, maybe it was changed before this code got committed
<ssvb>
it looks like DRI2GetBuffersWithFormat is not going to help us in any way
<hramrach>
it does not really say anything one way or the other, either
<hramrach>
there is just no description of these functions
<hramrach>
they just do someting DRI specific which is tightly coupled with the Xfree DDX drivers
<ssvb>
or actually it's the buffers reusing logic
<ssvb>
we may try to trick it to use the old buffer in the right way
<hramrach>
you could just return the old buffers
<hramrach>
which the function presumably does if hte format matches
<hramrach>
so it probably thinks it does not for some reason
<ssvb>
we want DRI2BufferFrontLeft to be reused, and the DRI2 code has an explicit check to make sure that it gets reallocated
cnxsoft has joined #arm-netbook
<hramrach>
it has an explicit check to make sure one is present
<hramrach>
but if there is any logic it should either
<ssvb>
if "attachment == DRI2BufferFrontLeft" then it calls create_buffer instead of reusing the old one
<hramrach>
oh, indeed
<hramrach>
it tosses the front buffer every time you request any buffer
<hramrach>
sounds awesome
<hramrach>
while(1) GetBuffers ..
<ssvb>
we can try to add a hack to reuse the old DRI2BufferFrontLeft buffer from MaliDRI2CreateBuffer :)
<ssvb>
so if we are requested to create DRI2BufferFrontLeft, just check the list of existing attachments for the drawable, find the old DRI2BufferFrontLeft buffer and return it
<ssvb>
this might work
<hramrach>
I tried removing the frontleft check in X server
<hramrach>
does not seem to help
<ssvb>
does not help to what?
<hramrach>
flashing in gnome-shell
<ssvb>
that's because the ddx is missing the correct buffers swap logic
<ssvb>
it currently just provides the same buffer for both front and back
<hramrach>
ah
<ssvb>
I'll try to add the needed changes to DDX, and also the hack to prevent DRI2BufferFrontLeft reallocation so that x server patching is not necessary
<ssvb>
but tomorrow, now I need to go to bed
<hramrach>
good night :)
<ssvb>
:)
Avernos has joined #arm-netbook
Avernos has joined #arm-netbook
Avernos has quit [Changing host]
Avernos_ has quit [Ping timeout: 255 seconds]
Avernos has quit [Read error: Connection reset by peer]
Avernos has joined #arm-netbook
Avernos has joined #arm-netbook
Avernos has quit [Changing host]
stefanro1 has quit [Ping timeout: 252 seconds]
stefanro has joined #arm-netbook
XenGi is now known as XenGi_
Eigen_ has quit [Remote host closed the connection]
<jelly-home>
libv: an ubuntu dev tells me the thing runs an ubuntu kernel, not the android one
<jelly-home>
well, he also says the whole thing is open source and I specifically noted the hw is tegra 3
<jelly-home>
and that providing source for drivers would be a very significant move for nvidia
<jelly-home>
we'll see
<traeak>
ouya hardware
<libv>
jelly-home: open source drivers will not happen on their own, nvidia will not do that out of the blue
<libv>
jelly-home: the question is, are there proper gnu/linux tegra3 drivers or not
bfree has joined #arm-netbook
Eigen has quit [Remote host closed the connection]
<libv>
i would really be amazed if there were proper gles drivers for gnu/linux falling out of ubuntu
<libv>
i still have to see solid gnu/linux mali binaries for the snowball and the origen
<libv>
i have not managed to find any for the exynos based origen for instance
<jelly-home>
well -- I trust him about the kernel part, and will wait to see what comes on top of that
<libv>
i think that they might be running the chromebook exynos5 gles drivers
<libv>
for the nexus10
<jelly-home>
10" is exynos5?
* jelly-home
only looked at nexus 7 specs
<mnemoc>
yes
<mnemoc>
like the chromebook, but with better display :|
<jelly-home>
Re: displays. HTC's new phone has effin 469dpi
<jelly-home>
468* but... what
<mnemoc>
and laptops are stuck at 1366x768, and LCDs at 1920x1080 :<
<jelly-home>
ok, they're starting to put 1920 in 13" ultrabooks as well
<traeak>
that's brutal at that resolution
<mnemoc>
N133HSE-EA1 is 13.3" and 1080p for ~400 yuan on taobao
<traeak>
i guess tons of upscaling
<traeak>
or whatever it is (big fonts)
<mnemoc>
N116HSE-EA1 is 11.6" and 1080p for mostly the same price
<mnemoc>
and why the *censored* they keep using 1366x768?!
<jelly-home>
it's cheeeeep
<mnemoc>
those panels above cost less than $70
<jelly-home>
I'm staying away from laptops ever since they all got 16:9 screens; 16:10 was barely passable
<traeak>
why not passable?
<jelly-home>
too little vertical space, or too small pixels for my myopic eyes
<traeak>
for my tastes it's wide enough for 2 side by side xterms
<jelly-home>
not wide enough was never the issue for me; 1024x768 was wide enough for a 132x48 term
<traeak>
80 columns wide :-p
<traeak>
you're wasting 52 columns
<traeak>
hehe
<libv>
how hard would it be to have unity talk to surfaceflinger?
<libv>
"Ubuntu has already been adapted to run on chipsets using the ARM and Intel x86 architectures relevant for mobile devices, with the core system based around a typical Android Board Support Package (BSP)."
<libv>
so android underneath, no proper gnu/linux drivers, still bionic and its insane loader
<mnemoc>
chroot saves you from bionic
<libv>
but that does not get you working drivers
<mnemoc>
:<
<libv>
and i really really doubt that they forgo hw accel
<libv>
not on this hw, not in this market
<libv>
so i really do think that they have bolted themselves on top of surfaceflinger
<libv>
"android board support package", that, to me, translates to "EGL is whatever android does", so surfaceflinger
abesis has joined #arm-netbook
<jelly-home>
eh
<jelly-home>
but that's ubuntu phone. Maybe ubuntu tablet is completely different...!
anunnaki has joined #arm-netbook
j1nx_ has joined #arm-netbook
<j1nx_>
Hi there guys
<j1nx_>
can we buy an EOMA card already? :D
XenGi_ is now known as XenGi
<mnemoc>
j1nx_: no
abesis has quit [Read error: Connection reset by peer]
<w00tc0d3>
any CyanogenMod requests for a phone here?
XenGi is now known as XenGi_
<jelly-home>
w00tc0d3: what?
<w00tc0d3>
jelly-home: if you have an Android phone, which needs CM. Tell me :)
<jelly-home>
oh! Thanks I guess
abesis has joined #arm-netbook
<j1nx_>
I just sended a question to the arm-netbook mailing list about CMDLINE_EXTEND
<j1nx_>
Anybody in here who can help me out a bit?
dyoung-away is now known as dyoung
* Turl
didn't get any email from arm-netbook
<j1nx_>
hmm
<j1nx_>
Might still be bouncing around in virtual space
eebrah has joined #arm-netbook
abesis2 has joined #arm-netbook
abesis has quit [Ping timeout: 248 seconds]
focus_it has joined #arm-netbook
wingrime has quit [Ping timeout: 272 seconds]
<libv>
jelly-home: apparently ubuntu for tablets will need a dual A15 minimum
<libv>
jelly-home: and here i was thinking that the nexus7 had a quad a9
eebrah is now known as eebrah|away
<Turl>
libv: how can they 'require' a dual A15?
<libv>
beats me
<libv>
any a15s shipping apart from the exynos5?
<Turl>
OMAP 5 on Q2 2013
<Turl>
2.0 GHz Dual-core ARM Cortex-A15 + Two Cortex-M4
<libv>
i worked with the early panda 5 over the summer
<libv>
customer was told it was a quadcore... *sigh*
<mnemoc>
do they sell omap4 openly yet?
<libv>
don't think so
<Turl>
it is, you just don't use the 4 cores simultaneously I guess
<libv>
Turl: the m4s are used for media stuff
<Turl>
libv: hm, not big.LITTLE?
<anunnaki>
sorry to jump in your convo. but is there a minimum for adding a touchscreen
<libv>
Turl: yup, no big.little
<libv>
and then ti decided to leave the mobile marked
<Turl>
libv: fwiw, T3 is a penta cortex A9
<Turl>
it just has one crippled core at 500mhz
<libv>
but doesn't officially meet the ubuntu minimum specs
<Turl>
anunnaki: hm?
<anunnaki>
like would a small touchscreen work well on a rpi or is the processor not powerful enough
<anunnaki>
or does it not matter
<Turl>
anunnaki: depends on what touchscreen technology
<Turl>
usually they have a separate processor and you just read the (x, y) values on the device
<Turl>
libv: you need a Nexus 10
<Turl>
and it has mali ;)
<RaYmAn>
Turl: it also has a ARM7TDMI core, so 6core? ;)
<libv>
Turl: i will order myself a chromebook in a few weeks
<libv>
just to get one before they run out
<anunnaki>
Turl, oh neat.. didnt know they have their own. a little lcd screen like beaglebone has would be cool but i rather touch capabilities
<Turl>
RaYmAn: and a powervr, and a BP if you choose the 3G one
<libv>
still have too much mali-400 stuff to do
<RaYmAn>
Turl: powervr?
<Turl>
RaYmAn: err sorry, was thinking of sth else
<libv>
which reminds me, i was cleaning up mali-libs
<Turl>
tegra has... tegra
<RaYmAn>
indeed
j1nx_ has quit [Read error: Connection reset by peer]
<libv>
mnemoc: what should i do with these changes, push them directly, or toss them in a branch first?
<traeak>
wierd, how does ubuntu enforce a15? special instructions that a9 doesn't have ?
<mnemoc>
libv: `make install` changes? maybe tag first and push after?
<roxfan>
cpuid check!
<RaYmAn>
traeak: given they only seem to give it to partners, they probably enforce it contractually :P
<libv>
ok, so just a tag will suffice for you?
<libv>
or should i push to a repo of my own to get people to have a look over it?
<libv>
traeak: they are demonstrating it on a tegra3 based nexus 7, so the a15 requirement is quite bogus
eebrah|away has quit [Ping timeout: 252 seconds]
<libv>
techn_: please do not do merges for single commits with no complicated histor
<libv>
especially not for one which i do not find overly useful, and which probably would not have been a problem if there was an x11 test out in the public already, which there will be soon
<mnemoc>
libv: I'm happy with the tag
<RaYmAn>
I guess a15 might be requirement for their target performance levels
<libv>
ok
<libv>
mnemoc: what should the tag be to make sense in the sunxi ecosystem?
<libv>
mnemoc: also, how do you want me to handle the deprecation of the separate libump repo?
<mnemoc>
people loves date based tags/releases (like 2013.2) these days
<libv>
for whatever good those are :)
<libv>
ok
<mnemoc>
:p
<mnemoc>
git tag -a 1 ?
<libv>
actually, it makes sense to tag the commits i made back in november
<mnemoc>
fine with me
<libv>
the one commit up there, which i made last week, was really the snowball that started the current avalanche
<mnemoc>
regarding the libump deprecation... that might deserve a temporal branch and some mail expailing it
<mnemoc>
libump separated repo I mean
<traeak>
libv figured so. also means it shoudl run fine on a cortex a7 as well
<mnemoc>
i'm somehow not inclined to mix closed source with free software in the same repos. but as libump is also from arm and we need tighter integration to get the whole thing working...
<libv>
well, the only thing that made sense was to fold it into the mali-libs repo, so that the umpblobs vanish, and all can get installed coherently with little extra overhead and little chance of mess-up
<libv>
yeah, i know, this is the one thing that i find non-ideal here
<libv>
but the benefits far outweigh that awkwardness
<libv>
and the free code has nice headers
<mnemoc>
what about getting mali-libs as a submodule inside a rename of libump's repo?
<libv>
the status of the binaries is very unclear as well
<libv>
it'll have to be more than a rename.
<libv>
let me clean up my stuff, and push it out to a personal repo so you can see what happened
<mnemoc>
i mean rename to not lose the history
<libv>
there is little history
<libv>
there basically are 2 libump versions
<mnemoc>
so, what about a new sunxi-mali including the blobs as a submodule, building and installing the whole
<mnemoc>
would that carry much awkwardness?
<libv>
yeah, that indeed makes the most sense
<libv>
clone mali-libs into sunxi-mali, then throw out the binaries and add a submodule, then my upcoming changes
<libv>
we should've done this in november, but hindsight and such
<mnemoc>
if we start sunxi-mali from mali-libs history will include proprietary poison
<libv>
ok, will recycle my november commits as much as possible
<libv>
mnemoc: can i create that repo, or do you need to do so?
<mnemoc>
i believe you should be able to
<libv>
ok, seems like we have a plan then :)
<mnemoc>
yeah :) and as git lets you export commits as files recycling history shouldn't be hard
* mnemoc
loves how easy is to commit VCS heresy with git :p
abesis has joined #arm-netbook
<mnemoc>
sanctity of timeline is... bornig :p
<mnemoc>
boring*
abesis2 has quit [Ping timeout: 255 seconds]
<libv>
mnemoc: should we, while we are at it, rename mali-libs to sunxi-mali-proprietary, and deprecate mali-libs entirely as well?
<libv>
since we are messing everything up anyway
<mnemoc>
libv: fine with me
<mnemoc>
sunxi-bsp will need to be adjusted for the new sunxi-mali anyway
<mnemoc>
techn_: ---^ comments?
<libv>
ok, so creating two new repos, one with the libs and the bottom end of the build system which will not be useful on its own, and a README at the top end
<libv>
and the other with some cherry picks of the existing mali-libs, and the end result will be like what i currently have here locally, but with lib/mali/ a submodule
merbzt has joined #arm-netbook
alcides has joined #arm-netbook
<mnemoc>
libv: :)
<libv>
rz2k has been spreading some howtos for using our mali libs for the odroid, so he will have to go and update those as well
<libv>
i am not sure how the android guys are dealing with sunxi stuff atm
<mnemoc>
Turl: ---^ ?
<libv>
let me push my current tree out to a repo of my own, a repo that i will destroy once everything is in place
<mnemoc>
please don't delete the "old" mali-libs yet
<libv>
i will not
<libv>
i will also not remove those repos
<mnemoc>
great
<rz2k>
libv: odroid no longer uses our stuff
<rz2k>
they have automated installer
<libv>
ok
<libv>
mnemoc: by deprecating i mean would empty out the tree in a commit to master and put a README.deprecated in there pointing to the real repo
<libv>
s/would //
<ibot>
libv meant: mnemoc: by deprecating i mean empty out the tree in a commit to master and put a README.deprecated in there pointing to the real repo
<mnemoc>
sounds good
<libv>
i am going to kill the github.com/libv/mali-libs repo i am about to create though :)
<Turl>
libv: we use proprietary repos with cool makefiles, any change to those repos won't affect us
<libv>
mnemoc: i will deprecate the mali-libs repo though
<anunnaki>
tzafrir_laptop, depends on your definition of "proper" but i believe there is a video on youtube with a guy running ubuntu on his mk802
<libv>
so master from there will only contain a README
<libv>
mnemoc: how are you dealing with libump.so atm?
<tzafrir_laptop>
anunnaki, for starters, have proper kernel source.
<mnemoc>
cp :<
<mnemoc>
which is broken, i know
<libv>
libump.so was removed from mali-libs
vinifm has joined #arm-netbook
<hramrach>
I run debian on cubieboard ;-)
<libv>
as it was not working for r3p0/armhf/x11
<mnemoc>
submodules are bound to certain commits, not branch heads
<mnemoc>
and hasn't been updated in a while
<tzafrir_laptop>
anunnaki, "mk802 III", "mk806" and such similar names.
<mnemoc>
but will need to find a way to cross compile libump.... yuck
<hramrach>
it has almost no dependencies
<hramrach>
and you can qemu-compile
<libv>
mnemoc: i am rather amazed, as r3p0/armhf/x11/libUMP.so and r3p0/armhf/x11/libMali.so were not good matches
<libv>
it might have been the faking of the X11 linking that was the issue
<libv>
in any case, direct copy of those would not result in decent working EGL/GLES system
<anunnaki>
tzafrir_laptop, well some of those are newer than others so I wouldnt expect much progress on the newest ones. I want to know the answer to that myself with the MK802IIIS.
<mnemoc>
libv: yes, i agree the concept is broken
<libv>
plus, well behaved X apps deadlock and other stuff on the libMali.so which is out there