<wizziwig>
I would love to write a media player for this thing (even something simple like the NMT monoLite one I did).
<lundman>
I was just wondering what to do next... so what you suggest is, we need more video out modes
<lundman>
and audio on hdmi cant do more than 2 ch?
<wizziwig>
that was the show-stopper for me.
<lundman>
wizzi: I am considering making a display-app for Accidents db/eversion API.. so it looks like eversion on android
<lundman>
another option is xbmc on android, might take longer
<wizziwig>
the judder playing back high fps content was too extreme for my taste. It's less noticeable at low fps like 24fps content.
<lundman>
i fixed the judder when using NIC, if you experienced judder otherwise, I dont know
<wizziwig>
No, I mean the frame rate mismatch. The a10 runs everything at even multiples like 24 and 60. It needs to output 23.976 and 59.940 like the NMT.
<wizziwig>
but good job fixing the ethernet problem.
<wizziwig>
I mostly tested from local storage.
<lundman>
ok, i think the video frame rate is in the kernel module that we have sources for, so we should be able to add more modes
<rzk>
check out what luke posted at mailing list just now.
<wizziwig>
I can point you to some test video files to show you the fps judder. hold on.
<wizziwig>
all the existing a10 HD modes are based on a 74.25 Mhz pixel clock. Real HDTV modes and encoded content has a funny /1001 divider so we need a pixel clock running about 74.25*1000/1001 = 74.17 Mhz.
<wizziwig>
otherwise you see frames being repeated or dropped every few seconds.
<lundman>
ok so, if HDMI1080P_24 has clock of 74250000, then 23. uh, whats the number again?
<wizziwig>
to stay perfectly in sync with audio without dropping or repeating frames.
<lundman>
and 74175824.17582 for 29.97003
<wizziwig>
yeah, all the modes they have defined in the source would work fine as they are. Just needs a proper pixel clock.
<lundman>
I can certinaly add 74175824.0 and see if it has less judder
<wizziwig>
the problem is that their clock accuracy may not allow that.
<wizziwig>
it may be limited to multiples of some fraction of a second that don't match exactly what we need.
<lundman>
its possible, but more fun in just trying
<lundman>
so, you get me a sample with the problem, I set 1080p24 and see how bad it is
<lundman>
then change to 1080p23 and see if it is better
<wizziwig>
ok. just FYI, this clock problem is VERY common. Even billion dollar companies like Intel can't get this right. All their integrated GPU's suffer from the same limitation. That's why I still use my old NMT A100.
<wizziwig>
Realtek media players are also broken
<lundman>
oh i doublt it'll fix it. but if the judder can be limited such that it is watchable....
<wizziwig>
it's like they have idiots designing this hardware.
<wizziwig>
there is another work-around possible...I'll discuss in a second. Let me find you those samples.
<lundman>
now if we could later also make it mode-switching, that'd be nice
<wizziwig>
problem is most obvious on the 59.940 samples. I also have some hockey camera panning shots that are very bad. This also happens on movies/tv-shows but at low 24fps it's harder for most people to see.
<wizziwig>
the next problem (as you've already discovered) is the PCM stereo audio issue.
<wizziwig>
from what I was able to figure out, it seems to support up to 8-channels of PCM over HDMI. So it has the bandwidth to pass HD audio.
<lundman>
but it does not send aac/ac3/dts over hdmi passthrough?
<wizziwig>
no currently. but it seems possible in theory.
<wizziwig>
worse case we may have to decode to PCM and pass it out that way.
<lundman>
ok, we definitely need to fix that. It has 3 audio options, I just assumed that was the difference between "codec" and "hdmi" settings. codec is decoding to stereo
<wizziwig>
but it would be lossless and same audio quality as bitstreaming the DTS-HD, etc. directly
<wizziwig>
you'll have to try. I don't have a mele to test right now.
<lundman>
yeah I am already testing truehd/dtsma tonight, so I'll check all that too
<lundman>
no idea what clkspeed for 59.940 would be
<wizziwig>
regarding the FPS issue. The work-around would be to speedup the video slightly (so it plays at 60hz or whatever is the closest match to 59.940 on the mele). Then adjust audio speed to match by resampling the audio. This is what XBMC does on PC.
<wizziwig>
it's ugly and slightly lossy since you're messing with the audio bits.
<wizziwig>
also not sure if the a10 has enough CPU power to do proper audio resampling.
lupul has quit [Ping timeout: 245 seconds]
<lundman>
unlikely
<wizziwig>
you could just drop/repeat audio frames too. It's much less noticeable than dropping and repeating video frames.
<wizziwig>
that would keep both in sync without additional CPU cost.
<wizziwig>
and you get to keep audio bitstreaming at the cost of occasional audio drop-outs. There is no really perfect solution without a proper pixel clock. Hopefully the a10 allows enough precision in the clock to get closer. A frame glitch every few minutes would be ok.
<lundman>
yeah
<lundman>
148351648.4 for 59.9401
<wizziwig>
progressive yes.
<lundman>
ok so, i get a judder about eevery 3 seconds playing 59 on 60 output, sounds about right?
<lundman>
or is it some other playback issue
<lundman>
hmm yes, I cant tell any difference between 60 and 59, seems to judder the same, which is not a great start :)
<lundman>
hmm VGA dont tell me frame rate, so I'll test this at home on hdmi
<wizziwig>
yeah, from my experiments, the mele outputs some funky frequency that is above 60... so no video format looks perfect on it.
<wizziwig>
just timing the vsync interval in code can give you a good idea.
<wizziwig>
I'm a video game developer on my regular job so we deal with these issues all the time. Luckily game consoles support proper pixel clocks. :-)
<lundman>
yeah, i used to be in game dev
<lundman>
arganout, wooo
<lundman>
cant even spell it though
<lundman>
*argonaut
<wizziwig>
I know who you mean.
<lundman>
but I left quite a while back. last I worked on was ps3/gamecube/pc
<wizziwig>
I wish game consoles were not locked up so tight. They would make ideal media players (ignoring the crazy power usage). I've worked on practically all of them (PS2, PSP, Wii, PS3, Xbox360, 3DS). Wrote video players for some of them for our in-game cinematics. That's why I'm sensitive to timing issues.
<lundman>
yeah, ps3 or 360.. if they were open, it'd be an acceptable answer
<wizziwig>
Right now I'm waiting for some of those quad-core Arm devices to start showing up.. either the Exynos one or the Freescale i.mx6.
<wizziwig>
Freescale has really great developer support on their web site.
<lundman>
the naked boards are available, but yes, something more friendly would be nice
<lundman>
or that 96core 2u arm, that's should have enough cpu
<wizziwig>
Looking through the SDK of their older i.mx53, they seem to better understand the requirements of proper video playback. The i.mx6 dev board is like $300. Too much $ for experimenting. I think final products will be $100-$200 next year.
<wizziwig>
need to get some dinner now. Nice talking to you lundman. I'll try to stop by here again soon.
<lundman>
yeah
<lundman>
also, keep me informed if you find anything out
<wizziwig>
main problem is I no longer own any A10 devices. I had a tablet for a while but sold it too.
<wizziwig>
if you make any progress, I'll pick up a mele and try to help you out.
<wizziwig>
I know a lot about video much not as much about Linux kernel hacking.
<lundman>
i dislike linux, but its here to stay :)
<lundman>
same about java
wizziwig has left #arm-netbook [#arm-netbook]
DonkeyHotei has joined #arm-netbook
hipboi has joined #arm-netbook
hipboi__ has quit [Ping timeout: 240 seconds]
DonkeyHotei has quit [Ping timeout: 264 seconds]
ka6sox-away is now known as ka6sox
<steev>
aww wizziwig left, and i just noticed the freescale talk :(
mpthompson has quit [Quit: Take my advice. I don't use it anyway]
<lundman>
Did we get the Mele's "video output settings" program released?
nibb has quit [Ping timeout: 264 seconds]
<rm>
for Xorg?
<lundman>
android
<Shivan>
someone knows what versions are the libs in the mali400-dev package?
<lundman>
i bet someone does
nibb has joined #arm-netbook
Quarx has joined #arm-netbook
eebrah has joined #arm-netbook
rellla has joined #arm-netbook
simonckenyon has joined #arm-netbook
simonckenyon has quit [Read error: Connection reset by peer]
<lundman>
its either that or CedarX, android_Servers or cedarxbase :)
<steev>
those don't control the *UI*
<steev>
you're looking for settings most likely
<Turl>
and what steev^ said
<Turl>
but you'll still need to handle it on the hal to support it on the UI
<lundman>
thesettings are done in xml/sql, something reads that to call ioctl, that is what I am seeking
<lundman>
actually, its possible this is vanilla stuff, not specifically mele, but they do compile it in
<steev>
the only "Display Output" i'm finding in all of android sources for Quarx (because it's the only one i have at the moment) doesn't list it anywhere except comments in the kernel, none of which deal with sun4i
<steev>
unless you count ivtv
<steev>
no idea if sun4i calls into that though
<Turl>
I doubt quarx merged the UI controls
<steev>
i doubt it as well, but i'm still kinda lost, i thought lundman wanted to add the strings to the UI so that they can be selected
<steev>
either way, i should go to bed, meeting tomorrow
<lundman>
I can add the strings, and make it save it to sql
<lundman>
that don7t mean the binary program that reads the setting and calls ioctl will know about the new value
<steev>
well if you look at the mele settings app sources you should see what it calls out to
<lundman>
INSERT INTO "system" VALUES(219,'display_output_format','VGA 1920 x 1080');
<lundman>
that part is just xml
<lundman>
steev: yeah, so the url to the "mele settings app" is... :)
<steev>
lmgtfy
<lundman>
and we are back to my original question
<Turl>
lundman: the chances are, 'mele settings app' is on some mele employee's hard disk
<steev>
look on github? i seriously don't know where the melee rom comes from at all, or if they released sources
<Turl>
that stuff is apache licensed
<steev>
yay open source licenses
<lundman>
yeah. step 1 was to ask and see if it is already known to be out. step 2 is ask a mele person
<steev>
i'd look on github since people tend to keep it there, and then i'd look on gitorious or bitbucket
<steev>
a quick google didn't turn up squat
<Turl>
and in any case, if mele is a decent OEM and didn't sign their build with test keys, it's not like you can rebuild it and replace the binary to test
<lundman>
but, it is technically a setting for all A10. not specific to mele
<steev>
all the allwinner companies seem to be rather inbred
<Turl>
it's the vendor that released kernel source
<lundman>
I'll have a look in the zip
<simonckenyon>
does recovery.img include the root file system? if so, how come i have managed to modify default.prop?
<RaYmAn>
simonckenyon: it usually contains a ramdisk. You can modify it in the ramdisk, but it won't persist across reboots.
<Shivan>
It its possible to chroot the android system on the ram in the linux system so we can run android apps from Linux?
<Shivan>
ram=nand
<simonckenyon>
well i have somehow managed to change it permanently. build.prop contains values from an earlier attempt my me to create a working cm9. now i cannot install a new attempt after i changed the ro.build.product value and the assert is failing.
<RaYmAn>
simonckenyon: build.prop is in /system usually.
<RaYmAn>
simonckenyon: build.prop != default.prop
<simonckenyon>
did i say build.prop. i meant default.prop
<RaYmAn>
You said both :P
<simonckenyon>
found the code in edify_generator.py which emits the assert. going to comment that out to build a new cm9 without the assert.
<simonckenyon>
sorry about the build/default confusion. i've been building cm9's for days and i decided to start again with a new tree and i hit this problem. being looking at it for a couple of hours now.
<specing>
Shivan: maybe you can install dalvik ontop of your distro?
naobsd has joined #arm-netbook
hipboi_ has joined #arm-netbook
ka6sox is now known as ka6sox-away
hipboi has quit [Ping timeout: 265 seconds]
<simonckenyon>
you are lost in a maze of twisty makefiles
<lundman>
go north!
<Shivan>
even windows x86 can run android apps -.-
<Shivan>
we really need some kind of "wine" that runs android apps on linux arm -.-
<specing>
Shivan: dalvik ;P
<specing>
Shivan: dude android runs ontop of a bare bones linux distro
<specing>
I dont see a reason why it shouldn't run on debian, gentoo, or whatever
<Shivan>
that the same was thinking of the libflashplayer.so from android, and still, it does not work on linux
<specing>
It does
<specing>
the problem is that you dont have an android-compliant kernel
<rm>
"we really need" ?
<rm>
"really"?
<rm>
"need"?
<specing>
No we dont
<rm>
oh, maybe by "we" you mean yourself and your cat
<ZaEarl>
The Android emulator runs Android apps on Linux.
<rm>
orrrrrrrrrrrrr if you "really need" whatever crap you want from Android, then just run Android, and maybe a GNU/Linux in a chroot
<rm>
there isn't 3D or video acceleration working yet in Xorg anyways
<rm>
so your Angry Birds will stutter :<
<specing>
:D
<hno>
ManoftheSea, yes I am here.
<Triffid_Hunter>
Shivan: .so is a compiled binary.. you'd need the same cpu architecture as whatever phone you got it from as well as appropriate versions of whatever library dependencies it has
<Shivan>
so dalvik and the flashplayer lib from android should work?
<specing>
Shivan: another problem is that dalvik bypasses xorg
<specing>
so you would need to shutdown xorg to switch
<specing>
It has a lot of processing power but nothing to process
<specing>
No sata, no hw gigabit ether, ...
<Shivan>
bad vpu too
Gujs has joined #arm-netbook
<hp_>
vpu?
<hp_>
whats a vpu?
<Shivan>
video processor
<Shivan>
just H264 support and in mp4 format, is kind of annoying...
DonkeyHotei has joined #arm-netbook
<hp_>
Shivan: um yeah maybe
<hp_>
Shivan: did you see this.. Samsung 5Mpixel K5ECG MIPI CSI sensor
<hp_>
i wonder if i can get that module on my raspberry pi...
nibb has quit [Read error: Connection reset by peer]
nibb has joined #arm-netbook
naobsd has quit [Ping timeout: 245 seconds]
<rm>
and the ethernet+USB is the same as in the Raspberry Pi
<rm>
which requires constant 8000 interrupts per second to function
<rm>
varying opinions on whether it's "by design" or just due to the driver being awful
mtd_ is now known as mtd
<simonckenyon>
i have spent weeks trying to get this tablet to work. all i want is to be able to compile a couple of drivers. i give up.
<specing>
LOL
<specing>
what are you trying to do?
<specing>
and where are you compiling?
<specing>
and what are you compiling?
hipboi_ has quit [Ping timeout: 240 seconds]
hipboi has joined #arm-netbook
Mazon has quit [Read error: Connection reset by peer]
Mazon has joined #arm-netbook
<simonckenyon>
trying to build cm9 so i can build a device driver for a fingerprint reader
<simonckenyon>
building cm9 is straghtforward. trying to get a device driver for my touch screen is altogether a different matter
<simonckenyon>
how vendors think it is ok to ship GPL software without the source. makes me so ****ing angry. bunch of lying, cheating, thieving b******s
simonckenyon has quit [Quit: Nettalk6 - www.ntalk.de]
eebrah has quit [Remote host closed the connection]
ka6sox-away is now known as ka6sox
madmalkav has joined #arm-netbook
<madmalkav>
hey, where can I see if that exynos quad core devkit people is talking about on the mail list supports hdmi audio / DTS ?
<Shivan>
es2gears will be nice, if gles2 where working -.-
<traeak>
glxgears can run
<traeak>
but i only got 110fps with it
<rm>
it's still interesting to benchmark a modern ARM SoC, computers with which fit into a pocket, with a program from 1997 which compares it with a Pentium 90
<traeak>
not sure if that's good or not
<Shivan>
both of them can run, by software on mesa driver...
<rm>
which was essentially my first PC (I had the 100 Mhz model though)
<Shivan>
but 110 its a bit much by just mesa rasterizer i get about35...
<traeak>
yeah, take that with a grain of salt
<Shivan>
its strange... unless Mesa is accelerating glx using a gles wrapper?
<Shivan>
you can ran es2gears?
<Shivan>
and es2_info
<traeak>
right now i cna't run much of anything :-p
<Shivan>
well you cant spect much out of a ARM11 anyway...
tom_say has joined #arm-netbook
nibb has quit [Read error: Connection reset by peer]
nibb has joined #arm-netbook
<Shivan>
im trying to compile mali drivers and its missing drm.h ive compiled the driver before i wiped the sd, but i cant remember what is missing
<rmull>
This freebirds stuff is getting ridiculous.
<A2Sheds>
I've been reading like a bad spy novel....
<traeak>
there's a drm.h in the linux-allwinner code but not sure if that's the one you want ?
<A2Sheds>
he's obviously a fiction writer
* xxiao
is building android 4.1.1_r1 for pandaboard....
<xxiao>
and waiting for Mele2000, Tom shipped it one week ago, guess I need another week, anyone received it?
<mnemoc>
lots of people
<xxiao>
mnemoc: waiting or got it?
<mnemoc>
people has been using mele2000 devices bought from Tom for months already
<mnemoc>
mele-a2000
<RaYmAn>
xxiao: might want to check android-building mailing list. JBQ says 4.1.1 doesn't quite work on pandaboard yet (it boots with all black screen)
<rm>
xxiao, shiped one week ago, and already expecting to receive something shipped China Post (I assume)?
<rm>
...REALLY?
<rm>
also, just check the tracking
ctyler is now known as ctyler_onroad
* mnemoc
doesn't get one-week delivery from uk to spain...
<xenoxaos>
i just got something sent from bulgaria to the US in 2 days....
<xenoxaos>
i think it was cheap shipping too
<mnemoc>
nice
nibb has quit [Read error: Connection reset by peer]
<xenoxaos>
i was expecting to wait a couple weeks
nibb has joined #arm-netbook
<mnemoc>
bulgaria .... olimex?
<xenoxaos>
ya
<mnemoc>
:)
<mnemoc>
they just posted the routing of their a13-based board is finished :)
<A2Sheds>
I've noticed the same few day shipping for Euro car parts from Bulgaria and Romania to the US
* mnemoc
curses crappy uk's mail service
<A2Sheds>
packages from the US to the Uk tend to get stuck in customs
<A2Sheds>
unless you pay the 2x express fees for DHL or Fedex, anything Royal mail tends to bog down
<A2Sheds>
same thing with Spain last month, 3 weeks in customs then the receiver had 2 days to pay customs before it was going to be shipped back
<xxiao>
RaYmAn: yeah i'm aware of that, so far shooting for console only
<A2Sheds>
maybe Olimex can make the board fit in a small metal shell with edge connectors that isn't under patent?
<xxiao>
what about using the same format as beaglebone uses?
<xxiao>
so we can put "cap" on top
<A2Sheds>
how about a good format?
<xxiao>
android 4.1.1-r1 pandaboard finishes in 49 minutes, used to be 32 minutes on 4.0.4
<A2Sheds>
just an A10 or A13 on a board with DDR3 and IO connectors would be helpful..... like that tablet mainboard
<A2Sheds>
all IO on headers, no clunky USB or ethernet connectors to fight with for ID
<xxiao>
A2Sheds: some call this stamp-SOM, all pins are left at the edge for soldering with IO board
<xxiao>
but it's very hart to unsold the module, the hot-air-gun will affect all piece on the little module at the same time when you want to solder the module itself
<A2Sheds>
yes, something like that, even call it Eddie or Jake
<xxiao>
wish olimex releases it footprints of A10/A13
ka6sox is now known as ka6sox-away
<A2Sheds>
mnemoc, do you use stainless or just anodized aluminum?
<traeak>
legos would be good but they are damned expensive
<mnemoc>
A2Sheds: stainless afaik, I'm not involved in that part of the products :<
<A2Sheds>
mnemoc, just wondering
<mnemoc>
but I know that without a case boards die in a week because of the chemicals in the air
<A2Sheds>
at least the ML has some characters to provide some entertainment
rellla has quit [Quit: ChatZilla 0.9.88.2 [Firefox 13.0.1/20120614114901]]
gimli has joined #arm-netbook
<lkcl>
xxiao: i have one in the eoma.git repository on git.rhombus-tech.net
<xxiao>
lkcl: cool, what CAD is it for...
<lkcl>
kicad
<xxiao>
nice, i like that one, the best!
<lkcl>
:)
<lkcl>
go get fped if you haven't got it already.
<lkcl>
please help verify things - bear in mind that the documentation you find on the internet (the "datasheet") is *inaccurate* for the pinouts. i worked off of wits-tech's EVB schematics: those can be considered authoritative
ka6sox-away is now known as ka6sox
<xxiao>
ok. thanks. yes olimex was also saying pinouts are wrong from datasheet
<lkcl>
yes. but wits-tech's EVB are not.
<lkcl>
obviously. duh :)
<lkcl>
otherwise there would be a hell of a lot of broken products being sold, i think someone would have noticed?
<xxiao>
sigh, no comments
<lkcl>
:)
<CIA-122>
rhombus-tech: lkcl master * r2e38e765c919 /allwinner_a10/hacking_the_mele_a1000/script_for_installing_debian_on_sdcard.mdwn: add comment to copy OS
<madmalkav>
hey, where can I see if that exynos quad core devkit people is talking about on the mail list supports hdmi audio / DTS ? gonna look on the kernel but dunno where to look at exactly
<mnemoc>
tried the product page?
<madmalkav>
doesn't specify
<madmalkav>
oh, well, gonna use the lazy route: ask on their forums
<mnemoc>
:)
<madmalkav>
too tired for looking for stuff right now
<madmalkav>
by the way, it will be interesting to know the price of the exynos 4412 alone, if they are releasing the dev board at this price it will probably be a reasonable price cpu
<madmalkav>
another candidate for a eoma68 , don't you think lkcl ?
<xxiao>
lkcl: what's so good about fpeg, wan't kicad's footprint not good enough?
<xxiao>
s/wan/was/
<ibot>
xxiao meant: lkcl: what's so good about fpeg, was't kicad's footprint not good enough?
<A2Sheds>
madmalkav, I don't think they have posted pricing yet for just the quad core module with RAM
<xxiao>
madmalkav: try freescale's imx6 quad
<madmalkav>
yeah, freescale imx6 is also interesting priced
nibb has quit [Read error: Connection reset by peer]
nibb has joined #arm-netbook
<xxiao>
i think freescale has a board at $199 in the working, ready in Q3
<xxiao>
current one is $299
<A2Sheds>
if the next spin has the power management working for imx6
<A2Sheds>
last I heard they said August for the new wafers
<xxiao>
A2Sheds: how bad that is?
<A2Sheds>
xxiao, IIRC steev has a current imx6 dev board with the broken power management
<A2Sheds>
not sure of the other issues or workarounds
<mnemoc>
the point of those modules is to make low-quantiy boards cheap.... if you build jillion boards, it's cheaper to get the SoC directly in your board
<A2Sheds>
sure if they sell you the SOC
<A2Sheds>
you have to be part of the lucky we want to take your money club
<mnemoc>
those who can build jillion boards have easy access
<steev>
A2Sheds: yeah well multiples, but we should have new ones (soon)(er) than later
<steev>
supposed to have gotten them today, but they were delayed
<A2Sheds>
from the the FAQ : Do you have a distributor in my country? No, you need to purchase it from our web-STORE directly. We ship worldwide. I want to be a distributor in my country. We are not taking requests for it.
<steev>
A2Sheds: for odroid?
<A2Sheds>
steev: please let us know how well they work
vbmithr has quit [Read error: Operation timed out]
<steev>
that double negative always throws me off
<Turl>
steev: which double negative?
<steev>
ifneq (blah,n)
<traeak>
dunno what idiot (or set of idiots) made up the english double negative concept
<traeak>
ahh heh
<Turl>
:)
Quarx has quit []
<specing>
Turl: if you tell me what to do with it, sure (keep in mind that I havent worked on my Gentoo efforts for two weeks now)
<Turl>
just cherry pick the patch on your tree; you need to be using the "_SW" version of the driver
<steev>
specing: slacker
<specing>
:)
<A2Sheds>
steev: I'm still wondering if there is a future in imx6 or just 9 more months of delays and promises
<specing>
steev: I went on to write some GPIO tester on my ARM9 and I found that my Gentoo over there is completely messed up
<steev>
A2Sheds: too early to tell
<A2Sheds>
steev: let us know any good news
<steev>
we've been running as many tests as possible and reporting everything in a batch so it doesn't end up like the mx51 where the to1 came out, and issues were reported, then to1.1, then 2, then 2.1.. finalyl 3
<specing>
Turl: W.T.F. are those binary blobs?!
<Turl>
where? I commited blobs?
mpthompson has quit [Quit: Download IceChat at www.icechat.net]
<steev>
the firmwares?
<specing>
Turl: the patch is full of random binary { 0xab, 0xcd, ...} strings
<Turl>
specing: sounds like the firmware :)
<Turl>
my wifi hasn't failed yet
<Turl>
it used to drop like mad :)
<specing>
I dont think my wifi showed any problems
<specing>
other than being 800KB/s slow
* rzk
fighting with jhbuild and xorg cross compilation
<Turl>
specing: that's slow
<Turl>
specing: my wifi can do ~20Mb/s easily
<Turl>
and that's over the interwebz, it can probably do more against something on my LAN
<Turl>
(my interwebz is 6Mb with 'nitro' boost on connection start)
<specing>
:(
<specing>
rtl8192cus here
nibb has quit [Read error: Connection reset by peer]
nibb has joined #arm-netbook
Tsvetan has joined #arm-netbook
Tsvetan has left #arm-netbook [#arm-netbook]
hp_ has quit [Read error: Connection reset by peer]
arokux_h has joined #arm-netbook
ka6sox is now known as ka6sox-away
<Turl>
what's the "s" for?
marvin24 has joined #arm-netbook
<mnemoc>
that sucks
rellla has joined #arm-netbook
<ZaEarl>
GPL byte arrays, that doesn't quite make sense.
<specing>
yeap, it doesen't
<specing>
I wonder how it got accepted into the tree
* hno
do disagree with having out-of-tree modules merged inline in the sunxi kernel tree.
<hno>
those have not received the needed peer review to catch stupidities like GPL:ed firmware machine code in hex arrays.
<hno>
plus in case of MALI are not interface stable and tightly coupled with an userspace separate from the kernel tree.
<hno>
Core A10 drivers is one thing, but merging third party drivers with small modifications is not a good idea.
* hno
says end of rant.
<mnemoc>
:(
<mnemoc>
imo the only way to get the core sunxi drivers tested and improved by a broad mass of people is to be sure everyone uses our tree and authoritative, and that can only happen if we keep the drivers the real devices need
<mnemoc>
s/tree and/tree as/
<ibot>
mnemoc meant: imo the only way to get the core sunxi drivers tested and improved by a broad mass of people is to be sure everyone uses our tree as authoritative, and that can only happen if we keep the drivers the real devices need
<mnemoc>
we have one mali version which matches the userspace libraries, that help to be sure everyone is using the same version and integration and makes possible to support people using A10 devices in real life
<mnemoc>
we can't stay "pure" and have users at the same time
<mnemoc>
that also doesn't mean to accept every random driver included
<mnemoc>
only those actually needed by broadly available devices
<mnemoc>
in the case of the wifi drivers, we can't trash allwinner's until we have mainline's working
<mnemoc>
same with the wemac driver
arokux_h has quit [Quit: Leaving]
<mnemoc>
of course we need to get rid of the allwinnerizations, but that can't (imo) be done at the expense of making the tree useless for people...
<mnemoc>
similar case with memory detection. we can't trash allwinner's hack until we have a working alternative
<mnemoc>
</end-of-self-defense>
gimli has quit [Quit: Verlassend]
<hno>
mnemoc, yes, but those drivers can perfectly fine live in a separate subfolder easily identified. No need to merge them as if they were merged to the kernel.
<hno>
heck, even the "build.sh" script approach works for keeping users, automating the build of kernel + out of tree modules.
<mnemoc>
hno: so you want to move everything that isn't core sunxi to modules/ ?
<mnemoc>
I fail to see what's that bad in having essential-but-not-core drivers build in `make modules`