<Textmode>
is "del" mapped to anything, or do we just have backspace?
<Textmode>
don't suppose theres any way to change the default console font?
<arctanx>
Textmode: I haven't tried, but the usual kernel console font selections are available through make kernel_menuconfig
<Textmode>
at compile-time?
<arctanx>
Yes
<Textmode>
I'll probably mess with that at some point, but not any time soon.
<Textmode>
I don't suppose theres anything like a xterm for nn? :P
<arctanx>
I was about to say
<arctanx>
There's a framebuffer terminal described somewhere on the wiki
<arctanx>
and that does support different fonts and UTF-8
<arctanx>
I've forgotten what it's called already though :/
<Textmode>
ah, cool. I'll look there.
<arctanx>
fbterm, that'd be it
<Textmode>
sounds like a likely name for it.
<arctanx>
Ah it was on the debian page. It doesn't appear to be in the openwrt feeds
<Textmode>
no, I was just noticing that.
<arctanx>
I'm sure you could get an xterm running with a framebuffer x11 driver though
<Textmode>
was more wondering how hard it would be to build fbterm from source.
<Textmode>
on a related aside, I don't suppose anyone has taken the time to figure what the differences are between the dingux toolchain, and the nn's openwrt toolchain are?
<xdpirate>
hahahahaha
<xdpirate>
guess who's running win 3.11 on the nanonote
<Textmode>
lol
<xdpirate>
:D
<arctanx>
uuh, emulated right? :P
<xdpirate>
ofc, dosbox
<arctanx>
aah cool
<xdpirate>
:3
<arctanx>
did you build that yourself or have you put debian on there?
<arctanx>
Textmode: I cloned the most recent openwrt-xburst and having done a build, had a working toolchain in staging_dir/some_stuff/usr/bin
<arctanx>
it builds a toolchain as part of the image-building process
<xdpirate>
any way i can see the status of a process via telnet? i'm not sure whether dosbox just screwed itself over or not
<Textmode>
telnet, then run top?
<xdpirate>
thanks
<Textmode>
arctanx: how big is this thing? I'm being shaped...
<xdpirate>
wat, dosbox isn't even appearing on the list
<arctanx>
Textmode: pretty big. I can't remember how much exactly but it's in the order of <100MB and it downloads more stuff when you build
<Textmode>
:/
<Textmode>
the build is long, too, isn't it?
<arctanx>
yep, it took at least a couple of hours and then I left it overnight
<arctanx>
I'm sure a binary shapshot of the toolchain could be extricated.. my own would be amd64
<Textmode>
i'd have to boot the other comp to make use of that, not so great :P
<arctanx>
Now openwrt is teaching me how to make cocktails... I love this device
<Textmode>
yeah, that message confused the hell out of me the first time I saw it.
<Textmode>
since apprently I can't get through this w/o rebuilding the kernel anyway, where the are options for console font hiding?
<Textmode>
bah, its getting too late for me
<arctanx>
Pro-tip: if you build openwrt-xburst, don't move the dir unless you want to build the whole thing again
<arctanx>
apparently some absolute paths have snuck into the build process and mess it up
<rafa>
tuxbrain: you there?
<rafa>
larsc: ?
<rafa>
zear: it seems that the problem with this mplayer is that it already has a libavsync library built. And we can not build it because no sources.. That I did was tell mplayer do not avsync (with -autosync 2000 for example).. and it seems that mplayer works nice now. BUt it is just a workaround.
<zear>
ah, great we at least found the culprit
<zear>
and that there is a workaroudn
<zear>
*workaround
<rafa>
yep
<rafa>
there is something weird with kernel btw.. sometimes I build it after a clean and sound worked, sometimes after a clean and build sounds does not work. I hate the word "SOMETIMES" :P
<rafa>
and I do not know why it happens.
<rafa>
the official kernel in openwrt brings alsa driver as module.. I have always tried to put it inside the kernel binary. I am guessing that perhaps they have the alsa as modules for some reason :)
<zear>
but it is after you build it or after you start the system?
<rafa>
well, I build on pc, cp the kernel to SD and then start the system
<rafa>
sometimes after a clean building it works, sometimes no
<zear>
ah, i see
<{marcz}>
rafa: as I have some problem with sounds, I'm interested in what you observe
<rafa>
{marcz}: yeah.. we are not going to change sound hardware so I do not know why the official kernel brings the alsa drivers as modules and no inside the kernel.
<{marcz}>
Myself I have sound as output, but the recoding is also sound but completly distorted
<{marcz}>
Of course, but I don't know if it comes from my soft or hard, I have until now compiled also the sound modules in modules.
<rafa>
okey, good to know.
<rafa>
I would like to have it always inside, because the hardware sound will be always there.. but well. We will see if that is not a problem now.
<{marcz}>
I have just noticed that the order of loading modules is very important, if I let go by default, I come up with some modules loaded and I cannot load the remaining.
<rafa>
do you have that order?
<{marcz}>
In this case snd-page-alloc crash and I cannot get the device.
<rafa>
perhaps there is the problem.. something bad in init..
<rafa>
could you tell me the order of the modules?
<{marcz}>
My nano is not with me presently, but you can either take in order the order in the openwrt image under /etc/module.d or a post of bebajoth two days ago in the mailing list. I personnaly use less modules but the canvas is that.
<{marcz}>
But my own problem is OK for output and not input, ruben said me that he has both very good, so I don't know if my peculiar mic is defective or if it is my kernel (but why?)
<{marcz}>
:time
<calamarz>
hi
<calamarz>
for reflashing just the kernel I don't need to erase the whole nand, right?
<xiangfu>
calamarz: yes.
<xiangfu>
calamarz: for reflashing bootloader and kernel are don't need to erase nand.
<calamarz>
tx
<calamarz>
xiangfu: you said you had compiled a debian kernel with snd modules statically linked?
<xiangfu>
calamarz: yes. it can play music but very very slow.
<xiangfu>
calamarz: I only use 'mplayer' to test play sound
<qi-commits>
nbd: backport the latest version of the mac80211 package to backfire. includes fixes for wpa key handling, throughput issues, etc. http://qi-hw.com/p/openwrt-xburst/262b52b
<kyak>
at last i'm holding this thing in my hands :)
<kyak>
it is smaller than i thought!
<kyak>
so awesome..
<zear>
:D
<zear>
kyak, but you know what's the coolest about it? You can type commands on it on the go
<zear>
hold it in your hands and type with thumbs
<kyak>
root@BenNanoNote:~# uname -a
<kyak>
Linux BenNanoNote 2.6.32.3-g023227d-dirty #1 PREEMPT Wed Jan 13 20:53:27 CET 2010 mips GNU/Linux
<kyak>
yay!
<kyak>
zear: yeah, it's like mobile phone :)
<kyak>
okay
<kyak>
now for the software update thing
<kyak>
i have to get used for keyboard layout
<kyak>
we should perhaps hold a contest for the fastest typing on NN sometime :)
<kyak>
and the coolest thing is.. i have this damn small wifi card
<kyak>
but first things first
<kyak>
zhangyi: fyi, the parcel has been received. So it took 12 days to ship to Russia :)
<kyak>
zhangyi: thanks a lot for your effort!
<zhangyi>
kyak: great! i'm glad to hear it! :)
<zhangyi>
kyak: any time.
<zhangyi>
kyak: will update our shipping notes :)
<kyak>
you can also mention that EMS likes to come to your home without any prior notice and then call you in the middle of the day asking "where are you"?: )
<kyak>
luckily, i had someone who could accept the parcel at home
<sdschulze>
cross-compiles openwrt-xburst.
<sdschulze>
Is there a lot you can do wrong?
<nebajoth>
holy crow
<nebajoth>
I cannot figure out how to adjust the volume of this thing
<sdschulze>
alsamixer?
<sdschulze>
works on openwrt, at least
<nebajoth>
it doesn't do anything
<nebajoth>
it loads
<nebajoth>
it identifies the proper card
<sdschulze>
hm
<nebajoth>
you can nudge the volume up and down
<nebajoth>
but the actual playing volume remains the same
<sdschulze>
How did you get sound support in the first place, BTW?
<sdschulze>
(I assume you're on Debian)
<nebajoth>
I am on Debian
<tuxbrain>
press M
<nebajoth>
and I loaded the module list
<nebajoth>
from openwrt
<nebajoth>
and it works
<sdschulze>
:(
<sdschulze>
That's what I did, too.
<nebajoth>
muting works, tuxbrain
<nebajoth>
just not volumen adjustments
<sdschulze>
Maybe my tarball was too new, though.
<nebajoth>
actually
<nebajoth>
it seems as though I can raise the volume a little
<nebajoth>
but not diminish it
<nebajoth>
at all
<nebajoth>
from the very loud default
<sdschulze>
nebajoth: Where did you get the modules from?
<nebajoth>
the openwrt image
<sdschulze>
I copied mine from openwrt-xburst-rootfs.tgz.
<nebajoth>
same thing
<nebajoth>
interestingly
<nebajoth>
even on mute I can hear it very softly
<sdschulze>
snd_soc_core: Unknown symbol i2c_transfer
<sdschulze>
That's what i get.
<kyak>
software usb boot + ./reflash_ben.sh did the job (at the first attempt)
<kyak>
i guess i'll keep this magical USB cable :)
<kyak>
it's from Nokia N76, as that matters
<kyak>
guys
<kyak>
there is horizontal lines on the LCD (a noise) when Ben is connected to USB
<kyak>
is it ok?
<kyak>
i also notice such flickering when it is close to my laptop
<kyak>
hm
<kyak>
it really is flickering badly
<zear>
kyak, the flickering is my fault i think
<zear>
gmenu2x was compile with jz4740 overclock code
<zear>
and it overclock the lcd timings as well
<zear>
and that results with flickering
<zear>
*compiled
<zear>
oh, i think that's an unrelated flickering, sorry for not reading the rest of the messages
<kyak>
no, it might be related.. let me disable the gmenu2x autostart and we'll see..
<kyak>
it's rock stable now
<kyak>
even if i put Ben on laptop's wifi card
<kyak>
hm.. i inserted usb cable and the screen went black
<kyak>
ok.. i need to get used to inserting usb cable without pressing the power button by accident :)
<kyak>
i think most of you guys are not using gmenu2x, right?
<zear>
well, i am ;P
<kyak>
and it's not flickering for you? ):
<zear>
it is ;P
<zear>
though i don't care because i rarely use my nanonote (mostly just use it as a music player)
<kyak>
ok, i haven't found a use for mine yet :)
<kyak>
though i found gmenu2x keybindings weird
<kyak>
"enter" is launching settings, not the selected icon
<zear>
well, it's the best i could do
<zear>
with the gaming console layout gmenu2x was designed for
<kyak>
so how do i select?
<zear>
and you can always modify the controls in /usr/share/gmenu2x/input.conf
<zear>
"x" if i remember correctly
<kyak>
SELECT: Bring up the contextual menu.
<kyak>
whereis "select"? :)
<zear>
select is esc
<zear>
start is enter
<kyak>
zear: this is weird.. any way to remember this?
<zear>
L is q, R is P
<kyak>
i mean, is there some logic behind?
<zear>
the rest of the buttons (a/b/x/y) are s/d/z/x
<zear>
yes
<kyak>
i need to imaging game console?
<zear>
exactly ;)
<kyak>
like dendy controller? :)
<zear>
more like a dingoo
<zear>
though, the "front buttons" are on the left and the d-pad is on the right here on the nn
<zear>
but as i mentioned before, edit /usr/share/gmenu2x/input.conf to customize your controls
<zear>
i asked the author for the sources, i hope he will agree to release this app on GPL
<calamarz>
zear: looks cool indeed :)
<sdschulze>
notices that native compilation is *really* slow.
<emeb>
sdschulze: what distro you running native compile on?
<sdschulze>
Debian
<sdschulze>
trying to make-kpkg
<sdschulze>
eeek... virtual memory exhausted
<emeb>
sdschulze: ah - I'd heard Debian had a native compile. Wish there was a gcc ipk for OpenWRT.
<emeb>
not surprising that there aren't enough resources for a big compile on the NN.
<emeb>
I'd still like to do it for small stuff though (drivers, quick utils, etc)
<sdschulze>
Maybe I can misuse my microSD card for occasional swapping.
<sdschulze>
Native compiling is cooler than cross-compiling. :)
<sdschulze>
What's the preferred way of making "partitions" on SD cards?  losetup?
<emeb>
fdisk?
<sdschulze>
SD cards have physical partitions?  Nice.
<sdschulze>
Do I need any special tricks to boot from SD card, BTW?
<sdschulze>
so the bootloader finds the kernel and the kernel finds the root fs
<sdschulze>
At least it seems to like that swap.
<sdschulze>
Are there any general objections to making a partition table on the NAND flash, BTW?  Does it interfere with the block structure or anything?
<{marcz}>
MTD is not a block device!
<kyak>
wejp: could you please help? should i install libmpg123 for mp3 support in gmu?
<sdschulze>
{marcz}: So that's the reason why they're not partitioned?
<calamarz>
mp3 is evil ]:)
<sdschulze>
kyak: I haven't tried it, but I assume you have to recompile it.
<sdschulze>
Better: convert all files to Ogg Vorbis
<{marcz}>
You install your file system jffs2 or ubifs over an UBIÂ Â layer that emilate a block device.
<sdschulze>
obviously, yes
<sdschulze>
But having the partition tables hardcoded in the Linux source code is not that nice.
<{marcz}>
Of course their is no problem to partition a SD card
<{marcz}>
But a flash MTD is not the same, it has not the buil-in device driver
<sdschulze>
So if you press M, uboot automatically looks at the partition table of the SD card and uses the first one for the kernel and the second one for rootfs?
<{marcz}>
To partition a SD card you can go with fdisk exactly in the same way you do on a disk
<{marcz}>
If you are on bnn you have to use a compiled command line in the uboot image
<sdschulze>
Is using raw access to MTD faster than putting a driver between the flash and the CPU?
<{marcz}>
On the distribution of openwrt Xiangfu has set up a command line to boot from uimage on the fat partition N° 1
<sdschulze>
I do miss GRUB so much. :(
<{marcz}>
The main problem is wear levelling, in SD card it's done by the driver, so you can put over whatever fs you want.
<urandom_>
kyak copying libmpg123 and mpg123 from dingux version works nice
<sdschulze>
{marcz}: Where does the SD card driver store the information on where the virtual blocks are mapped in the flash mem?
<{marcz}>
On MTD the block layer take care of it so you are using layer that can provide this wear leveling: ubi then ubifs, or jffs2
<emeb>
OK - here's another annoyance: gmu disables the display after a bit. If you've switched to an alternate console it still disables it. How to get it on again?
<urandom_>
emeb you can disable switching off the display in the config
<emeb>
urandom_: cool - will have to do that. Meantime, how to get the display back on w/o a reboot?
<Textmode>
usually hitting any key brings it back
<Textmode>
I use the qi key
<emeb>
Not if you're in another console tho...
<Textmode>
no...
<urandom_>
change to its console
<emeb>
need to ctl+alt+f5 to get back to gmu screen
<emeb>
then hit spc or something
<emeb>
Does SDL always live on the f5 console?
<urandom_>
yeah you have to ctl+alt+f5, it cant get input from different console
<urandom_>
yeah it seems to be the place for the sdl stuff
<emeb>
xdpirate: came up with a couple of makefiles for keycode - want 'em?
<xdpirate>
huh? for what? =P
<xdpirate>
i don't really need a makefile when all i did to compile was gcc main.c -lSDL -lSDL_ttf -o keyCode
<emeb>
g'nuff.
<xdpirate>
;3
<xdpirate>
my nn refuses to load sdl altogether after i copied the dingoo sdl libs like zear said lols
<emeb>
urp
<xdpirate>
meh
<emeb>
what did zear say to do?
<emeb>
(btw is NN gmu statically linked to SDL?)
<xdpirate>
they're built with joystick support
<xdpirate>
i have no idea emeb, ask wejp if he's here
<xdpirate>
(wejp made gmu)
<emeb>
just wondering why there was no SDL lib on NN already.
<xdpirate>
there is
<emeb>
hrm - I didn't see it...
<urandom_>
there is, just no sdl-mixer
<xdpirate>
all sdl libs should be in /usr/lib, except sdl_mixer
<emeb>
urandom_: ur right. I'm getting confused
<emeb>
SDL lib wasn't in the openwrt host build dirs
<emeb>
for some reason the openwrt build process doesn't give you the same image/s that are under 'latest'
<emeb>
seems like there's a bit of extra tweakage going on behind the curtain...
<urandom_>
wouldnt things going on behind the curtain be against the qi ideologie?
<urandom_>
:P
<Textmode>
probably an oversight.
<Textmode>
easy enough to do.
<urandom_>
yeah
<xdpirate>
As I mentioned, my SDL libs got fucked up
<xdpirate>
Could anyone cp /usr/lib/libSDL* /card/ and upload them in a zip or something?