<mevon>
"Error cannot determine sdcard-dev from uboot-dev -"
<mevon>
i dont know much about .sh scripts
<mevon>
but i would like to hardcode the /dev/sdd
<mevon>
as UBOOT_DEV
<mevon>
nut i dont get the UBOOT_MOUNT part
<mevon>
exits at line 68 in select-board.sh
<user_2>
rellla, yes?
<rellla>
user_2: i created an issue for the damn blueish xbmc bug. do you also want to take a look into source code, to find the issue? ;)
wingrime has joined #linux-sunxi
<user_2>
rellla, unfortunately my capability to code is near zero :-(
<rellla>
mine too ;)
FR^2 has joined #linux-sunxi
<oliv3r>
rellla: is it an XBMC specific bug"
<oliv3r>
rellla: do we have a bootable xbmc sd image? :)
arete74 has quit [Ping timeout: 264 seconds]
<rellla>
oliv3r: i assume it is. no problems in vlc, and it is "fixable" by restarting xbmc. i think some initing or freeing goes wrong or misses. but i have no clue with color issues.
<rellla>
since about half a year i plan to make an image
<rellla>
maybe there you can find some working images: http://linux-sunxi.org/More-images - but i don't know something about the release date.
<rellla>
user_2: native libvecore.so or via libhybris?
<rellla>
and am i right, that only video is blueish, not gui!?
<wingrime>
Trul: ping
Black_Horseman has quit [Remote host closed the connection]
<oliv3r>
hello wingrime :)
<oliv3r>
wingrime: you really gonna do axp driver? Lots of work, but if you do, it would be awesome of course
<mripard>
wingrime: hi
<mripard>
wingrime: you had a question for me last evening?
<rellla>
as Brodomir asked on the ml, would it be (easily) possible to make some of these displays (http://www.hotmcu.com/lcd-displays-tft-lcd-c-6_16.html) work on the cubieboard? i never came in touch myself with lcds/lvds ....
A70X has joined #linux-sunxi
<wingrime>
mriprd: yes
<wingrime>
mriprd: such ic like axp must go to drivers/mfd
<wingrime>
mriprd: but it have side effects
<mripard>
which ones?
<wingrime>
mriprd: no modules
<oliv3r>
rellla: no clue but olimex sells LCD's for their boards, so why not?
<wingrime>
mriprd: becose core mfd device must export api for "sub drivers"
<mripard>
?
<wingrime>
mripard: take look at any driver in mfd
<mripard>
are you sure? all the drivers in drivers/mfd are shown as tristate, so they should be compilable as module
<wingrime>
mripard: i see that all drivers in mfd are have some like subsys_initcall
<wingrime>
mrupard: that can't be module
<wingrime>
mripard: good example 88pm860x-core.c
<mripard>
I don't know, I'm looking at pcf50633, and it seems "modulable" to me
hramrach__ has quit [Ping timeout: 240 seconds]
slapin_nb has quit [Ping timeout: 264 seconds]
slapin_nb has joined #linux-sunxi
<wingrime>
subsys_initcall(pcf50633_init); <- can this be module ?
<mripard>
see, 88PM860X is listed as a bool, not a tristate
<mripard>
so I suspect it can't be a module for some reason
<mripard>
maybe it has to be there at boot or the kernel won't work or something
<wingrime>
mripard: no, it becose driver exports api for slave drivers
<wingrime>
mripard: for example axp must export axp_read_reg and axp_write_reg
<wingrime>
slave devices can be modules
<wingrime>
i think (not sure still)
<mripard>
I don't see why you should export functions
<wingrime>
EXPORT_SYMBOL_GPL(pcf50633_reg_read);
<mripard>
slave devices will call the usual irq/gpio/whatever functions
<oliv3r>
that looks like a nasty driver to me
<mripard>
yeah, they do it
<wingrime>
mripard: atomic!
<mripard>
but I see no reason for *you* to do it
<mripard>
atomic?
<mripard>
like, in an irq context?
<wingrime>
yeax
<wingrime>
critical section
<wingrime>
mripard: and don't forget we need handle bunch irqs from axp
<mripard>
you can most of the basic frameworks in an interrupt context
<mripard>
they seem to have splitted the driver in several places
<mripard>
which is why it is exported presumably
<wingrime>
axp-input,axp-regulator,axp-battary
<wingrime>
minmal set
<mripard>
but looking at random drivers without any context is not very efficient
<mripard>
and that can be a single driver
<wingrime>
mripard: but still, will this aproved
focus_it has joined #linux-sunxi
<mripard>
the only way to find out is to actually write it and get review
focus_it has quit [Read error: Connection reset by peer]
focus has quit [Quit: Ex-Chat]
focus has joined #linux-sunxi
<mripard>
you can't expect to do it write the first time
<mripard>
ouch
<mripard>
s/write/right/
<mripard>
so, do something, whatever you like most, send the patches, and we'll start the discussion from there :)
<wingrime>
mripard: also don't forget we must have reset and poweroff stuff exported using EXPORT_SYMBOL_GPL
<wingrime>
mripard: and this make this driver automaticly non-module
<mripard>
you don't have to export it for reset
<mripard>
just to set the arm_pm_restart callback
<mripard>
and I would like to not worry about restart/poweroff for now
<mripard>
it's tricky to do it properly
<wingrime>
mripard: that callback can use input device for it?
<wingrime>
mripard: I think we need axp-input for powerbutton
<wingrime>
oliv3r: it seems to be more complex driver that a thinked bevore
<wingrime>
oliv3r: how you sid driver?
<mripard>
wingrime: hmm, you can do the poweroff actually, it's the reset I'm more concerned about
<wingrime>
mripard: with dealy and without, soft and hard reset
soul has quit [Ping timeout: 256 seconds]
<wingrime>
mripard: regulator part can be sended in different patch set, I think about mostly for first version with axp-input and axp-batt (show power source and procentage) )
<oliv3r>
wingrime: it's a very simple driver that took way more effort then imagined :)
<oliv3r>
wingrime: i would try something extremly simple, like IR :)
<wingrime>
oliv3r: basicaly not difficult , but complex
<oliv3r>
a lot of work
<oliv3r>
and if you never done a mainline driver, it may be a bit daunting :)
<oliv3r>
I know your smarter then me, but I wouldn't try something that big first, small drivers first ;)
<wingrime>
oliv3r: It can be simple in first version
<oliv3r>
true true, still it's a complex driver
<oliv3r>
but now, i first gotta shop for some lio AA batteries :)
hramrach__ has joined #linux-sunxi
Soru has joined #linux-sunxi
<mripard>
wingrime: yeah, I'd agree that the regulator part can be sent later
<mripard>
especially since we have no driver that might use it for now
<wingrime>
mripard: mripard: also I have no idea how handle problem evnets like pwm voltage low that setted
<mripard>
hmmm, I don't understand what you mean, sorry :S
<wingrime>
mripard: axp can send irq in many cases
<wingrime>
mripard: if configured voltage low that expected
<wingrime>
mripard: can single patchset touch different kernel subsystem?
<hno>
wingrime, yes, but only when needed.
<wingrime>
hno: axp driver will be more complex that expected so , core driver must go to mfd , input-button to input , batt/charger to power
<oliv3r>
that will be a patch-set
<oliv3r>
1 patch per subsystem you touch
<hno>
err. a patchset can cross as many subsystems as desired. Individual patches should be split to make them reviewable and bisectable.
<hno>
yes
<mripard>
wingrime: MFD means multi-function device drivers, so anyway, I guess all the features can go only to drivers/mfd
<hno>
quite often more than one patch per subsystem.
<mripard>
but yes, otherwise, split nicely your patch with the rule "do only one thing in a given patch", and that's it
<wingrime>
I would decide it before I will have to send v2 or v10 version
<wingrime>
mripard: and I actualy can do poweroff with axp , how it will be suported by march-sunxi >
<wingrime>
&
_BJFreeman has joined #linux-sunxi
<wingrime>
mfd can support it using export symbol
<hno>
wingrime, start simple and work up from there. Send for rfc when you have something basic working. Expect a number of rounds before done.
_BJFreeman is now known as BJfreeman
<hno>
almost nothing gets done right on first attempt, and much easier to have a dialogue while fitting the things together than a full scale review whe you think you are done..
<mripard>
wingrime: just like you have a arm_pm_restart hook, you have a pm_power_off callback that you can set.
<mripard>
but like hno is saying
<mripard>
start simple.
<mripard>
don't try to support every thing, in every cases
<mripard>
have a small driver that have a few features first
<wingrime>
hno:agree so I think only mfd-core(with axp_read_reg and axp_write_reg exports ) + axp-battery (simple procentage and voltage monitor)
<wingrime>
mripard:^
<mripard>
this will allow to figure out stuff like in which folders should it go, etc
<mripard>
and then, build on top of that
<hno>
wingrime, and start early on the cover letter explaining what the patchset is about and your intentions.
<wingrime>
hno: I should cc-ed it to mtd and power mail-lists and linux-sunxi ?
<oliv3r>
mfd*
<oliv3r>
+ each subsystem maintainer
<oliv3r>
but the very first RFC, i would only send to linux-sunxi :p
<hno>
mtd?
<hno>
RFC to the lists I think. To maintainers when time for review.
<wingrime>
mfd
atiti has joined #linux-sunxi
hipboi has quit [Quit: Leaving]
dragonn has joined #linux-sunxi
notmart has joined #linux-sunxi
notmart has quit [Changing host]
notmart has joined #linux-sunxi
A70X has quit [Quit: Page closed]
jemk has joined #linux-sunxi
<wingrime>
jemk: are you finished your exams
<wingrime>
?
<jemk>
wingrime: not yet, but i try to work on cedar too
<wingrime>
jemk: I have find more one reg for mpeg
<jemk>
where did you find this startcode register? i've never seen it in traces?
<oliv3r>
Thanks to rz2k for setup and hosting the torrent! The link is from A20 Wiki page on our web.Thanks to rz2k for setup and hosting the torrent! The link is from A20 Wiki page on our web.
<wingrime>
oh funny
<wingrime>
google aps included
<wingrime>
oliv3r: look like our nand is realy IP
<oliv3r>
wingrime: what do you mean? libnand sources where released even for a20 a few weeks ago
<oliv3r>
this torrent may hold old data
<oliv3r>
we have the kernel for a20 allready anyway
<wingrime>
good
<oliv3r>
and boot0/1 sources too :)
<oliv3r>
we only really need a usermanual
<wingrime>
but what a hell thay done that crap like libnand
<jemk>
wingrime: what libvecore do you use? either we have a difference in chips or in libvecore
<jemk>
diff shows only difference are the extra startcode searches
stekern has quit [Ping timeout: 264 seconds]
<wingrime>
jemk: that preinstalled by installer
<jemk>
md5sum?
<wingrime>
jemk: I mean from linux sunxi
<wingrime>
but we have only one imge for linux-hf
<jemk>
i've seen at least two
<wingrime>
a10 and a13 have differnecs indeed
<wingrime>
jemk: how my tool for scritp clean?
dragonn has quit [Remote host closed the connection]
<jemk>
needs to remove the address too to make diff useful
<wingrime>
this easy
<wingrime>
jemk: I thinking also about IRQ flags
<wingrime>
jemk: blob and driver use 0x7c mask for irq set
<wingrime>
jemk: and for clean pending
stekern has joined #linux-sunxi
<wingrime>
jemk: I have idea that cedar can work like dma with shadow regs set
<wingrime>
jemk: I mean, after you configured engine registers
<wingrime>
jemk: And lauched , you can load new register set before cedar finished word
rellla2 has joined #linux-sunxi
<wingrime>
you only need wait registers movig to shadow registers
<jemk>
wingrime: possible, but i don't really believe that
dragonn has joined #linux-sunxi
<jemk>
rellla: is there any player able to use the newest libhybris libvecore from your repo?
<jemk>
with vlc some fbm_ symbols are missing
<wingrime>
jemk: I wan't use something different that vlc
<wingrime>
it drop frames
<wingrime>
with tracing
ykchavan has quit [Read error: Connection reset by peer]
<wingrime>
jemk: are you have any idea what NFC means?
<jemk>
no
<hramrach__>
wingrime: it's eg. a bus somewhat like spi/i2c/..
<wingrime>
jemk: also I have ask you about join some forgotten bits form old regs page
<wingrime>
jemk: maybe I forgot but I defently saw something around need moving
<rellla>
jemk: i didn't test it till now
<rellla>
jemk: did you use ssvb's linhybris branch?
<rellla>
*libhybris
<jemk>
rellla: no, i only used the files from your repo and it worked after some manual work except missing fbm_alloc_yv12_frame_buffer
<jemk>
maybe i didn't quite understand what libhybris does, but it seems it is already done there
<hramrach__>
actually the register name is spelled NCF in another place which is another un-helpful acronym
<jemk>
wingrime: o.o strange things happen there in your trace, but it seems i can't reproduce them because it's really a13 (and higher maybe) specific
<hramrach__>
but M-NCF is some mpeg related acronym, apparently
bfree has joined #linux-sunxi
<wingrime>
jemk: when you begin implement mpeg12 poc?
<wingrime>
ssvb: ping
<hramrach__>
actually amybe it gets close to mpeg due to alphabetical sorting
<mripard>
I need to look into this, I don't have time right now, I'm busy doing something else, sorry
<oliv3r>
mripard: no problem
<oliv3r>
but that's what i wrote :)
<oliv3r>
including my driver adaption
<oliv3r>
mripard: but go do things now :)
<oliv3r>
Turl: ! :p ^
<oliv3r>
oh bah, my git diff shows my changes + greg's :S
<oliv3r>
no, i lie, it didn't
_whitelogger_ has joined #linux-sunxi
fredy_ has joined #linux-sunxi
heffer has quit [*.net *.split]
fredy has quit [*.net *.split]
_whitelogger has quit [*.net *.split]
grevaillot has quit [*.net *.split]
fldc has quit [*.net *.split]
fredy_ is now known as fredy
fldc has joined #linux-sunxi
ibrah_ has joined #linux-sunxi
_whitelogger__ has joined #linux-sunxi
dl9pf has joined #linux-sunxi
\\Mr_C\\ has quit [Ping timeout: 276 seconds]
<user_2>
<rellla> and am i right, that only video is blueish, not gui!? <--- yes, only video/movie is bluish, gui is normal.
davidgol has quit [Quit: Page closed]
rz2k has quit [Quit: time to go home]
_whitelogger_ has quit [*.net *.split]
soul has quit [*.net *.split]
dl9pf_ has quit [*.net *.split]
atiti has quit [*.net *.split]
steev has quit [*.net *.split]
ChanServ has quit [*.net *.split]
atiti has joined #linux-sunxi
<rellla>
i compiled xbmca10 for debian wheezy against new cedarx sources/libs. if anybody is interested, i will upload somewhere. can't test it myself atm...
user_2 has quit [Read error: Connection reset by peer]
<zeRez>
just a polite question about lima project, how good is it running at the moment? i think about to buy a cb or the cubietruck when released, but iam a lil bit afraid of the performance from mali cause there are only reversed drivers !?
<zeRez>
"The Lima driver currently only has some preliminary and highly experimental support. This experimental phase is necessary to gain a full and complete understanding of how the Mali GPUs work. Once more is known, an actual graphics driver (most likely based off of Mesa/Gallium) can be written. There is a lot of interesting work that still needs to be done!"....okay got my answer. So i think, things lik
<zeRez>
e 1080p or 3d graphics wont work atm?
<rellla>
lima isn't a driver yet
<zeRez>
okay, so that means?
<zeRez>
no gpu support yet?
<zeRez>
my problem is, that iam looking for a nice one-board-computer, and the more i read, the more devices there are in my mind...no the details are intresting...
<zeRez>
read annoucement about cubietruck, which sounds like its the right device for me, the only thing iam afraid of, is the problem with mali/lima drivers...
<zeRez>
so i thought, i will ask ppl which know more about here on irc ^^
<rellla>
to use mali 3d, atm the only possibility is to take the mali binaries because there isn't a lima driver yet.
<zeRez>
okay
<zeRez>
but it sounds like the hole thing is rolling/at work...how is the performance of the mali bins?
<zeRez>
Is it useable in case of multimedia stuff?
<zeRez>
My first case is learning about ARM Platform, but i think i will use it for media too...
<Turl>
zeRez: mali is just useful for OpenGL ES
<zeRez>
okay
<zeRez>
hard choice
<zeRez>
^^
<zeRez>
read about the freescale guys, who supporting the community with drivers and they are os friendly...
<zeRez>
but from specs, i like the cb2/ct
<zeRez>
so dont know what to do
<zeRez>
:/
<Turl>
zeRez: when you get into the ARM world, you need to forget the GPU concept from the x86 world
<Turl>
GPUs on ARM just do 3D acceleration
<zeRez>
Turl, you mean cause ARMs are SoCs?
<Turl>
zeRez: I'm just saying because you used Mali and 1080p on a sentence :)
<Turl>
mali just does 3D rendering
<Turl>
video output is done by another thing, not mali
<zeRez>
ahh okay...i see
<zeRez>
saw it on a shematic
<zeRez>
sry :P
<Turl>
hardware video decoding is done by yet another part, cedarx
<zeRez>
so for videoencoding there a another peace on the chip right?
<Turl>
yes
<zeRez>
only read that the a10/20 mali wont work nice with media stuff, but maybe that where ppl without knowledge
<zeRez>
so how the a20 is running? is a linux "workstation" usuable and stable...or isnt it really useful?
<zeRez>
Turl, which board(s) do you own? iam really intrested in the hole topic....questions over questions :P
<Turl>
zeRez: mele & cubieboard (A10), and an A10S-OLinuXino-Micro (A10S)
<Turl>
and a cubieboard2 is in the mail :)
<zeRez>
okay
<zeRez>
there all singlecore right?
<zeRez>
^^
<Turl>
the ones I have here, yes. cubie2 is dual core (A20)
atiti has joined #linux-sunxi
<zeRez>
yep, i know so far :P
<zeRez>
and cubietruck will be a20 dual core too right?
<zeRez>
btw any new information about release from cubietruck Turl ?
<zeRez>
I think the right question for me is, what i can aspect from a a20 at all. Can you tell me? :P
<zeRez>
or tell me hows your work with the a10 chips ^^
<zeRez>
nonetheless i will wait for cubietruck release, hope that anyone will does a review and than i will make my choice ^^
<zeRez>
But i think the arm devices are really intresting
<zeRez>
Turl, do you know a good book about arm assembly?
<zeRez>
or free papers ?!
<user_2>
im dowloading chromium-browser source... crazy! more than 680M of source!!!
hglm has joined #linux-sunxi
<user_2>
zeRez, A20 disappointed me. it is "hot" even if slow than A10 (912MHz vs 1008Mhz).
<hglm>
zeRez: The ARM website has a lot free ARM assembler info -- you can print some quickreference guides.
<zeRez>
hglm, thanks for hint but got them yesterday
<zeRez>
:P
<zeRez>
user_2, really? why that? isnt it running good at all?
<zeRez>
hglm, searched for free books as well....found some pdfs on internet...think it will be enough to start. Doy you have experience in arm asm or asm at all?
<user_2>
zeRez, there are 2CPU, 2GPU... it double transistors, but not scale down the geometry of transistors, so the SoC is hot.
<hglm>
zeRez: Yes, recently I have done some asm work in ARM, it is not too hard. You can optimize for Thumb2 mode too (reduced code size). Make sure you use the right directives in your .S files declaring the function.
<zeRez>
user_2, ahh got cha! first i thought you mean the device is "hot" in the meaning of really nice :P. Isnt there a cheap heatkit for cubie out there?
<user_2>
no, hot in meaning of temperature :-)
<zeRez>
hgml okay, thats a good hint. Think i will learn it the painful way when it wont run ^^
<user_2>
heatkit no exixts asaik
<zeRez>
user_2, yes, understood you now :P
<zeRez>
here in eu you can buy some for a few euro user_2
<user_2>
anyway thre solution is NOT to place heatcooler, the solution is to srink the thansstor geometry.
<user_2>
nice kit
<zeRez>
so we need another chip than a20 ?
<zeRez>
i think so, hope there will be one for cubietruck too :P
<user_2>
no, we need A20 but not at 55nm. we need A20 at 28nm
<zeRez>
ahhh okay
<zeRez>
so that will reduce heating from the sock
<zeRez>
cause of lower voltage?
<user_2>
yes
<hglm>
Does Allwinner have anything in the pipeline at lower geometries? Rockchip does but they're not too Linux-friendly at the moment.
<user_2>
to scrink the nm will solve all the heat problem
<zeRez>
hglm, do you have experience also with x86 asm? ask because iam at the beginning to learn and intrested in ppl also coding asm ^^
<zeRez>
user_2, but it will make the production more expensive too ^^
<user_2>
40nm is already a "old" teclnology, so it will be usable for cheap price.
<zeRez>
and make less heat problems
<zeRez>
:)
<user_2>
55nm is too much for A20, il make it hot
<hglm>
zeRez: Yes, I did x86 asm a long time ago. But ARM asm is not difficult to learn if you already know some other assembler.
<zeRez>
is it hot all the time?
<zeRez>
hglm, iam at the very beginning...learning about the processor and how it works...but hope to write my first lines of asm next days :)
<user_2>
i can refere only what a frined told me: even if his CB2 is oly turned on and run in idle mode, the A20 is more than warm. it doenst appen to my A10. so A20 at 55nm is not a good choiche.
<hglm>
user_2: If the CPU is idle even the A20 at 55nm should not be hot, maybe power-management is broken.
<zeRez>
Iam very intersted in asm cause i think it makes you to a better programmer at all...cause you understand whats hapening in the machine and so you can write better code that works more efficent even in high-level
<hglm>
zeRez: Yeah it helps to know how C code compiles to asm. Try objdump --disassemble <objectfile.o>
<user_2>
hglm, im not telling this to talk bad, only to report what one told me. when i will have my A20, i will be able to test and report by mysel what happen to me.
<zeRez>
so what iam doing know? waiting for another allwinner chip? or just for the cubietruck? *confused*
<zeRez>
hglm, ahh nice...so i can inspect my object files with it on assembly to know what the compiler does with my code? :)
<user_2>
zeRez, in my opinion - based on sole "second hand" info -, actual A20 is not the magic i supposed it should be. take it, but be warned.
shineworld has quit [Remote host closed the connection]
ykchavan has quit [Read error: Connection reset by peer]
ykchavan has joined #linux-sunxi
<user_2>
in my mind A10=55nm and A20<=40nm. if it is not, than i am not happy cos it will became necessary a dissipator, that is a bad news for embedded device.
<zeRez>
user_2, okay...will have it in mind, thanks for the warning! Maybe the heatkit is a good choice than!
<user_2>
cubuetruck seems to be -on the paper- a good device. i hope it will be moved asap to A20 <=40nm
<hglm>
user_2: Rockchip has had a faster dual core at lower geometry out for quite a while used in millions of Android tablets (just like A10 has been for single core). I guess A20 is targeted at low-end.
<zeRez>
user_2, how is the performance side from a20? you friend told you?
<zeRez>
is there a "big" gap from a10 to a20...?
<user_2>
hglm, unfortunately, cubie came only wit allwinner.
<user_2>
zeRez, more or less, A20 is 180% compared to A10 100%.
<user_2>
so if you have 2 conucrrent task A20 is ok, if you have only one task, a10 is better.
<zeRez>
okay
<user_2>
but this is on theory, i will be able to say better afer test A20 compared to A10 in my hands.
<zeRez>
thanks :)
<zeRez>
i will be here when you talk about :P
<zeRez>
hglm, which devices you are working with?
<hramrach__>
hglm: the rk3066 cannot boot off SD which sucks but they fixed that with rk3188
<user_2>
wht about thet het dissipator? it ise a adesive, not a glue... im perplex
<hglm>
zeRez: I have a standard A10 tablet (1GB) which works pretty well, also have a RPi.
<hglm>
hramrach: OK, then rk3188 could be usable with Linux in the future.
<oliv3r>
wingrime i got a china charger, i can't use sata power with my '2 am 5V psp charger' from ebay
<hramrach__>
In my experience A10 gives _very_ low end desktop.
<hramrach__>
the memory is too slow so you get very low performance
<oliv3r>
buzz don't shorten data lines, put a restior between d- and d+ (you can easly google the value)
<zeRez>
hglm, okay :)
<zeRez>
hramrach__, how it is with a20?
<zeRez>
any experience
<zeRez>
?
<hramrach__>
a20 does not seem to improve much on that
<hglm>
hramrach: A10 is not that bad, for an older single core it runs pretty well, much faster than RPi.
<zeRez>
so also low end desktop?
<hramrach__>
there is more possibility to tune hte memory controller on a20 but it is less stable on higher clocks
<buZz>
rpi is an annoyingly slow desktop
<zeRez>
hramrach__, i see
<buZz>
a10 is better, a20 is not much but a little better
<hramrach__>
hglm: it is good when it runs gnome. now it crawls gnome
<buZz>
i have used all 3 on a lapdock for some time
<ssvb>
hramrach__: just don't use gnome :)
<buZz>
i use fluxbox :)
<hramrach__>
ssvb: I use it as benchmark
<hglm>
hramrach: You are probably benchmarking software-compositing, which would be slow on any system.
<hramrach__>
on a10 we have accel
<hramrach__>
actually the hw compositing is slow for small updates and sw compositing is slow for large updates
<ssvb>
hglm: not quite software compositing, but still excessive memory copies in the case of gnome-shell
<hglm>
ssvb: OK, so sunxifb's hardware blit gets used for compositing?
<hramrach__>
and th accel does not work on a20
jemk has joined #linux-sunxi
<wingrime>
oliv3r: use pc's power-unit 5V 120 A with 600 W easy
<hramrach__>
also it's not even possible to use full 1080p display resolution probably due to slow memory
<hramrach__>
it's just underpowered
<ssvb>
hglm: gnome-shell is using gles compositing, and is handled in a somewhat suboptimal way
<hramrach__>
it's not that yo ucannot use the a10 or a20 for something but desktop is too demanding these days
<hglm>
ssvb: I see, nice that it uses GLES, but Mali400 isn't too fast anyway and not optimized for compositing.
<ssvb>
hramrach__: I believe the acceleration will work on a20, when the other things become a bit more stable and we move to 3.4 kernel
<hglm>
In my experience Mali is very slow when doing anything with transparency (compositing).
<hramrach__>
it's the memory that is the bottleneck, not mali
<hramrach__>
it might be that mali is next on the list but that's irrelevant
<hramrach__>
I guess something like exynos 4/5 would do for a desktop
ykchavan has quit [Quit: Leaving]
<zeRez>
but it will run lxde without comp right?
<zeRez>
^^
notmart has quit [Quit: notmart terminated!]
<hramrach__>
I would like to know the speed of rk devices but their kernel does not even do frequency scaling so far so they don't want to publish benchmarks of current suboptimal performance
<hramrach__>
lxde does sw compositing - or was it xfce?
<hramrach__>
either way you will get abysmall performance for moving windows
<hramrach__>
without hw accel
<zeRez>
okay
<zeRez>
and we havent hwaccel atm for a20 chips?
<hramrach__>
android avoids that issue by making windows non-movable
<hramrach__>
no accel atm
<hglm>
hrma: not true, sunxifb has some nice optimizations for dragging windows even without hw accel
Tartarus_ has joined #linux-sunxi
<hramrach__>
did not work for me last time I tried.
ChanServ has joined #linux-sunxi
Tartarus_ has quit [Client Quit]
<zeRez>
so now iam unsure if i should spent my money for a a20 device :S
<zeRez>
hoped that it can be used as a simple desktop at all
<hglm>
zereZ: When using A10 (or A20) a simple desktop is very usable, it is not slow with LXDE or XFCE.
wingrime has quit [Read error: Operation timed out]
<zeRez>
hglm, okay...so it only got trouble with composite/"big" desktops
<hglm>
zeRez: Just don't use compositing.
ChanServ has quit [*.net *.split]
\\Mr_C\\ has quit []
<hglm>
I have experience with a 3D engine running on Mali, and anything related to transparency slowed it down a low -- I think that's why GLES compositing is slow also on Mali. Mali is only meant for single-pass 3D rendering.
<zeRez>
hglm, ok
<zeRez>
thats not a problem in "my usecase"
<zeRez>
^^
<oliv3r>
i guess as simple desktop, the a20 should be better due to its double cores
<hglm>
Yeah dual core should work well in a Linux environment.
<oliv3r>
wingrime: that's not very power efficient
<oliv3r>
Turl: ping
<hglm>
But I think the A10/A20's G2D engine can theoretically be used for compositing (alpha blending), but if it does it would require some work to implement.
<oliv3r>
A* needs tons of work still
<oliv3r>
i think A* has a lot of potential
<oliv3r>
a lot of potential that AW hasn't used yet
<oliv3r>
due to sloppy/bad code
<oliv3r>
Turl: :(
<Turl>
oliv3r: pong, sup
<oliv3r>
you never replied to my ping 5 hours ago! :(
<oliv3r>
maxime had to go
ChanServ has joined #linux-sunxi
<Turl>
oliv3r: I was probably half asleep 5h ago :p