<amstan>
he might have a fix in there for wifi not working after resume
<greggypoo>
i mostly copied that from the article for samsung chromebook
<leming>
ext2? wtf mate
<leming>
hrm, so just need to blacklist btsdio
<leming>
can't say i've bothered with suspend at all on minnie
<greggypoo>
yeah
<greggypoo>
i just used ext2 on the sd that i used to bootstrap, i'm even using ext4 on the full install
<greggypoo>
i have no idea how bad an idea it is :)
<leming>
ext4 will get you some resilience.. and you can turn off some of its noisier features to theoretically gain some flash lifespan
<leming>
you used to have to have an ext2 partition for the kernel or uboot environment, can't remember which.. but you definitely don't need it for root
<leming>
i was eyeing c4f71b9 too, since it was another vop commit
<leming>
though just reverting 181c3fe from tot is working
<amstan>
yeah, it's as if the absence of dabea37 hides the bug from c4f71b9
<leming>
well, i can just apply the one revert for now
<amstan>
yeah, makes sense, no point in having arch users broken
<amstan>
technically 181c3fe hasn't even landed upstream, so it's still under debate
<amstan>
well.. i guess i'm done
<amstan>
so blacklisting the bt module you say
<leming>
that's what's mentioned
<amstan>
leming, greggypoo: yep, blacklisting works perfectly
<amstan>
leming: so... that bisect work we just did, there's a very similar looking bug for chromeos
<leming>
oh?
JohnDoe_71Rus has joined #linux-rockchip
<amstan>
i'm gonna do a similar rebase
<amstan>
but it's awesome
<amstan>
bisect*
<amstan>
leming: ya! we found the problem
<amstan>
dabea37 is borked
<amstan>
the bit masks are wrong for the win2 and win3 registers
<amstan>
so... obviously that's why 181c3fe would break(this just switches to win3)
<leming>
after working past 9.. do you just roll in around lunchtime?
<amstan>
leming: yeah, i will
<leming>
just making sure you're not an insane workaholic :P
<amstan>
well.. yesterday Sadneophyte(the guy who soldered his peach_pit to boot firmware from sd cards)
<amstan>
was all concerned about this thing
<amstan>
given his past history i tought it was just him, then i upgraded my arch kernel and i had the same problem
<amstan>
so i felt like debugging it today
<amstan>
given that it's not really work related and more arch related
<leming>
i remember the nick from scrolling back.. don't recall reading any conversation
<leming>
chromium 44 is broken, btw
<leming>
new minor bump to that building now, doubt it will fix things
<leming>
some segfault i haven't been able (or have time) to track down yet
<amstan>
leming: i noticed
<amstan>
cool, so i just fixed a real problem in chromeos by bisecting with arch
<amstan>
s/fixed/found
<leming>
:D
<leming>
one step closer to world domination..
<amstan>
greggypoo: one big question i have for you
<amstan>
how on earth does this step work "# Copy the ChromeOS kernel to the root filesystem:"
<amstan>
the vanilla chromeos kernel doesn't like archlinux for example
<amstan>
i have to add systemd configs in there or else it won't boot all the way
<amstan>
don't you have the same problems with debian?
<leming>
i'm saving that page for when people complain that our install instructions are too lengthy/complex :P
<amstan>
greggypoo: another "note: though it will probably require armsoc server and several files from Chrome" you can't use those libmali files anymore
<amstan>
chromeos switched away from X11, so libmali doesn't have the required bindings for them to work
<naobsd>
oh
<amstan>
but... we do compile an X11 flavour of them, mmind00(heiko) actually made a package for debian for it: https://github.com/mmind/mali-driver
<greggypoo>
amstam, i don't know, i built my own kernel
<greggypoo>
yeah, i just saw that mali driver myself for the first time, i am glad of it but i haven't tried any of it
<greggypoo>
i didn't even know chromeos had abandoned X11
<amstan>
greggypoo: not a fan of that move, makes our work a lot harder
<greggypoo>
i was hoping someone might wiki-edit the rough edges of the install doc :)
<amstan>
i'm kinda hesitant to do that, given that i don't even use debian
<greggypoo>
the stock kernel mostly worked for me, except i didn't get it to take unsigned modules
<GekkePrutser>
w0000t my Asus Flip has been reserved and should come end August :D
<GekkePrutser>
First thing I'll do is install Linux :)
<GekkePrutser>
I could have had one today but I wanted to wait for the 4GB model
<GekkePrutser>
For those few bucks extra it's an easy choice
<sjoerd>
mmind00, rperier: ooi do you know if anyone started with upstream support for the Rock2 square thusfar ?
<rperier>
it was in my todolist, but I have no started yet
<mmind00>
sjoerd: not me :-) ... if people send me boards, I try to work on them, but I don't have a Rock2 ... but in any case shouldn't be to much work I think
<sjoerd>
Nope
<sjoerd>
For some of the bits i'm doing it was decided to use the 2 instead of the pro (so rperier don't expect me hacking on the 3188 hdmi bits :p). Will hopefully have a board in not too long
<rperier>
I received one at home, I planned to play a bit with sdio and wifi on my veyron-speedy and then start to work on a dts for the rock2
<rperier>
I think that use both are interesting, both boards need work. But everyone can work on his preferred platform ;)
<sjoerd>
They are
<mmind00>
sjoerd: good choice ... I sadly don't think the rk3188 will reach an equivalent featureset anytime soon
<rperier>
I agree
<sjoerd>
I'm keeping one rk3188 to use as a personal audio player most likely, but that already has enough features now as i just need spdif out :p
<mmind00>
sjoerd: you just need to resend the whole series to make Mark happy ;-)
<sjoerd>
mmind00: I was planning to wait a few days to see if there were review comments from others i could address and then resent it in a Mark-compliant way
JohnDoe7 has joined #linux-rockchip
<c0d3z3r0>
hi mmind00, we had a talk about the rockchip timer / arm global timer some time ago, because it's not working with cpufreq, yet.
<c0d3z3r0>
now that my exams are over I have some time to look at it again. you said, it would be easier to ajust the arm global timer than implementing the missing parts of rktimer.
<mmind00>
sjoerd: not sure if there will be any more ... aka Mark is the maintainer, I don't understand i2s very well and except for style nitpicks we don't have so much drive-by comments for rockchip-specific stuff
<mmind00>
c0d3z3r0: both implement the same timer hw
<sjoerd>
mmind00: Then most likely i'll resubmit in a few days without changes indeed
<c0d3z3r0>
mmind00: arm global and rkchrome?
JohnDoe_71Rus has quit [Ping timeout: 264 seconds]
<mmind00>
c0d3z3r0: rockchip_timer in both rkchrome and mainline ... you can of course try to squeeze relevant stuff in there
<amstan>
though.. you might care of linux-peach devices too
<mmind00>
oh nice
Sadneophyte has joined #linux-rockchip
<Sadneophyte>
sorry amstan it took me a second
<amstan>
Sadneophyte: so you say fbdev is faster
<amstan>
that's interesting
<amstan>
we need to get the egl backend for vlc
<amstan>
then it'll go a lot faster under mali/armsoc
markm has quit [Ping timeout: 250 seconds]
<amstan>
mmind00: speaking of framerate... composition in kwin absolutelly kills framerate on youtube videos
<amstan>
if it's non composited it goes a lot faster
<amstan>
there's also tearing everywhere
<Sadneophyte>
so I had some observations about the archlinux linux-veyron-3.14.0-6,7,8,9 kernel patch verions and their interactions with X11 ..ohh you are here
<mmind00>
amstan: yep ... same with gles and composition ... glmark2-es2 now runs with nice 120fps per test after turning this off
markm has joined #linux-rockchip
<amstan>
Sadneophyte: right.. we have fixes for that glitch problem
<Sadneophyte>
yeah it seems like the xf86-video-fbdev drivers interacting with kernel-3.14.0-8,9 were REALLY fast compared to the armoc-rockchip drivers when interactingwith X11
<Sadneophyte>
even compositing
<amstan>
how are you compositing with fbdev?
<Sadneophyte>
it is a normal feature of xfce4
<Sadneophyte>
emulation
RayFlower has quit [Ping timeout: 246 seconds]
<Sadneophyte>
(i assume)
<amstan>
ok, so you're not doing egl through mali, you're just software gling
<Sadneophyte>
but with fbdev it seems to be faster (qualitatively) than with the armoc-rockchip
<Sadneophyte>
amstan I assume. I replace the driver "armsoc" with driver "fbdev" in the /etc/X11/xorg.conf.d/20-armsoc.conf file, and some things get a lot faster
<amstan>
and i assume you had mali working too?
<Sadneophyte>
HOWEVER fb was faster on kernels 3.14.0-7,8 and slower on patchnumber 9
<Sadneophyte>
amstan : re: mali I am not sure
<amstan>
can you run eglgears_x11 and eglinfo ?
<Sadneophyte>
amstan everything I am saying is opintion however. fyi, I did not bench x11
<Sadneophyte>
I only found glewinfo
<amstan>
if you see mali midgard in there you're running it, if you see mesa then you're doing emulation
<amstan>
and mesa with armsoc probably doesn't go well in terms of performance
RayFlower has joined #linux-rockchip
<Sadneophyte>
where can I find the package providing eglinfo
<Sadneophyte>
omg amstan thank you for recomending this chipset
<Sadneophyte>
it is a really nifty little thing
<amstan>
Sadneophyte: try mesa-demos
<Sadneophyte>
oooh okay
<Sadneophyte>
I have to appologize in advance if I ask doltish questions, I am totally new to arch systemd and arm in general.
<amstan>
Sadneophyte: no problem, just pass on the knowlege :)
<Sadneophyte>
glxgears unmod is ~70fps with 3.14.0-9 and armson-rockchip x11 driver no mention from 'glinfo' of midguard
<Sadneophyte>
still no egl* packages
<Sadneophyte>
no eglgears
gb_master has joined #linux-rockchip
<Sadneophyte>
just gl gears
<Sadneophyte>
glxgears*
<Sadneophyte>
and glinfo
<Sadneophyte>
buy with the error: libGL error: unable to load driver: rockchip_dri.so
<Sadneophyte>
but you implied before that was normal...
<Sadneophyte>
****no midgard nor a midguard*** in the glinfo or glxinfo output
<mmind00>
Sadneophyte: es2gears with Mali drivers runs for me right now at around 1200fps ;-)
<mmind00>
now it seems to have made it into the 1400-1500fps range
<mmind00>
Sadneophyte: but also it looks like your fbdev xserver is hindering performance ... glxgears runs currently at 154fps
gb_master has quit [Remote host closed the connection]
<mmind00>
and sorry have to correct es2gears values ... 300fps (was reading the wrong column)
<Sadneophyte>
do i need the dri library?
<mmind00>
Sadneophyte: there is no dri library ... aka the missing rockchip_dri is to be expected
<Sadneophyte>
es2_gears is running at 75fps as well. Are you running the standard arch veyron?
<mmind00>
nope Debian ... with mainline kernel
<Sadneophyte>
huh....
<mmind00>
(4.2.0-rc5)
<Sadneophyte>
kernel version?
<Sadneophyte>
and that is armhf?
<mmind00>
yep
<Sadneophyte>
mainline is that the chromeos3.8.0 kernel?
<mmind00>
nope mainline kernel, as in 4.2.0-rc5 + some patches that will be in 4.3 + a small amount of stuff that needs further refining
<Sadneophyte>
right, sorry
<Sadneophyte>
so I should compile that kernel huh...?
<Sadneophyte>
it looks like arch has a linux chrombook kernel, however it is 3.18.1
<mmind00>
nah ... you should probably stick with the one the arch people provide ... it might provide a bit more completeness right now
<Sadneophyte>
yeah..... wireless...
<Sadneophyte>
does it matter that the X11 was compiled against the 3.10 kernel?
<Sadneophyte>
like: from xorg.log.0: Build Operating System: Linux 3.10.69-1-ARCH armv7l
<Sadneophyte>
mind00 lol my goal is to be able to watch mpeg4 with synchronous sound and pictures :)
<mmind00>
X doesn't really care about the kernel version ... one thing is that the whole drm-subsystem (meaning graphics) is quite different
<Sadneophyte>
amstan : so no midguard or midgard
<mmind00>
the mali driver works for both (3.14 and mainline)
<amstan>
Sadneophyte: that would explain it
<amstan>
Sadneophyte: get your mali driver working in armsoc and it might go faster than fbdev
<Sadneophyte>
amstan it looks like it is loading
<Sadneophyte>
is there a pastebin command for arch?
<amstan>
i'll compare that with mine when i get a chance
<Sadneophyte>
are you using the stock open source mali?
<amstan>
mali is not open source unfortunatelly
<amstan>
there's lima, which is the analogous to noveau in nvidia land
<Sadneophyte>
ohh totally my bad, grep didn't like the output of es2_info. the first line very specifically says: EGL_VERSION: 1.4 Midgard-"r5p0-14wk51"
<amstan>
then you're good
<Sadneophyte>
amstan okay I think I understand
<Sadneophyte>
1342 frames in 5.0 seconds = 268.400 FPS
<Sadneophyte>
this is after I close cairo-dock
<Sadneophyte>
so cairo-dock is the problem amstan
<Sadneophyte>
weird
RayFlower has quit [Ping timeout: 246 seconds]
<Sadneophyte>
or rather the driver interacting with cairo-dock and compositing
RayFlower has joined #linux-rockchip
<Sadneophyte>
amstan can you recomend a video player which you find to play with adequate performance
<amstan>
not yet
<amstan>
vlc worked pretty well with low resolution(less than 720p)
<Sadneophyte>
it seems like glxgears_fbconfig runs faster than glxgears
<amstan>
.... glxgears will never run fast
<amstan>
since it's gl
<amstan>
there's no hardware acceleration, the hardware itself doesn't do gl
<amstan>
only egl
<Sadneophyte>
ohhhhhh
<Sadneophyte>
amstan vlc looks like gold, the mplayer isn't nearly as nice
<Sadneophyte>
amstan so it makes sense that x11 xcb output is faster than gl output for video players?
<Sadneophyte>
and egl is a type of accelerated framebuffer!?
<Sadneophyte>
thank you very much amstan and mmind00 if I have to go abruptly.
<amstan>
Sadneophyte: egl and gl are similar both accelerated
<amstan>
egl is a newer standard, designed for more low power usage like phones
<amstan>
desktop gpus like nvidia do both, but mali only has egl
<amstan>
so your gl is going to be emulated by the cpu
<amstan>
read: slow and/or not working
<Sadneophyte>
amstan so... it looks like the solution is to run cairodock -o which selects the opengl backend. it looks like when armsoc is running it wants to default to the -c cairo backend. ...
<Sadneophyte>
this is all very interesting
<Sadneophyte>
again, super thanks
<leming>
amstan, nice to see they're updating it.. so many others just park on initial releases
<amstan>
mmind00, leming: once a man loses a bet, he's forced to provide updates, lol
<leming>
looks like both the new patch and armsoc update are waiting for me tonight
<amstan>
did heiko update armsoc?
<amstan>
neat
<amstan>
Sadneophyte: there you go, fixed :)
<amstan>
leming: have you tried hdmi yet?
<amstan>
we might be able to do 4k now
<leming>
nope
<leming>
so remind me.. no revert is needed now, correct?
<amstan>
leming: nope, not with both the arm patch and the new kernel patch