leming has joined #linux-exynos
<WarheadsSE> mmalecki: the official one
<mmalecki> WarheadsSE: right, but the official ArchLinux ARM sound guide or the official ArchLinux sound guide?
<mmalecki> WarheadsSE: iirc, both only mention installing alsa-mixer and that's what I did
<si1v3r_> I scripted the install and it works from that.
<dddh> mmalecki: dual boot or crouton?
<dddh> mmalecki: just interested
br has joined #linux-exynos
<mmalecki> dddh: dual boot from an microSD card
afaerber has joined #linux-exynos
<chrs_> mmalecki: which kernel are you using?
<mmalecki> chrs_: the chromebook one. package is linux-chromebook, `uname -a` is "Linux cb 3.4.0-ARCH #1 SMP Sun May 25 18:58:05 MDT 2014 armv7l GNU/Linux"
<mmalecki> chrs_: I'm working on compiling the chromebook kernel myself presently tho
<chrs_> i never got audio working with linux-next
<chrs_> but i never tried for too long
<si1v3r_> Worked fine in arch for me.
<chrs_> 3.8.11?
<si1v3r_> 3.4
<si1v3r_> mmalecki: I'm working on compiling 3.8 too. I have it working somewhat.
<chrs_> oh, right. default ALARM install instructions uses chrome os kernel
<si1v3r_> Nope.
<chrs_> no?
<si1v3r_> They include their own compile of it, no repacking.
<chrs_> oh
<chrs_> some memory is ocming back to me now
<chrs_> hmm, but my problem wasn't "no mixers"
<si1v3r_> macs are shitty.
<chrs_> i thnk my problem was all audio channels were muted by default
<si1v3r_> I scripted a fix for that.
<si1v3r_> amixer | grep "Speaker\|Headphone" | grep DAC1 | sed "s/Simple mixer control //" | sed "s/,0//" | while read mixcontrol; do amixer sset "$mixcontrol" on; done;
<chrs_> neat
<si1v3r_> I'm having way too much fun with bash.
<chrs_> i didn't even use a commandline tool
<chrs_> i used one with a curses interface
<si1v3r_> alsamixer takes forever to do the same thing. heh
<chrs_> there were a lot of keystrokes
<si1v3r_> After doing that about a dozen times I said fuck it, I'm done. heh.
libv_ has joined #linux-exynos
libv has quit [Ping timeout: 250 seconds]
<WarheadsSE> si1v3r_: if that is the case, then we'd actually want to look at /usr/share/alsa/conf/*
<WarheadsSE> But you've already done that.
afaerber has quit [Quit: Verlassend]
<si1v3r_> Have not played around in that folder, no.
<chrs_> do you think the chromium project will ever switch over to a mainline kernel?
libv_ is now known as libv
<si1v3r_> Doubt it.
<chrs_> i feel like the longer they're on they're own branch, the harder it will be
<si1v3r_> Look at android.
<chrs_> ew
<si1v3r_> Google has the resources to support a fork if they want to, so the odds of them ever working in mainline are low.
<mdrjr> si1v3r_: you should start reading linux-samsung-soc
<mdrjr> before saying those things
<javier__> mdrjr: or just doing a git log
<mdrjr> javier__: haha! People don't understand how mainline works. They think you just drop a 5Mb .diff and its all fun and games
<mdrjr> they don't see patchs that have 12 revisions before getting accept
<mdrjr> nor the time that it takes
<javier__> mdrjr: agreed, I don't know a single linux product that uses a vainilla mainline kernel
<javier__> everyone has downstream patches, there is a trade-off between doing constant rebases of your out-of-tree patch-set vs investing effort in upstreaming to minimise your delta
<mdrjr> javier__: with time.. Support comes.. but you have product X to put on the market.. You'll fork the kernel make your product work and ship it.
<javier__> mdrjr: nod, I do have my personal opinion on what's the best approach, specially for products with a long life span
<javier__> mdrjr: because I used to work for a company similar to hardkernel that designed and manufactured SOM and dev boards but OMAP based and management policy was to not upstream our patches
<mdrjr> javier__: well.. we don't have such policy inside.. (not that i'm aware really).. its just that me, personally don't have time to deal with it ATM
<javier__> mdrjr: actually, they didn't allow us to do on our workday but we did anyways in our free time to reduce our maintenance nightmare each time we had to rebase to a newer kernel
<mdrjr> whenever I stop working on a board.. I have a new one to deal with
<javier__> mdrjr: sorry I didn't mean similar to hardkernel w.r.t of any policy (I don't know how the company works) but similar because they manufactured SOM as well :)
<mdrjr> javier__: Its complicated.. because everyone want's that a new shinny piece of hardware..
<mdrjr> I would like ideally to have someone (me or anyone else) to keep working full time to upstream our stuff
<mdrjr> Its a nightmare to backport certain patch's
<sjoerd> speaking of hardkernel, quite nice to was great to see a bunch of odroid support finally landing upstream
<mdrjr> sjoerd: yes. Thanks to Samsung.
<sjoerd> Nod
<SJRvanSchaik> /win 14
<javier__> mdrjr: I know it's complicated since I've been there done that...
<sjoerd> mdrjr: will hopefully open up the gates for more folks to contribute for the exynos4 odroid though :)
<sjoerd> hopefully someone will get support for the XU3 in mainline done as well, i guess the chromebook2 having the same soc will probably help there
<sjoerd> one can dream :)
<mdrjr> sjoerd: yep.. When I got the first samples of XU3 it was half-booting on mainline already
<mdrjr> I didn't checked again..
<sjoerd> Nice
<mdrjr> I have a few XU2's that I would love to put into use as well :P
<mdrjr> Hardware that no-one will ever see :(
* sjoerd can only wonder how those are different :)
<mdrjr> XU2 is 5420, XU3 is 5422
<mdrjr> same size, same ports.. same everything..
<mdrjr> expect that XU2 has 3GB of RAM
<sjoerd> what does the 3 have? 2G?
<mdrjr> XU3 has 2GB
afaerber has joined #linux-exynos
<javier__> mdrjr: so, what's the difference between 5420 and 5422?
<mdrjr> never bothered to check both manuals but..
<mdrjr> some clocking stuff is different
<mdrjr> and according to SLSI 5422 can do the HMP thing nicely.. (its doing atm)
<javier__> sjoerd, mdrjr: yeah according to http://en.wikipedia.org/wiki/Exynos also the difference is only in the Cortex A15 / A-7 and mali GPU clocks
<mdrjr> eg. ATM I have all the 8-cores at the same time on my XU3
<mdrjr> and 5420 in theory can't do that
<sjoerd> nice
<sjoerd> need to tweak the options for the kernle i'm running on my chromebook atm, only the A15s came up
MrBIOS has joined #linux-exynos
<WarheadsSE> Doesn't that cause the wattage to jump mdrjr
<mdrjr> WarheadsSE: if you use properly all the PM functions on Exynos no
<MrBIOS> hello folks
<MrBIOS> I have a few new Arndale Octa boards (exynos 5420-based) here in the US and was looking for someone who might be interested in one or two.
<Wizzup> hiya
<si1v3r_> What sort of connectivity do they have?
<MrBIOS> si1v3r_: USB 10/100 eth.
<MrBIOS> but it also has a full-speed (aka SuperSpeed) USB 3 port
<si1v3r_> I need to do some usb3 benchmarking. It may suit my nas needs.
<si1v3r_> God it takes a long time to git clone a kernel
dlezcano has quit [Quit: Leaving]
<chrs_> yup
<chrs_> even on my datacenter connection it was slow
MrBIOS has quit [Ping timeout: 240 seconds]