<ganbold>
mnemoc: right :), so giving power to USB1 from u-boot and then set clock would be enough for initialization
<ganbold>
or I maybe missing something
<mnemoc>
ganbold: try on the mailing list. you'll find more people familiar with that stuff there
<ganbold>
ok
hg_5 has joined #arm-netbook
gimli has joined #arm-netbook
rellla2 has joined #arm-netbook
rellla2 has quit [Client Quit]
rellla has quit [Ping timeout: 245 seconds]
rellla has joined #arm-netbook
<provel_>
hum... is stage/sunxi-3.4 working? I should have missed something as it doesn't even boot... should I change boot.scr or script.bin when changing from 3.0 to 3.4?
<mnemoc>
no change required
<mnemoc>
sunxi-3.[04] and stage/sunxi-3.[04] branches are equivalent
<mnemoc>
uhm... still need to merge some edid/fbcon fix to the stage branches
* mnemoc
misses libv feedback
tinti has joined #arm-netbook
<provel_>
to use r3p1 drivers, should I use stage branches or plain 3.4 is fine?
oliv3r has quit [Ping timeout: 264 seconds]
<provel_>
moving from stage/sunxi-3.4 to plain sunxi-3.4 caused an oldconfig
<provel_>
for usb/otg
Kraln has joined #arm-netbook
eebrah has joined #arm-netbook
ganbold_ has joined #arm-netbook
<buZz>
i am trying to set my hdmi screen to proper edid mode with the staging sunxi-3.0 branch
<datagutt>
i should find out what codec the video i was trying to view uses
<datagutt>
mpeg-4 probably
<datagutt>
jerky playback sounds about right
pwhalen has joined #arm-netbook
<rellla>
gimli: but it was long time ago, they told you to fix it, right? seems neither you nor empat0 is doing any development at the moment, due to lack of a fixed library!?
<datagutt>
I bet they won't fix
<datagutt>
and just work on their closed a31
<datagutt>
^^
<rellla>
btw, yesterday it was the first time, i had a successful usage of xbmc on a10. watching tv over xbmc/pvr/vnsi - streaming from another a10. it was usable, and WAF wasn't that bad ;-)
<mnemoc>
nice :)
<gimli>
rellla: correct, the only thing we can do ist wait and hope :D
eebrah has quit [Ping timeout: 265 seconds]
mtndew420 has quit [Quit: worky time]
rellla has quit [Remote host closed the connection]
rz2k has joined #arm-netbook
lkcl has quit [Ping timeout: 255 seconds]
mikey_w has joined #arm-netbook
n6pfk has joined #arm-netbook
eFfeM has joined #arm-netbook
gzamboni_ has quit [Ping timeout: 276 seconds]
mikey_w has quit [Ping timeout: 245 seconds]
n6pfk has quit [Ping timeout: 252 seconds]
gzamboni_ has joined #arm-netbook
ZaEarl has joined #arm-netbook
Jef91 has joined #arm-netbook
ganbold__ has quit [Ping timeout: 276 seconds]
ganbold_ has joined #arm-netbook
Yaku has joined #arm-netbook
<Yaku>
hey there
ganbold__ has joined #arm-netbook
<Yaku>
i am currently eyeballing an rk3066 tab on aliexpress for 50$ but it gives me a scamfeeling since the shop does not have any sells yet
<mnemoc>
in the worst case you'll get a refund in 3 months
<mnemoc>
ali doesn't pay the sellers until you are happy
<mnemoc>
so it's not a useful place for scammers
<Yaku>
good to hear, there is a working 5$ voucher today for aliexpress as well
ganbold_ has quit [Ping timeout: 276 seconds]
<Yaku>
MAINAGAME5 <- for any purchase over 50$
<Yaku>
hmm and i just ordered an mk808B yesterday, 30 days processingtime on this tab :/
<jinzo>
indeed, aliexpress provides a escort service (it's actually mandatary) - so you just make sure you're paing thtough aliexpress and that should give you quite some protection
<mnemoc>
anything longer than 4 days means they don't have stock but hope a factory will send them some.... eventually
<Yaku>
ah, i think i leave it, i have my a2000 and my new stick propably isn´t a good idea to buy just because it´s cheap
<Yaku>
but it´s damn tempting for 45$ it´s even in the gift without vat area for the EU
<jinzo>
Yaku, at least here - the usually disregard that
<jinzo>
and you have to send them a reciept/some proof of purchase price
<Yaku>
yes, had to do that in germany sometimes but they only got the ones less then 10 euro, my mele was declared with 15$ by tom cubie bye the time :)
<jinzo>
yeah they probably only have time to check a limited number of those packages
<jinzo>
I also had success with UPS, that didn't even bother
<ssvb>
oh, sorry, it was techn_ and maybe mnemoc also knows something
eebrah has quit [Ping timeout: 272 seconds]
<mnemoc>
techn and rz2k are familiar with that stuff
datagutt has quit [Quit: kthxbai]
<ssvb>
well, looks like we may need a new ioctl for getting a secure id for ump, wrapping the whole framebuffer
<ssvb>
and this secure id must be different from the ones returned by GET_UMP_SECURE_ID_BUF1 and GET_UMP_SECURE_ID_BUF2, because the mali blob seems to interpret them in a special way and I can't seem to use them in any meaningful way
<mnemoc>
they are different. look at the last chunk of that commit
<ssvb>
I need a third ump secure id
<mnemoc>
send a mail to the linux-sunxi ML describing the problem
<ssvb>
ok, I'll just finish the driver first
<ssvb>
I just realized that I can't get rid of "[EGL-X11] [6281] DRI2 WINDOW UMP SECURE ID CHANGED (0x2 -> 0x2)" and "[EGL-X11] [6281] DETECTED ONLY ONE FRAMEBUFFER - FORCING A RESIZE" types of problems without patching the kernel
IEF has quit [Quit: brb!]
<mnemoc>
sun4i or sun5i?
<ssvb>
sun4i
<mnemoc>
weird
<ssvb>
mnemoc: it's not so weird, because I'm trying to implement an x11 ddx driver with zero copy for glesv2
<provel_>
ssvb: when you need testing..... :-)
<ssvb>
I just wanted to know if anyone ever had page flipping working with xf86-video-mali in X server, or maybe with the framebuffer targeting mali binary blobs
<provel_>
ssvb: I'd say yes, xbmc on framebuffer
<provel_>
doesn't consumes all the cpu of the memcpy
<ssvb>
provel_: does it use glesv2 for anything?
IEF has joined #arm-netbook
<provel_>
it was... but I think empatzero removed glesv2 a month ago
<provel_>
I check the renderer code
<ssvb>
aha, does it use disp layers now?
<ssvb>
I got the layers working, but still without scaling
servili007 has joined #arm-netbook
<ssvb>
the boring guesswork figuring out how to use disp ioctls by skimming through kernel sources
<provel_>
Yes I think is disp.... with m_scalingMethod = VS_SCALINGMETHOD_LINEAR
<ssvb>
sounds great, do you have a link to the sources?
<techn_>
ssvb: we asked that from arm.. and they said that they are the same
<ssvb>
techn_: thanks, it does not provide much of the details though
rellla has joined #arm-netbook
<techn_>
ssvb: yes :)
<techn_>
but still I dont understand your problem :/
<ssvb>
techn_: my problem is that if I give UMP_SECURE_ID_BUF1 or GET_UMP_SECURE_ID_BUF2 to mali blobs from DRI2 code, I can't get any reasonable behaviour out of it
<techn_>
and you'll need that different "#define GET_UMP_SECURE_ID _IOWR('m', 310, unsigned int)" ioctl?
<mnemoc>
still sounds whimpful :<
<ssvb>
techn_: mali blobs try to do something weird in addition to just damn rendering to this provided buffer
<ssvb>
techn_: see the log messages above about FORCING A RESIZE, etc
<techn_>
I havent seen those kind prints :/
<techn_>
where they are output?
<ssvb>
techn_: because you probably have not tried to use any arbitrary rectangle in the framebuffer memory as a rendering target for mali blobs
<techn_>
ssvb: how I can do that? :)
<ssvb>
techn_: implement your own x11 dxx driver? :)
<ssvb>
techn_: but in any case, I know how to solve this problem, it just needs a simple patch for the kernel
<techn_>
nice
<ssvb>
techn_: I just wondered if the current kernel code is considered to be correct :)
<techn_>
ssvb: no.. It's just done with those references
<ssvb>
fair enough
<techn_>
which are .. as you said "not much details" :p
<mnemoc>
ssvb: what about pointing at the repo of your dxx driver so others can try it and try to find the real issue?
<techn_>
anyway great that there is something what we can do to improve x11 support.. and someone is doing that :)
<techn_>
and found bottleneck? (hopefully software :)
<WarheadsSE>
I keep saying this but i need to get updated packages into the alarm repo for the sunxi
<ssvb>
techn_: with 1080p I suspect that there is some memory bandwidth starvation for hdmi scanout
<mnemoc>
WarheadsSE: do so :)
<ssvb>
techn_: the image on the screen is shaking when I'm running glmark2 in 1080p resolution
<techn_>
so it's disp problem? hw? :(
<techn_>
or just some stypid extra memcpy?
<mnemoc>
running it in more devices will discard hw problem
<provel_>
some sync missing?
<ssvb>
techn_: have you also observed similar effect?
<provel_>
android version is 1080p capable?
mdasoh_ has quit [Ping timeout: 276 seconds]
<techn_>
ssvb: no.. just wondering what's with xbmc 1080p rendering.. it's 28fps max
<rz2k>
ssvb: you've disabled scaler layer
<rz2k>
in .fex
<rz2k>
it is directly wired to vsync
<mnemoc>
provel_: android/sunxi runs fine at 1080p.... but they don't use X11
<rz2k>
I had same screen tearing effect with scaler layer disabled
<mnemoc>
provel_: not the same ioctl()s etc
<ssvb>
rz2k: yes, that's another different configuration to test and support :(
<ssvb>
rz2k: screen tearing for very demanding screen resolutions is not totally uncommon also for the other devices, for example pandaboards had some GFX FIFO UNDERFLOW issues
<ssvb>
rz2k: it might a a configuration issue, like setting right priorities for memory accesses from different hardware blocks or increasing some FIFO buffer sizes
<ssvb>
rz2k: if mali is starving the screen update, then mali might need to be given lower priority in the memory controller or something like this
mdasoh_ has joined #arm-netbook
servili007_ has joined #arm-netbook
<ssvb>
rz2k: about the "scaler mode" in fex, do you know what are the benefits/disadvantages?
<rz2k>
I know only that if it is enabled - you have vsync everywhere
<techn_>
ssvb: you'll loose different pixel depth support on framebuffer layer..
servili007 has quit [Ping timeout: 248 seconds]
<rz2k>
oh and that, VLC guy had something around there
<rz2k>
forcing him to turn it off
<techn_>
only argb32 and couple yuv modes are supported on scaler layer
<techn_>
we could have scaler and normal layers combined.. but that can't be done without proper benchmarkinking etc
<techn_>
since it could kill performance :/
<provel_>
? but the initial issue isn't that we miss performance ?
<ssvb>
techn_: my understanding is that there are two different things: "scaler mode" in fex and "scaled layers"
<techn_>
nice way to duplicate the logic when you have same information in multiple places :)
<ssvb>
techn_: so, what is the difference?
<ssvb>
techn_: my speculation is that "scaler mode" may affect the primary framebuffer, while the extra layers are optional and can be enabled/disabled
<rz2k>
ssvb:
<rz2k>
I've sent you a pm :)
<techn_>
maybe it was supposed to work differently.. but now there is no dual fb support.. I havent got even dual output working
<ssvb>
techn_: also the comments in the code say that a10 has two scalers, and a13 has only one
<buZz>
so A10 can have dual output?
<buZz>
awesome :O
<techn_>
ssvb: yes.. I have a10 device
<techn_>
buZz: Atleast in theory
<ssvb>
techn_: and if you have scaler mode enabled, there is no way to have a scaled overlay window on top of the normal framebuffer
<ssvb>
techn_: which would suck for Xv extension on A13 :)
<techn_>
ssvb: oh
<techn_>
forgot that there is only limited amount of them :(
<ssvb>
buZz: my Mele A200 has HDMI and VGA connectors, maybe I can try to plug two monitors to it some day
dyoung-away is now known as dyoung
mdasoh_ has quit [Ping timeout: 265 seconds]
<buZz>
well it would be awesome if A10 could do dual
<buZz>
i would love HDMI + CVBS :P
<buZz>
cause then i can use A10 in a VJ setup, instead of or complimenting my c2d dell