<lekernel> what's the difference between "line out" and "line level out"?
<lekernel> the wm codec has both
<lekernel> atm we're using the "line out" and it works, so i guess we'll stick with that
<lekernel> hi aw
<lekernel> could you get samples of WM9707? we'll probably use it in the end
<aw> lekernel, hi evening
<aw> yes, i can order some of them.
<aw> still reading your email. :-)
<lekernel> yeah... you should read the IRC log too :)
<aw> okay...i may change some capacitor with low ESR to have extremely lower ripples from power supplies to check.
<lekernel> you think the noise might come from power supply caps?
<lekernel> FYI: I'm using the WM codec without noise now
<lekernel> I have fixed some problems in the FPGA design that prevented it from working correctly
<lekernel> and now we have noise free audio
<aw> yes, WM may have different performance noise reduction tech...yup? also fixed on fpga design?>>> sounds great.
<aw> you used WM codec in RC1 not RC2, right?
<roh> aw: ack. it was a fight!
<roh> not for the wm.. that one came out easy... the video adc was hard
<roh> i either need nozzles for that tqfp stuff or much more experience ;)
<roh> aw: can you tell us about your hot-air experiences, give some tips?
<aw> roh, yup, such skilled tech. you have is great. :-)
<lekernel> yeah, I took a RC1 board
<aw> well...last week i just used hot-air to rescue one damaged RC2 board with all ICs,
<lekernel> roh: well, with the bigger nozzle it wasn't so hard
<lekernel> and leaded solder doesn't have so much tendency of forming balls behind the pins
<aw> lekernel, okay..the layout/schematic between rc1 and rc2 is quite different, so i may yes order WM to replace it on my rc2 for confirmation.
<lekernel> aw: the WM chip requires a few modifications
<aw> lekernel, yup, can imagine. :-)
<lekernel> remove 1M resistor on crystal, add capacitor on pin 33 (for 3D effect, optional), add capacitors on pin 32
<lekernel> I have uploaded the datasheet to the git repos. please have a look at it
<aw> okay..
<lekernel_> <lekernel> remove 1M resistor on crystal, add capacitor on pin 33 (for 3D effect, optional), add capacitors on pin 32
<lekernel_> I have uploaded the datasheet to the git repos. please have a look at it
<lekernel_> also, we might also want to route SPDIF to the internal connector and DNP the parts for the nonexistent headphones amp
<lekernel_> you should also recompile the test program
<aw> lekernel_, um..seems lot of works to be learn on my side. ;-)
<lekernel_> btw i'm running the demo console in 800x600 resolution atm
<aw> has this changed by SoC or s/w porting enough?
<lekernel_> some dirty soc hacks
<aw> umm.:-)
<lekernel_> 1024*768 wouldn't work though. well, maybe with more buffering
<aw> lekernel_, do you think that we still need U23 if change into WM in the end? or not necessary.
<lekernel_> the 4.3V regulator?
<lekernel_> well... could be a good idea to protect against incoming power supply noise
<lekernel_> at least we have more safety if we happen to pick up a noisy transformer
<aw> I probably also order some low ESR capacitors to replace C215 10uF. As a recommended part there in datasheet. ;-) yeap, seems use it as a seperated circuitry part.
<aw> i saw some doc the 'white' noise can come from bad ripples from power supply, but we didn't test though. :-)
<lekernel_> power supply?
<lekernel_> I checked it on scope... looks clean
<lekernel_> but you can still double check :)
<aw> yeah, double check is good after replace a low ESR capacitor. :-)
<xiangfu> lekernel_: Hi. I am working on try to create the /dev/flash5 image.  then ender user can easy flash that by using urJtag. got more patches and wallpaper.png
<xiangfu> lekernel_: I think I mis-understand your task about default wallpaper.
<xiangfu> so I talk with wolfgang about my task on milkymist one.
<xiangfu> something wrong with the "www.milkymist.org"?  always give me connect timeout. and
<xiangfu> --- www.milkymist.org ping statistics ---
<xiangfu> 11 packets transmitted, 0 received, 100% packet loss, time 9999ms
<xiangfu> xiangfu@fidelio:~$ ping www.milkymist.org
<xiangfu> PING www.milkymist.org (69.163.150.252) 56(84) bytes of data.
<xiangfu> ^C
<xiangfu> --- www.milkymist.org ping statistics ---
<xiangfu> 11 packets transmitted, 0 received, 100% packet loss, time 9999ms
<rejon> xiangfu might be our location
<roh> rejon: i can't reach it either. seems down
<xiangfu> rejon: I tried in qi-hardware.com. in Germany  :)
<rejon> i got sweet vpn running here now at mozilla china office
<xiangfu> ww.milkymist.org works fine now
<aw> i also can't reach taipei here 1 hour ago, but now it's ok.
<xiangfu> how can I copy file from milkymist one to PC?
<xiangfu> I try the tftp. it's always give me timeout.
<xiangfu> got it. it's ftp.
<xiangfu> my first 'fbgrab' in milkymist one : http://downloads.qi-hardware.com/people/xiangfu/tmp/mm1.c.png
<xiangfu> kristianpaul: wolfspraul. the 'fbgrab' is working :) http://downloads.qi-hardware.com/people/xiangfu/tmp/mm1.2.png
<kristianpaul> xiangfu: ohhh
<kristianpaul> xiangfu: cheers !
<xiangfu> kristianpaul: I shoudl connect the camera to which color of video in?
<Fallenou> well done xiangfu :) thanks !
<xiangfu> this may help find out the video issue.
<xiangfu> Fallenou: now. I try to send patch to lekernel :)
<kristianpaul> xiangfu: green i remenber
<kristianpaul> nice car ;)
<xiangfu> not in my yard. only in my camera :D
<lekernel_> xiangfu: nice shots
<lekernel_> i'll replace that on milkymist.org
<lekernel_> if you don't mind :)
<xiangfu> lekernel_: sure.
<xiangfu> I like this patch very much, thanks lekernel.   :)
<kristianpaul> what's the name of this one?
<kristianpaul> looks awesome indeed
<Fallenou> xiangfu: oh you have screenshot feature even in performance mode ?
<xiangfu> Fallenou: yes. when run 'fbgrab' the performance will stop.
<xiangfu> I guess it's cause real time os. right?
<Fallenou> how do I run it ? typing "fbgrab" in the rtems shell ?
<xiangfu> fbgrab file_name.png
<Fallenou> in the shell ?
<xiangfu> yes
<Fallenou> ok
<Fallenou> strange that it stops the performance
<xiangfu> oh. it's stop everything.
<xiangfu> for example. connect with telnet. ftp. and serial
<Fallenou> you mean it freezes the board ? :o
<Fallenou> and then after the screenshot, everything resumes ?
<xiangfu> when you do 'fbgrab' in serial. the 'telnet' and 'ftp' just stop. until 'fbgrab' finish.
<xiangfu> Fallenou: yes.
<Fallenou> oooh ok
<wolfspraul> xiangfu: wow nice - congrats!
<xiangfu> Fallenou: this is not normal?
<Fallenou> it should not
<xiangfu> oh.
<Fallenou> ftp and shell should run in separate threads
<wolfspraul> now we need to be able to do the fbgrab from a (usb) keypress
<xiangfu> the fbgrab need ~16 seconds.
<Fallenou> rtems runs several threads
<Fallenou> and do scheduling among them
<wolfspraul> and we need to publish flickernoise images that have this included (and get the patches accepted upstream by sebastien)
<wolfspraul> 16 seconds? :-)
<wolfspraul> that's the next thing to optimize :-)
<Fallenou> 16 seconds to read a 640x480 array ?
<wolfspraul> but one by one, it's great progress, very good!
<xiangfu> Fallenou: I using the 'time fbgrab a.png'
<xiangfu> Fallenou: let me run that again.
<Fallenou> never tested the time in rtems shell
<xiangfu> Fallenou: I think because write nor flash.
<xiangfu> I tried copy files from memory card to /dev/flash5. very very slow.
<xiangfu> 160KB
<Fallenou> oooh yes maybe
<Fallenou> try to write to the ramfs
<Fallenou> just to see the speedup you get
<Fallenou> it might give you the "incompressible" part of the time
<Fallenou> to show you what you can optimize and what you cannot
<Fallenou> (ramfs is mounted on /ramdisk )
<Fallenou> I don't know how much ram is mounted there, maybe some 4 kB
<xiangfu> [/flash] # time fbgrab 7.png
<xiangfu> 11: time fbgrab 7.png
<xiangfu> Converting image from 16
<xiangfu> Now writing PNG file...
<xiangfu> time: 0:02:28.670
<xiangfu> under flash. I start the performance, ftp, and telnet. some music played in line-in.
<Fallenou> try to write in /ramdisk (if there is enough space) or just try commenting out the part that actually write)
<xiangfu> the music not stop.
<xiangfu> Fallenou: ok.
<Fallenou> just to confirm the write is the big part
<Fallenou> which may be incompressible unfortunately :/
<lekernel_> xiangfu: seems you don't close /dev/fb in your fbgrab function
<lekernel_> and the fact that the software freezes while fbgrab is running is perfectly normal
<xiangfu> lekernel_: oh. yes.
<xiangfu> lekernel_: too bad. :(
<lekernel_> fbgrab is running with the shell task priority, which is the highest
<Fallenou> oh ok so it's a priority thing
<lekernel_> so RTEMS will not preempt it as long as it has something to do
<lekernel_> if you want to put it in the background, you could spawn a PNG compress/write sub-task
<lekernel_> with low priority
<lekernel_> also be careful if you read the framebuffer in this subtask
<lekernel_> because it can be modified by other tasks while you read it :)
<xiangfu> (subtask) don't know how to do that now. :( need look into document.
<xiangfu> wolfspraul: (keyboard shotcut) yes.
<lekernel_> so the dirty solution is to take a copy of the framebuffer in a high priority task and then process it in a low priority task
<xiangfu> kristianpaul: it's "Lekernel - Vibrant Plasma Streams.fnp"
<lekernel_> a clean solution can be copy-free (since the framebuffer is already mapped in memory and uses triple buffering) and you'd simply "lock" the current displayed framebuffer from the driver
<lekernel_> i.e. you add a 4th buffer
<lekernel_> in normal operation, that 4th buffer isn't used, it's the current triple buffering
<lekernel_> but when fbgrab requests a still framebuffer you return the currently displayed one and you don't touch it again until fbgrab is done with it
<lekernel_> but you can keep rendering using the other 3 remaining buffers
<lekernel_> it's a bit more complex to implement, but it would make fbgrab not interfere at all with the rendering
<lekernel_> also, keep in mind that the CPU is heavily used by the rendering already
<lekernel_> so if you use a background task, your PNG encoding can take forever
<lekernel_> about the ramdisk: you can write loads of stuff there, it's allocating on the ~100MB heap
<wolfspraul> xiangfu - my m1 still has flickernoise 0.1 - what is the easiest way to upgrade?
<xiangfu> lekernel_: thanks for the info.
<xiangfu> wolfspraul: urjtag. I think.
<wolfspraul> ok. need to disassemble my case first then...
<xiangfu> wolfspraul: or this one: http://lekernel.net/blog/?p=1339
<wolfspraul> and find one of those small allen keys for it, argh...
<xiangfu> but I never tried this method.
<wolfspraul> which one do you use?
<xiangfu> urjtag
<wolfspraul> ok
<xiangfu> back online in 1 hours.
<CIA-43> milkymist: Sebastien Bourdeauducq master * r99b1cfe / software/bios/Makefile : remove duplicate code in makefile (Xiangfu) - http://bit.ly/e5RwfR
<lekernel_> got 1024x768 ...with still some bugs though
<wolfspraul> hey my projector can only do 800x600
<wolfspraul> and I bought it because I thought it was 'future-proof' with m1. but you seem to be too fast!
<wolfspraul> my flickernoise 0.1 does not work with an Apple USB keyboad I have here
<lekernel_> is that a keyboard with integrated hub?
<wolfspraul> is that something that was improved in later flickernoises?
<wolfspraul> wait, checking...
<wolfspraul> yes, indeed
<wolfspraul> when I plug it into LInux, I get 2 new devices, hub and keyboard
<lekernel_> keyboards with integrated hubs are fucking extreme bloody pains in the ass that would make you hate USB forever should you even think about trying to develop support for them
<wolfspraul> good catch!
<wolfspraul> well, xiangfu can add it to his todo list :-)
<lekernel_> and they're not supported atm
<wolfspraul> (at the bottom though)
<lekernel_> well it won't be an easy task
<wolfspraul> no problem, I will find another keyboard
<wolfspraul> yes I can imagine
<wolfspraul> not the right priority now
<wolfspraul> I will find another keyboard
<wolfspraul> then I much rather have xiangfu implement usb keyboard support in the Ben NanoNote :-)
<wolfspraul> without a hub, of course
<wolfspraul> thanks that was an easy catch. I will find another keyboard.
<lekernel_> god, USB is so stupid... how could one even dream about making so complicated and messy the simple task of transmitting key presses and mouse moves down a bit of electric wire?
<lekernel_> I don't get it
<xiangfu> btw. I have a wireless mouse and keyboard.   using one usb receiver. the mouse works fine. keyboard not working
<lekernel_> xiangfu: also you're not freeing buf_p in fbgrab
<lekernel_> and zeroing it should be unnecessary
<lekernel_> you could also use an ioctl() interface that gives you the address of the framebuffer... and you wouldn't have to allocate memory anymore
<xiangfu> lekernel_: thanks.
<Fallenou> accessing the fb through the driver each time is an overhead
<Fallenou> accessing directly the memory array is faster
<xiangfu> is that ok, just read the framebuffer when mm1 do performance ?
<Fallenou> look at how it is done in fb.c
<Fallenou> (for the ioctl)
<lekernel_> wolfspraul: for the resolution, 800x600 will be supported as well. ideally, we could even detect the supported resolutions with DDC and pick the highest.
<lekernel_> and in fact it wouldn't make much difference with the rendering, only with the GUI
<lekernel_> I don't believe the current SoC architecture would be able to run the complete rendering system at high resolutions and high frame rate
<lekernel_> so the rendering would happen with a limited resolution internal framebuffer that is scaled up on the fly by the VGA controller
<xiangfu> lekernel_: I will send another patch with fixed 'free' and 'close', I will look into the ioctl, direct read framebuffer.
<lekernel_> ok
<xiangfu> lekernel_: I add the close(fd) to the end of main_fbgrab. the problem.
<xiangfu> everytime 'fbgrab a.png' finished the screen got no signal.
<lekernel_> ah :)
<lekernel_> uhm, yes
<xiangfu> just like the close(fd), close the vga output.
<lekernel_> actually the framebuffer driver isn't supposed to be acceded from two different tasks
<lekernel_> it enables video out at open() and disables it at close()
<lekernel_> you should be able to fix that by adding a reference counter to it
<xiangfu> yes. when I run the fbgrab again. video out work again. before fbgrab finished.
<lekernel_> do you see how?
<lekernel_> open: ref_counter++; if(ref_counter == 1) enable_video();
<lekernel_> close: ref_counter--; if(ref_counter == 0) disable_video();
<xiangfu> in c/src/lib/libbsp/lm32/shared/milkymist_framebuffer/framebuffer.c right?
<lekernel_> yes
<lekernel_> and with mutexes if you want something neat
<xiangfu> lekernel_: I will try to do that.
<xiangfu> counter first :)
<lekernel_> 1024x768 working bug free now :)
<xiangfu> great.
<xiangfu> so I can also get the resolution by using ioctl ?
<lekernel_> but it collapses when you start rendering
<lekernel_> the memory can't keep up
<lekernel_> we'll definitely need scaling
<lekernel_> hm, don't know. haven't looked at how to implement that in RTEMS yet
<lekernel_> but when it's done yes, it'll be with ioctl()
<xiangfu> (scaling) under verilog code right? (I try to understand more)
<lekernel_> yes, when rendering the FPGA will scale the low resolution framebuffer on the fly, at the same time as it generates the video signal
<lekernel_> this way the load on the memory system is only that of the low resolution framebuffer
<lekernel_> but when using the GUI, the needed memory bandwidth is much lower, and we can enjoy the full resolution
<lekernel_> he 14 fps @ 1024x768
<lekernel_> it's not that bad
<lekernel_> (i'm using the demo firmware now)
<xiangfu> lekernel_: http://pastebin.com/E1cVn3WW. is this ok?
<xiangfu> ref_counter ^
<lekernel_> yeah, looks good
<xiangfu> lekernel_: ok. I will send out the patch to mailing list.
<Fallenou> the resolution is held in a struct fb_var_screeninfo
<Fallenou> dunno if you can get it from ioctl
<Fallenou> i guess not :x
<Fallenou> xiangfu:  FBIOGET_VSCREENINFO
<Fallenou> this ioctl will give you the good struct :)
<Fallenou> to get the resolution
<xiangfu> Fallenou: ok. try to implement in next fbgrab. 1. direct read fb; 2. get more info by using ioctl
<xiangfu> Fallenou: thanks.
<lekernel_> ok, now the funny part: use partial reconfiguration to let the software change the pixel clock
<lekernel_> since it seems xilinx fucked up the normal way to reconfigure clock generators, I guess I'll have to spend the afternoon doing icky fpga hacking
<Fallenou> lekernel_: will the rtems framebuffer driver have to change its resolution?
<lekernel_> hmm... I guess I'll generate a differential bitstream with only the DCM configuration changed and then throw that into the ICAP to change the pixel clock
<Fallenou> I mean dinamically
<lekernel_> yes, sure. we want GUI menus to select the resolution, don't we?
<lekernel_> and before on the fly scaling works, we might even have to switch back to 640x480 during rendering
<Fallenou> ok so we need to implement the FBIOPUT_VSCREENINFO
<Fallenou> ioctl
<xiangfu> lekernel_: I have a very small patch to connect mm1 by serial console. but not sure if you would like put it in milkymist.git or flickernoise.git. blow is the small patch
<xiangfu> +connect: /dev/ttyUSB1
<xiangfu> +       stty -F $< raw 115200
<xiangfu> +       while : ; do cat $< ; done & cat > $<
<xiangfu> +
<xiangfu> i add it to "milkymist.git/boards/milkymist-one/flash/Makefile"
<xiangfu> lekernel_: http://pastebin.com/UTgAwWcG. this one is more clear
<lekernel_> why not use flterm?
<lekernel_> or gtkterm, or...? :)
<xiangfu> ah. I always using 'kermit' :).
<xiangfu> this one is just for ender using maybe.
<xiangfu> lekernel_: a better one. : http://pastebin.com/pgiznE7u
<xiangfu> I would like this small feature. since some one just bought on mm1. then he connect the usb cable. run 'make connect' he can got the boot log :)
<CIA-43> milkymist: Sebastien Bourdeauducq master * rdcef87c / boards/milkymist-one/flash/Makefile : flash: connect target to get boot log (Xiangfu) - http://bit.ly/geWVza
<xiangfu> lekernel_: thanks. :)
<xiangfu> lekernel_: sorry. the my terminal make the 'tab' as 'space'. :(
<lekernel_> and what's the problem?
<xiangfu> lekernel_: after you apply my patch from "http://pastebin.com/pgiznE7u" in makefile the front of 'stty ...' and 'while ..' is space not 'tab'
<lekernel_> argh
<lekernel_> ah, and it should be a phony target too
<CIA-43> milkymist: Sebastien Bourdeauducq master * recb9635 / boards/milkymist-one/flash/Makefile : fix connect target - http://bit.ly/g2iX5Z
<xiangfu> new patches send out. one for rtems-milkymist.git the fb ref counter. another is fbgrab fixed. free and close.
<lekernel_> I put your screenshots online: http://www.milkymist.org/flickernoise.html
<lekernel_> thanks for those!
<lekernel_> we should put some with the video input
<lekernel_> preferably with good looking dancers etc. :)
<kristianpaul> i can find good looking dancers next week at labsurlab ;-)
<xiangfu> after I update the rtems-milkymist.git. I got some error on network.
<xiangfu> "No rx buffers left in the pool! We are in big troubles!"
<xiangfu> ok. not always. after reboot. the ftp works fine again
<lekernel_> yeah, there are still several ethernet bugs
<CIA-43> rtems-milkymist: Sebastien Bourdeauducq master * r68f1136 / c/src/lib/libbsp/lm32/shared/milkymist_framebuffer/framebuffer.c : add open ref_counter to framebuffer driver (Xiangfu) - http://bit.ly/gAoF3v
<lekernel_> xiangfu: could you re-send your fbgrab patch with tabs for indentation?
<Fallenou> hum I've read somewhere that usually spaces are preferred
<Fallenou> because tabs can be interpreted by your editor
<xiangfu> lekernel: sended out. will more carefully next time.
<xiangfu> Fallenou: linux kernel style is using 'tab'
<Fallenou> tabs could show up as a different number of spaces depending on the editor
<Fallenou> whereas spaces are always the same
<Fallenou> xiangfu: so I guess it's the best :p
<xiangfu> lekernel: btw. I saw you always manually apply the patch. I always using save the file to .eml, the 'git am PATCH_EMAIL.eml', if the patch is as expect :)
<xiangfu> Fallenou: the only issue for me is the terminal always replace 'tab' with 'spaces'.
<CIA-43> flickernoise: Xiangfu Liu master * r64ea9ad / (src/main.c src/shellext.c src/shellext.h):
<CIA-43> flickernoise: add screenshot command fbgrab
<CIA-43> flickernoise:  add screenshot command fbgrab
<CIA-43> flickernoise:  add topic 'flickernoise'
<CIA-43> flickernoise: TODO:
<CIA-43> flickernoise:  * direct read fb memory
<CIA-43> flickernoise:  * get more info by using ioctl - http://bit.ly/i4YvHS
<lekernel> xiangfu: thanks
<lekernel> and tab width is 8
<lekernel> (to answer Fallenou's concern :p)
<Fallenou> well if you say you want real tabs
<Fallenou> there is no width :o
<Fallenou> the width is the way the editor displays it
<xiangfu> time for sleep. see you.
<Fallenou> gn8 !
<CIA-43> milkymist: Sebastien Bourdeauducq master * re758b81 / software/libhal/snd.c : demo: display WM9707 codec when found - http://bit.ly/hT1vau
<CIA-43> milkymist: Sebastien Bourdeauducq master * rba6271d / (8 files in 4 dirs): Support video mode switching - http://bit.ly/gzq2DZ
<lekernel> is using the flickernoise GUI in 1024x768 atm :)
<CIA-43> flickernoise: Sebastien Bourdeauducq master * re7498df / src/fb.c : Detect screen resolution at start up - http://bit.ly/gP3CgA
<CIA-43> mtk: Sebastien Bourdeauducq master * rf3ff0f5 / lib/scrdrv.c : Remove hardcoded resolution - http://bit.ly/hoX4hv
<CIA-43> rtems-milkymist: Sebastien Bourdeauducq master * r6ac350f / c/src/lib/libbsp/lm32/milkymist/include/system_conf.h : Add all definitions for VGA registers - http://bit.ly/eQbLaJ
<CIA-43> flickernoise: Sebastien Bourdeauducq master * r81bdecd / src/shellext.c : fbgrab: detect screen resolution - http://bit.ly/dSQUzg
<mwalle> lekernel: btw we wont have to modify the bios serial upload protocol
<mwalle> im using a BREAK character
<mwalle> thus i've only needed to add support for that in the uart transceiver
<lekernel> hm, what's that? keeping the line at 0 for more than one byte and no stop bit?
<lekernel> can it be done with common serial port hardware and drivers at the other (PC) end?
<mwalle> lekernel: yeah violating the stop bit
<mwalle> there is a short break (length between one and two frames) and a long break character (longer thatn two frames)
<mwalle> all modern serial transceivers should be able to generate one :)
<lekernel> worst case I guess we can 'emulate' it on the PC side by setting a baudrate too low and transmitting a zero character
<mwalle> yeah, lol :)
<lekernel> I found that crap when looking for info about how to send rs232 breaks
<lekernel> ELM electronics has a "break detector" circuit
<lekernel> I guess they're programmed attinys/pic or something like that
<mwalle> lekernel: lol
<mwalle> lekernel: the gdb stub will need 6kb/2kb rom/ram
<lekernel> 8kb in total?
<mwalle> yes
<lekernel> bytes?
<mwalle> bytes
<lekernel> should be ok i think...
<lekernel> we have that much spare BRAM afaik
<mwalle> unfortunately it is hard to mux gdb packets and console.. atm i did a tx redirection with the help of the uart core
<mwalle> there are some scripts that intercepts the serial port traffic and looking for gdb packets and split them from normal data, but that wont work out of the box
<mwalle> gdb supports 'systemcalls' eg read and write to stdin/stdout/stderr, but that requires an application that is 'gdb aware'
<mwalle> gn8 :)
<mwalle> 12.142ns sys_clk period with one breakpoint
<mwalle> the new ise seems to be a lot better :)=
<CIA-43> mtk: Sebastien Bourdeauducq master * r0789f9d / lib/gfx_functions.h : Fixed text antialiasing - http://bit.ly/hBuztv
<CIA-43> mtk: Sebastien Bourdeauducq master * r7a7bc76 / (7 files): Dark blue color theme - http://bit.ly/ijYerq