<larsc>
wolfspraul: the display is super stable now. even without setting the undocumented registers
<vegyraupe>
wolfspraul: wow! great! yippie!
<wolfspraul>
larsc: oh, why that?
<wolfspraul>
larsc: about more recent kernel versions, I read somewhere 2.6.33 introduced something called 'compressed memory'. could this be helpful on the ben?
<larsc>
wolfspraul: i used their init sequence, just without the undocumented registers
<wolfspraul>
hmm, OK
<larsc>
wolfspraul: yes, it can be used and i've already been looking into it.
<wolfspraul>
if you can tell me the numbers of undocumented registers I can still ask
<wolfspraul>
zear: you would have to buy more like 50K and become a big disti for Poland :-)
<wolfspraul>
but yes, I share your sentiments and of course we work on this stuff
<zear>
haha, not gonna happen ;D
<wolfspraul>
who knows
<wolfspraul>
if I can sell you these phones for 15 USD a piece, and we can get really functional software on it, you might find people in Poland that are very interested in financing it all. like large retail chains etc.
<wolfspraul>
but lots of pieces are missing still
<zear>
if it had features like encrypted calls and texts
<zear>
then it would probably sell good
<wolfspraul>
so one by one
<wolfspraul>
osmocom is being developed
<wolfspraul>
it's a long long way
<wolfspraul>
I'm actually somewhat doubtful about the GSM stacks since they are huge and moving forward
<wolfspraul>
but the project is great still, and if I can support it a bit from the MTK side I'm happy to do that
<wolfspraul>
this is 'alpha' stage though
<zear>
so it's gonna take years, eh?
<wolfspraul>
yes
<wolfspraul>
realistically
<wolfspraul>
actually the Ben is a step there
<zear>
still, it's something really interesting
<wolfspraul>
you just need to see all the pieces
<wolfspraul>
but unfortunately there are lots of pieces
<wolfspraul>
that's why the SAKC, even Milkymist One, Elphel cameras, etc. all fit into this
<wolfspraul>
we'll see
<wolfspraul>
so for this wiki page, yes I bought some of those phones, and tried to see how cheap & fast I can dig into the PCB
<wolfspraul>
was quite successful
<wolfspraul>
I basically found a shop on the street that can do what you see on that wiki page for 100 USD in 2 days or so
<zear>
is it a form of reverse engineering?
<wolfspraul>
I'm not going to distinguish between forward engineering and reverse engineering.
<wolfspraul>
I only do forward engineering :-)
<wolfspraul>
I buy phones, then I take apart my property.
<wolfspraul>
those pictures are lined up in physical order, i.e. you can zoom through the product
<zear>
i can only imagine how many iphones that company gets for taking apart :D
<wolfspraul>
not many
<wolfspraul>
no point
<wolfspraul>
there is not that much design work in the PCB anyway
<zear>
to produce cheap ripoff, i guess ;)
<wolfspraul>
no no
<wolfspraul>
it's all different than you think :-)
<zear>
ah
<wolfspraul>
so anyway, did this explain the C3100 page in the wiki?
<zear>
well, yeah, the PCB is completely different in the ripoffs, they just use the same form factor and look like the originals
<zear>
i guess so :)
<wolfspraul>
it's a support effort for a neighboring project, osmocombb
<wolfspraul>
we'd love to do just what you are asking for
<wolfspraul>
a phone that looks like a phone, and runs 100% free Linux
<wolfspraul>
believe it or not, by buying a nanonote, and hacking on it, and helping us with kernel, apps, Debian, etc. you are contributing towards that direction
<wolfspraul>
at least I hope so, and we don't die before reaching the goal :-)
<zear>
:D
<zear>
just don't follow the way of openpandora and you'll be fine ;)
<larsc>
what did they do wrong?
<zear>
taking preorders for unexistant hardware
<zear>
it's about 3 years since they started the preorders
<zear>
and they still don't have a finished product
<wejp>
yeah, that really sucks
<zear>
and in the meanwhile many people resigned
<wejp>
also they are not building open source hardware, so you can't really compare that anyway
<zear>
and they had to return their preorder money back
<vegyraupe>
zear, wejp: the problem is not the way they finance the project, but the fact that they had no idea what they were getting it to
<vegyraupe>
it = in
<wejp>
vegyraupe, yes you are right, that is the biggest problem there
<zear>
i agree
<vegyraupe>
if you don't wanna be dependent on some ppl with big money you have to find alternative ways
<vegyraupe>
and I like the approach of community supported development better and better
<zear>
btw, when can we expect any public information about how are the bens selling?
<vegyraupe>
of course with modifications to OP's way, but the same general idea
<wejp>
vegyraupe, yes, but in case of "open pandora" except the money they took for the preorders from the community, there hasn't been ver much influence on the actual product by the community
<vegyraupe>
wejp: as I said with modifications ;)
<vegyraupe>
I would see the community as the customer
<vegyraupe>
so the customer creates specs
<wejp>
not that i don't like the hardware design, i do, but still, it was only a very small group of people building a handheld console
<vegyraupe>
the company makes an offer
<vegyraupe>
and then the customer looks over it
<vegyraupe>
and the two parties agree to a plan
<wejp>
yyeah
<vegyraupe>
when modifications need to be made
<vegyraupe>
it goes back to the customer for a decission
<vegyraupe>
and of course the customer wouldn't pay the whole sum up front
<vegyraupe>
but only part of it to finance development
<wejp>
problem with the pandora was, it turned out to be even more expensive than what they got through the preorders
<vegyraupe>
i don't follow them that closely
<vegyraupe>
but I am sure if that happened than probably because they hadn't done anything like that before
<wejp>
yes
<vegyraupe>
and considering that, it is actually amazing what they built
<wejp>
of course it is
<vegyraupe>
i thinkit is a very good proof of concept and commendable that they even tried
<wolfspraul>
zear: we sold about 500 Ben so far
<zear>
wolfspraul, of how many in total?
<wolfspraul>
which is a good start, roughly in line with my estimates. Problem will be to sustain it now, which depends on improving software.
<wolfspraul>
zear: first batch we made 1000
<zear>
i guess that's a good result?
<wolfspraul>
we are taking all this very carefully
<wejp>
oh 500 sold out of 1000 isn't bad :)
<wolfspraul>
we are spending a lot of time to visiting vendors, digging deeper into the production process
<wolfspraul>
well we need to sell all 1000
<wolfspraul>
and then the second 1000
<wolfspraul>
etc
<wolfspraul>
:-)
<wejp>
sure :)
<wolfspraul>
also drive price further down
<wejp>
i'm sure a future nanonote version which comes with wireless included would sell much better as this seems to be what most people interested in the device complain about in the first place. i for myself would be fine with just having usb host port (preferably a type a connector on the device), but internal wireless would be nice too
<wolfspraul>
my current Ya NanoNote looks like Ben, but 4760 CPU, USB On-The-Go, more RAM (maximum supported by one chip), hopeRF RF module
<wolfspraul>
but who knows it's all moving
<wolfspraul>
the seeds are growing
<wejp>
how much RAM does the CPU support?
<wolfspraul>
which one?
<wolfspraul>
the goal now is to max out the Ben
<wejp>
the one you've chosen for the Ya
<wolfspraul>
don't know
<wolfspraul>
for one it support mobile DDR
<wolfspraul>
finaly
<wolfspraul>
Ben has SDRAM
<mortys>
Hi all
<wolfspraul>
wejp: 'chosen' is the wrong word, we haven't chosen anything
<wolfspraul>
focus now is Ben
<wejp>
btw, the cpu speed of the ben which i would least complain about, memory bus is a little thin but cpu speed is fine
<zear>
what is a rf module? some sort of a wireless radio?
<wolfspraul>
we need to show that we can bring out the performance of the HW to the normal end user
<wejp>
wolfspraul: yeah, i understand, i meant just the configuration you spoke about :)
<wolfspraul>
zear: yes
<wolfspraul>
there were some mails about it on the list. just being evaluated right now, together with many other things...
<wejp>
so you are going with USB OTG to be able to keep the same case?
<zear>
yeah, read the mails already
<zear>
but i don't really understand the idea behind it ;)
<wolfspraul>
zear: what do you mean with "don't understand"?
<zear>
well, what it could be used for
<zear>
is this a well know and popular standard, that many devices use?
<zear>
*known
<larsc>
otg?
<zear>
on the go, can pair two otg devices without a need of usb host
<larsc>
no, i was wondering if you were asking about otg
<wejp>
not only that, you can also attach a usb slave device to a usb otg capable device
<zear>
no, i was asking about the RF
<wejp>
i was asking about otg, if it has been "chosen" to be able to keep the ben nanonote case
<zear>
wejp, so how is it different than a host then?
<wejp>
zear, it can also run as normal slave mode, and the connector is usually the small slave port, not the large type A port
<zear>
wejp, that means it requires a mini>normal converter
<larsc>
otg is basically a host and a device behind a inteligent transiver which decides which one is to use
<zear>
i have one and it's like 2,5cm big
<wejp>
zear, yes
<wejp>
that's why i would prefer a USB A type port on the device, but i understand if this will not be done, to keep the ben case as it is
<zear>
yep
<vegyraupe>
wejp: do you have any plans on making gmu playing videos as well?
<zear>
ha, that would be cool
<vegyraupe>
zear: +1 :)
<zear>
vegyraupe, but you mean a video support written from scratch, or some kind of a gui for mplayer?
<vegyraupe>
zear: no idea about the details :)
<wejp>
vegyraupe: writing a video plaer isn't a simple task, so it requires a lot of work to do that
<wejp>
i'm not sure yet, if i'll do that. maybe i'll put some work into videoplaying when it is mostly feature-complete from the musicplayer point of view.
<zear>
it is mostly feature-complete music player already :)
<wejp>
zear, it it mostly is, there are only a few things left, i would like to add :)
<zear>
:)
<wejp>
and if you have every looked at ffmpeg (which one could use for creating a video player), you probably know that even doing very simple things with that library are rather complicated to say at least
<wejp>
s/every/ever
<zear>
yeah, i always have to study the manual before i do anything with it
<wejp>
and that does not even involve putting a video on the screen yet
<wejp>
which also needs to be done, and it needs to be done in a fast way
<vegyraupe>
just wanted to spark the thought :)
<wejp>
then, ou need to keep video and audio in sync...
<wejp>
hehe, yeah, that's fine :)
<zear>
oh, i didn't even know there's a "ffplay"
<wejp>
i just wanted to point out that this is a rather long way to go, if i want to do that ^^
<zear>
should it be faster than mplayer?
<vegyraupe>
coz then one could create a "mediaplayer" which comes with gmu as the graphical interface :)
<wejp>
zear, not necessarily
<vegyraupe>
create here: build
<wejp>
vegyraupe that could be an option, but i don't like it that much becaue until now, Gmu is a stand-alone player that does not need an external program to play stuff
<wejp>
of course you need some librarries but it doesn't call external programs
<vegyraupe>
external programs?
<zear>
write your own video processing lib then :D
<wejp>
well, i'll think about the whole video stuff a little  :)
<vegyraupe>
wejp: by mediaplayer I meant a physical device
<wejp>
zear, hehe, yeah, if i find the time to do that :D
<wejp>
vegyraupe, oh, ok i see :)
<vegyraupe>
my sis bought one of these
<vegyraupe>
sized as a cheap digi cam
<vegyraupe>
with a screen
<vegyraupe>
and earplugs
<wejp>
i agree that it would be nice to use the same interface for all media formats
<vegyraupe>
and all it does is play videos and music
<vegyraupe>
and the avt2 boards and even teh ben is not too far away from that
<wejp>
eah
<wejp>
y
<wejp>
argh, my y button works only every second time i hit it or so
<zear>
vegyraupe, weird thing is, that even with ingenics patches and with an ipu, mplayer on the dingoo is really, really slow
<zear>
you can't play anything greater than 320x240 without lags
<wejp>
the video player from the default firmware isn't much better though
<zear>
well, mplayer has to scale everything to 320x240 anyway, but it's more convinient to just let it play a dvd quality movie than to fiddle with ffmpeg and convert it to 320x240
<vegyraupe>
zear: that's not quite my department ;)
<zear>
:P
<zear>
not to mention a nononote, which has less available ram
<zear>
*nanonote
<wejp>
does the nanonote cpu even have the ipu?
<zear>
hmm.. no idea
<wejp>
it does have those SIMD instructions, but the IPU is an entirely different thing
<wejp>
i think only the 4740 has it not the 4720, but i could be wrong
<larsc>
both have it
<wejp>
yeah, just checked the datasheet, you are right
<larsc>
the only real difference between 4720 and 4740 is the form factor and the pin which are available
<wejp>
still, if the dingoo has problems with playing videos it will be a real challenge to get that working on the nanonote. the dingoo has twice the memory bandwith compared to the nanonote :|
<wejp>
d
<zear>
ingenics mplayer compiled for the nanonote using dingux toolchain just segfaults for me :P
<wejp>
mh
<wejp>
do you know where it segfaults?
<zear>
same with the binary some other guy from the community compiled and claimed it worked for his ben
<tuxbrain>
video conversation yummy yummy
<wejp>
:D
<zear>
wejp, nope, didn't bother bugtracing it
<wejp>
ok
<wejp>
need valgrind on the ben :D
<zear>
*bug tracking
<zear>
i heard valgrind is good, it helped my coder to track one nasty bug with the Tower of Gowno for the pacc contest
<zear>
we couldn't find it with either gdb or strace
<wejp>
yes, valgrind is a great tool
<wejp>
i like it much better than stupid gdb
<cain__>
good morning
<cain__>
I have a little question
<cain__>
how can I return to console from gmenu2x?
<xiangfu>
cain_, CTRL + ALT + F1.
<cain__>
thanks xiangfu
<xiangfu>
cain_,  you can edit /etc/inittab. remove the "tty5/6/7/8"
<xiangfu>
cain_, then you can go back to gmenu2x by CTRL+ALT+F5
<zear>
me too, though do we really have a place for it?
<wejp>
well maybe not in the middle of the keyboard, but rather above it between speaker an microphone
<wejp>
i would like that better than a touchscreen
<zear>
yeah, unless there's something on the PCB in there
<zear>
same
<wejp>
yeah, not sure if it is, but shouldn't be difficult to find out :)
<darfgarf>
if anyone's interested, i'll be doing a proper release of nupdf later tonight
<vegyraupe>
darfgarf: hui, cool
<tuxbrain>
darfgarf: Yay!!! I was waiting for this :)
<darfgarf>
sorry for taking so long, the competition judging dragged on
<darfgarf>
(came 9th)
<tuxbrain>
I have not understand a word about you have said :P
<darfgarf>
tha's ok XDÂ Â nothing important
<tuxbrain>
not pushing at all, but you will do a Makefile to proper include on next distro?
<zear>
tuxbrain, the pacc competiton darfgarf (and me) participeted in has finished the 31th march, but the results of the contest were announced today
<tuxbrain>
ok :)
<zear>
btw, is it "on 31th" or "at 31th" or yet somehow different? :P
<darfgarf>
tuxbrain: maybe, but i don't know much/anything about packaging for openwrt, and it's 1 month until exams start  (zear, 31st :P)
<zear>
so "the" wasn't needed as well? :P
<darfgarf>
the 31st yes
<darfgarf>
or you could ignore it
<zear>
so i was right after all, hooray for me! ;P
<tuxbrain>
darfgarf: Ok, just make it compile and tell us what are the dependencies, someone (maybe me) will do the work of doing the Makefile, I think this is a key piece of soft for nano
<zear>
i suck at prepositions :P
<zear>
darfgarf, owrt toolchain is a nightmare to set up
<darfgarf>
tuxbrain: i'll include the compile scripts i use, and also compile it statically, so it can just be dropped in and used
<zear>
it's not as simple as throwing it to /opt and exporthing the path
<zear>
btw tuxbrain, is there any pdf reader for the wiz?
<darfgarf>
zear: so it can wait or be done by someone else, i shouldn't even be touching it but it's the end of the week and i haven't stopped work at all
<zear>
i could recompile nupdf for it
<darfgarf>
zear: think there is
<darfgarf>
look up Mipdf
<tuxbrain>
zear, really I dont understand why you have the need of move the tolchain , it's easier to do the Makefile really
<zear>
darfgarf, ah, you're right
<zear>
tuxbrain, because i want to just export the path and run ./configure --host= --target=
<zear>
and with the owrt toolchain you have to manually edit the makefiles becuse libs are located in an unusual place
<zear>
(the whole toolchain is divided in two dirs)
<tuxbrain>
I supose is an advantage being an ignorant in this case, cause I 'm not used to  compile in anyway , anyway is fine for me :)
<zear>
i might be wrong after all
<zear>
i hope i am and there's an easy way to set up owrt toolchain :)
<darfgarf_>
meh, i'll put it as a todo at the end of a very very long list of things
<zear>
:P
<tuxbrain>
owrt is thinked to do full firmware and I think is good for that porpouse, I might recognize is not such ergonomic for individual ports, but in the long run (make things manteinable on time) I think is a better aproach
<zear>
yeah, i agree to that
<zear>
but that also means you need to set up every single new port to work with it
<zear>
and that takes time
<darfgarf_>
and keep it compatible with the dingoo at the same time
<zear>
it's just a matter of a makefile
<darfgarf_>
though that's just doing things in a slightly different way really
<zear>
if you have one single makefile for your project, it should be compatible with both the dingoo and owrt
<tuxbrain>
I hope we should find a way to make two words compatible
<zear>
just use different makefiles for dingoo and owrt
<zear>
we could always do a standalone owrt toolchain