<rjeffries> wpwrak what are specs for ribon cable that will work wrll with UBB? Part number, source? if I recall correctly the bets option is a cable with 10 wires
<rjeffries> then one slits it to the correct width and number of wires
<steve|m> wolfspraul: you may like this: http://blog.akkit.org/2010/05/30/project-chip-decapping/ ;)
<wolfspraul> hmm, nice blog.
<wolfspraul> I'm wondering whether to include it in the planet.
<kyak> larsc: if i want to play with 2.6.37, should i build it from openwrt-trunk or from qi-kernel?
<tuxbrain_away> I totally fail crosscompiling :( binaries doesn't run on NN
<tuxbrain_away> this is totally strange
<tuxbrain_away> root@BenNanoNote:/usr/bin# ls avrdude
<tuxbrain_away> avrdude
<tuxbrain_away> root@BenNanoNote:/usr/bin# avrdude
<tuxbrain_away> -ash: avrdude: not found
<tuxbrain_away> root@BenNanoNote:/usr/bin#
<tuxbrain_away> ok at least bash found it but can't execute it... so just another failed build from my part :(
<Jay7> morning
<tuxbrain_away> morning Jay7
<Jay7> tuxbrain_away: file avrdude
<xiangfu> tuxbrain_away: is the 'avrdude' execute-able?  chmod +x avrdude
<kyak> tuxbrain_away: file /usr/bin/avrdude and ldd /usr/bin/avrdude
<kyak> :)
<kyak> fighting to boot into 2.6.37.1 from openwrt-trunk
<tuxbrain_away> -rwxr-xr-x    1 0        0          865082 Jan  4 20:05 avrdude
<tuxbrain_away> avrdude: ELF 32-bit LSB executable, MIPS, MIPS32 version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.4.0, with unknown capability 0xf41 = 0x756e6700, not stripped
<tuxbrain_away> ldd: can't open cache '/etc/ld.so.cache'
<tuxbrain_away> checking sub-depends for 'not found'
<tuxbrain_away> checking sub-depends for '/usr/lib/libreadline.so.5'
<tuxbrain_away> checking sub-depends for '/usr/lib/libncurses.so.5'
<tuxbrain_away> checking sub-depends for 'not found'
<tuxbrain_away> checking sub-depends for '/lib/libgcc_s.so.1'
<tuxbrain_away> checking sub-depends for '/lib/libc.so.0'
<tuxbrain_away> libusb-0.1.so.4 => not found (0x00000000)
<tuxbrain_away> libm.so.6 => not found (0x00000000)
<tuxbrain_away> libreadline.so.5 => /usr/lib/libreadline.so.5 (0x00000000)
<tuxbrain_away> libncurses.so.5 => /usr/lib/libncurses.so.5 (0x00000000)
<tuxbrain_away> libc.so.6 => not found (0x00000000)
<tuxbrain_away> libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00000000)
<tuxbrain_away> libc.so.0 => /lib/libc.so.0 (0x00000000)
<tuxbrain_away> /lib/ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0x00000000)
<kyak> seems that it is linked against some libs that are absent from your system
<tuxbrain_away> I guess those marked as not found? isn't it?
<kyak> yes, and the addess seems kind of strange
<kyak> 0x00000000
<tuxbrain_away> well then maybe use the OE toolchain to build has not been such good idea :(
<kyak> you should build statically if you use non-compatible toolchain, but then this is a bad idea anyway
<Jay7> kyak: I'll try to build .37 today with OE
<wpwrak> tuxbrain_away: seems that you mixed up the toolchains from openwrt and jlime. or maybe even the binaries (trying to run jlime build on openwrt or vice versa)
<wpwrak> tuxbrain_away: if building for openwrt, make sure you didn't run jlime's environment-setup
<wpwrak> tuxbrain_away: also, if you haven't done so, rm -rf the avrdude tree first
<xiangfu> tuxbrain_away: make IGNORE_ERRORS=m
<tuxbrain_away> thanks :)
<tuxbrain_away> wpwrak: no I don't run
<tuxbrain_away> jlime's environment-setup but using the OE toolchain but whatever is a bad idea
<tuxbrain_away> xianfu: then this must be added in the build image wiki page isn't it? if you are ok with this I will add
<kyak> Jay7: ok
<kyak> xiangfu: do we need to do something special to run the kernel from openwrt-trunk?
<roh> imagine this for 'testing'
<xiangfu> tuxbrain_away: just got it compiled. uploading...
<kyak> xiangfu: it builds fine, but i have to add some missing options to config-2.6.37 from config-2.6.32
<xiangfu> kyak: in fact, never tried the new kernel. sorry.
<tuxbrain_away> xiangfu: it was not so hard then :P
<kyak> xiangfu: hmm, ok :)
<kyak> i guess i'll go with qi-kernel. I had luck there some time ago
<tuxbrain_away> that compiles ok so I have it locally :)
<tuxbrain_away> xiangfu: will you update the Makefile in repo?
<xiangfu> tuxbrain_away: sure.
<xiangfu> tuxbrain_away: the gpsd is in upstream. not openwrt-package.git. I will send patch to upstream mailing list.
<xiangfu> tuxbrain_away: here is the patch: http://pastebin.com/dbh0MfGD
<xiangfu> tuxbrain_away: patch send out.
<xiangfu> tuxbrain_away: when I start 'tangogps' it give me:
<xiangfu> connection to gpsd FAILED
<xiangfu> NOGPSno gpsdata for timer
<xiangfu> don't know how to make 'gpsd' and 'tangogps' works :(
<kristianpaul> xiangfu: hi
<kristianpaul> xiangfu: you have the gps-receivre already connected to the serial port?
<kristianpaul> Btw gpsd could die just because cant acess the right port (/dev/ttyS0)
<kristianpaul> You also may like to edit /etc/inittab and comment lines that have "/dev/ttyS0" on it
<kristianpaul> If you gps receiver is using SiRF, i recomend recompile gpsd to just support that..
<Jay7> larsc: ping
<Jay7> is jz4740-udc.patch still needed for .37 kernel?
<larsc> yes
<Jay7> it's about USB_GADGET_JZ4740 and USB_JZ4740 config options
<larsc> if you want usb gadget support that is ;)
<Jay7> have you recent version against .37?
<Jay7> .36 one fails to compile
<Jay7> second question is modifier-keys.patch
<Jay7> is it still needed as well?
<larsc> you can and probably should load the keymap from userspace
<xiangfu> kristianpaul: oh. thanks for the info. no gps-receiver in serial port.
<larsc> but if you don't, you'll need the patch
<Jay7> well.. we (kexecboot) are initramfs mostly :)
<Jay7> ok
<larsc> the modifier-keys.patch will always be needed if you don't load the keymap from userspace
<Jay7> larsc: ok, then we will use it
<tuxbrain_away> pango fails to build http://pastebin.com/HNrf2XDX
<larsc> is there a copy of the pango package somewhere in qi package feed?
<kyak> no, there is no.. but pango should be fixed  after we catch up with the latest backfire
<kyak> jow fixed the autoreconf
<kyak> larsc: would you suggest building kernel from openwrt-trunk or qi-kernel, if i want to play with 2.6.37?
<tuxbrain_away> kyak I'm following the instructions from http://en.qi-hardware.com/wiki/Building_Software_Image#Building_OpenWrt_images_from_source , so maybe is fixed but not uploaded to the right place?
<kyak> tuxbrain_away: as a temporary measure, maybe this would help you: https://dev.openwrt.org/ticket/8813. You have to adapt the patch for yourself
<kyak> tuxbrain_away: xiangfu was going to merge the latest backfire into our branch soon, so you might as well wait for that
<tuxbrain_away> I prefer wait, I have broken too much building systems those days
<larsc> kyak: shouldn't matter which one you use
<larsc> kyak: the one from the qi-tree doesn't have the openwrt logo
<larsc> but that should be all of the differences
<kyak> larsc: ok then. i tried both, seems there is 2.6.37.1 in openwrt-trunk and 2.6.37 in qi-kernel. But, unfortunately, i have problems booting both -\
<kyak> by adjusting CONFIG_CMDLINE, i can make it boot to "Starting kernel..."
<kyak> btw, there is no CONFIG_CMDLINE is config-2.6.37 in openwrt-trunk...
<kyak> is/in
<kyak> another thing i noticed is that there is CONFIG_CMDLINE_BOOL now in 2.6.37
<larsc> hm, that seems rather strange
<kyak> without it, CONFIG_CMDLINE won't work
<larsc> i build one from openwrt-trunk when i did the ubi speed-up patches and it worked fine
<kyak> i put the one from openwrt-trunk in /boot/uImage (rootfs) and boot by pressing the F4
<kyak> maybe it would work different if i flash it in kernel partition
<kyak> the uImage from 2.6.32.27 boots well from /boot/uImage without any adjustments
<kyak> so i was hoping that 2.6.37 will, too
<kyak> i trying to diff the .config's from 2.6.32.27 and 2.6.37, but it seems futile
<zrafa> tuxbrain_away: you got that with jlime?
<zrafa> tuxbrain_away: I mean..the problem .. you can not run it with jlime?
<zrafa> tuxbrain_away: the problem seems classic :)
<zrafa> between systems and differents libraries
<zrafa> tuxbrain_away: so you should get the same if you build with any building system and you try to run the binary on systems with the same arch but different OS
<zrafa> tuxbrain_away: ah.. wpwrak already said you :)
<kyak> larsc: i don't understand how you managed to boot the kernel from openwrt-trunk. It fails to find the root without CMDLINE
<kyak> larsc: hmmmm.. however, the same uImage boot fine from SD card!
<kyak> i guess it could also work from the kernel partition..
<larsc> kyak: uboot passes the correct cmdline
<kyak> larsc: xiangfu: then i'm confused. Two questions: why do we need cmdline in 2.6.32, if it is handled by uboot? And why does uboot work correctly for 2.6.32 (when pressing F4) and doesn't work for 2.6.37 (when pressing F4)?
<xiangfu> kyak: command can configure kernel mem, console, where is the rootfs. also like g_ether.host ...
<xiangfu> s/command/cmdline
<wpwrak> kyak: you know   cat /proc/cmdline   ?
<wpwrak> kyak: for kexec, you basically have to make sure you're passing the same information
<kyak> i'm not even talking about kexec now
<xiangfu> kyak: have you change the nand partition configure in 2.6.37?
<xiangfu> kyak: by default it's 256M
<kyak> i'm saying that the 2.6.37 built by default from openwrt-trunk won't bott from /boot/uImage
<xiangfu> kyak: the nand partition is hard code inside kernel.
<kyak> it would boot from SD
<wpwrak> (funny that we need mem=32M. we should auto-detect this. reminds me of the psion s5 where the memory was even scattered in non-contiguous blocks of I think 0.5 MB ;-)
<kyak> xiangfu: i haven't changed anything
<xiangfu> kyak: then the nand partition is not correct.
<xiangfu> kyak: kernel will got error when try to mount nand rootfs partition
<kyak> hm.
<kyak> fw_setenv bootargsf4 mem=32M console=tty0 console=ttyS0,57600n8 ubi.mtd=2 rootfstype=ubifs root=ubi0:rootfs rw rootwait
<kyak> xiangfu: these are arguments when pressing F4
<kyak> where is the rootfs size?
<xiangfu> kyak:the nand partition size is hardcode inside kernel.
<kyak> xiangfu: oh, ok
<xiangfu> kyak: let me check the nand partition. I just check is 'master' branch. not 2.6.37
<kyak> so it's still 256 M in operwrt-trunk?
<xiangfu> kyak: checking now
<kyak> xiangfu: then it explains my troubles
<kyak> all right!@
<xiangfu> kyak: in qi-kernel. by default rootfs is   .size = (504 + 512 + 1024) * 0x100000,
<xiangfu> kyak: checking openwrt-trunk now
<kyak> almost sure it's the same as qi-kernel
<kyak> xiangfu: btw. Some our patches for 2.6.32 haven't got into 2.6.37. Is it ok?
<kyak> i'm talking about the red arrow + backspace as delete
<kyak> it works in 2.6.32 and doesn't work in 2.6.37
<kyak> cause the key map is not correct
<xiangfu> we should try to send those patch to upstream again :)
<kyak> upstream - larsc :)
<xiangfu> I am the openwrt-truck.
<xiangfu> I mean the openwrt-trunk
<kyak> hm.. trying to find it in git log
<xiangfu> those patch will never goto upstream. because that patch change all base keyboard.
<kyak> xiangfu: thanks for this really helpful hint about nand size.. im'm sure it will work now, and now i'm able to test kexec on the latest kernel
<kyak> no
<kyak> it was very specific
<kyak> this is the patch
<kyak> in fact, it copies the defkeymap.c_shipped to defkeymap.c anyway. So modifiying 500-modifier-keys.patch is just for correspondence
<larsc> wpwrak: autodetection is for systems where you don't know the config
<xiangfu> larsc: did the ubi faster patch goto openwrt trunk? or just committed in openwrt-xburst.git ?
<larsc> just openwrt-xburst for now
<wpwrak> larsc: would also be useful if there's a future device with more memory. autodetection just removes one item from the list of worries :)
<xiangfu> kyak: hmm.. I remember it's need manually create defkeymap.c
<larsc> wpwrak: and adds a second to the boottime ;)
<xiangfu> kyak: so, after modify those keys. need run a command to create the defkeymap.c
<xiangfu> kyak: why we patch those two file is. 1. defkeymap.map is for clear   2. defkeymap.c_shipped: no needs for re-generate the defkeyamp.c
<wpwrak> larsc: naw, a few milliseconds at most. you don't have to *test* the memory ;-)
<jow_laptop> stupid question, anybody tried reflashing the ben from OS X yet?
<kyak> xiangfu: it's ok, i just want to have it in 2.6.37, too :) i'm afraid we can loose something when migrating to 2.6.37
<xiangfu> jow_laptop: there is a wiki page about how to compile xburt-tools in MAC os
<xiangfu> jow_laptop: let me try to find out that.
<xiangfu> kyak: very thanks for 2.6.37 testing.
<xiangfu> jow_laptop: sorry, can not find that page. but I am sure someone have tried that.
<jow_laptop> :)
<jow_laptop> I'll just wait until I'm home
<xiangfu> jow_laptop: I will let you know when I found it :). time to sleep.
<mth> jow_laptop: I did build usbtool for OS X, see: http://www.treewalker.org/dingux/
<mth> this does not allow flashing though, I think
<mth> in Dingux, flashing is done by uploading a kernel which has a flasher and the boot loader to flash in its initrd
<mth> but the Makefile might be useful to compile libusb
<jow_laptop> don't worry, I borrowed a linux laptop :)
<jow_laptop> just wanted to try the most recent image
<jow_laptop> how does one quit the gmenu2x settings screen?
<jow_laptop> and how gmu?
<kyak> jow_laptop: gmenu2x settings - "s" (http://en.qi-hardware.com/wiki/Applications#settings)
<kyak> gmu: alt+q (this can be read from F1 help)
<xMff> thanks...
<kyak> xMff: btw, kexec is not working in 2.6.37.1 :)
<kyak> just checked it
<Jay7> kyak: :(
<kyak> Jay7: yep, not very nice.. hope you will have more luck
<wpwrak> curses DRI
<Jay7> kyak: not sure..
<Jay7> larsc: may be you will try to play with kexec? ;)
<kyak> Jay7: were you able to try kexec with 2.6.37?
<Jay7> I need to build some image to try
<Jay7> jlime is unbuildable at this moment
<Jay7> may be I'll reuse linux-kexecboot kernel to build some other distro (e.g. minimal)
<kyak> you could also try with openwrt
<Jay7> I have not touched it before :)
<kyak> everyone has his first time :)
<Jay7> yeah :)
<Jay7> good point to place into CV anyway :)
<Jay7> but I'm a bit tired after that kexecboot features implementation race :)
<kyak> kexecboot is a nice piece of software. But it's useless without kexec -\
<Jay7> sure :(
<kyak> working kexec
<Jay7> I have no enough skills to debug/fix it
<Jay7> this is task for kernel and kexec-tools guys
<Jay7> btw, wrt compressed uImage
<kyak> and for those knowing mips well. I asumen it is very architecture-specific
<Jay7> iirc, someone was tested uncompressed kernel + compressed uImage vs compressed kernel + uncompressed uImage
<Jay7> and second win
<Jay7> but that was on Zauruses iirc
<kyak> kexec-tools on mips specifically list only "elf-mips" as supported images
<Jay7> well.. that may be not a problem because kernel is laying on FS
<kyak> i found that both vmlinux and vmlinux.elf can be loaded successfully (but not ecexuted)
<Jay7> about execution
<kyak> uImage can't be loaded -\
<Jay7> your idea about wrong entry point may be rigth
<Jay7> but anyway we need some guru :)
<kyak> yeah
<kyak> we could also moan in kexec-tools and kernel mailings lists :)
<kyak> but it's enough of this in google...
<kyak> without apparant results
<kyak> off
<tuxbrain> I think something is wrong on hardware of my NN, doesn't charge the battery (nor on or off) and it can't boot when usb is plugged , it gets stuck on kernel message of g_ether.
<tuxbrain> I have tried with various batts (even OM ones) to discard is matter of old battery. Any one has experience same problem?
<tuxbrain> In my case is a minor issue due I'm plenty of replacements here , but I would like to know if is the first case on that .
<Jay7> tuxbrain: did you tried with other kernel? :)
<Jay7> some Zaurus models can't bood current kernel with power plugged in
<Jay7> something is wrong around his power management
<tuxbrain> Jay7: I have test on jlime kernel and lastest release kernel
<tuxbrain> same behabiour
<tuxbrain> jlime beta4 and Blizzar lastest build
<Jay7> seems HW then :(
<tuxbrain> the lack of charge even off also points to that.
<wpwrak> tuxbrain: i may have some problems with charging, too, but haven't examined that in detail. no hangs at g_ether, though
<tuxbrain> avrdude working on openwrt machine  (at least it trows the help message )
<dvdk> tuxbrain: saw your video programming an arduino via the Nanonote.
<dvdk> tuxbrain: you programmed via UBB?  Or some more special adaptor board?
<wpwrak> tuxbrain: congratulations ! now, you just have to sleep two more nights before you can actually try it :)
<dvdk> just wondering, since I thought arduine were serial (as in uart) boot loader only.
<tuxbrain> (re)finishing building avr toolchain binutils and gcc finished but avr-libc , needs x86-avr cross toolchain due oviously can execute mips-avr one
<tuxbrain> dvdk using NN serial port
<dvdk> ah, ok that explains it.  what a pitty, then I can't even use the UBBs for that trick :)
<tuxbrain> dvdk but you can program and comunicate with SPI also directly on chip
<tuxbrain> yes we will!
<dvdk> ok, the spi option didn't show up last time i googled and looked for datasheets.  guess that would be the way to go.
<dvdk> does arduine have the pins (and bootloader) for that?  or are we talking about 'naked' avr chips?
<dvdk> s/arduine/arduino
<dvdk> tuxbrain: how long until UBBs are shipping?  still time to add an arduino to the package? :)
<dvdk> just looking at your link: but no in-chip-programming via Spi?  i.e. using only an UBB no other cables and programmer?
<tuxbrain> you can also acces them as  "nude" pins to program the chip is reset is on
<tuxbrain> is-> if
<tuxbrain> or you can also use the ICSP connector (same pins to the chip)
<dvdk> so having NN+UBB+Arduino would suffice to do programming?  don't own any other special cables.
<dvdk> no problem if i have to do some bit-banging programming on NN.
<tuxbrain> yes
<dvdk> cool.
<tuxbrain> I know :)
<tuxbrain> that's why I spend so many time porting the avr toolchain :)
<wpwrak> dvdk: (bit-banging) with avrdude, you'll may need a definition for the pin assignment of your programming adapter in avrdude.conf
<wpwrak> dvdk: that is, unless yours happens to end up with the same assignment as any of my adapters (two so far)
<dvdk> wpwrak: i'd need some code for the Jz47xx I guess?  or does it know how to do I/O already?
<wpwrak> dvdk: i have patches for avrdude that do the bitbanging
<dvdk> ok: already on its way into NN's openwrt i guess?
<wpwrak> dunno. it's simple enough to compile it on your own
<dvdk> hmm, no package?  should also document your UBB pinout, as kind of 'standard' to beware others of pinout headaches.
<dvdk> might be nice to have it included in NN out-of-the-box.  always trying to reduce the amount of work my brain has to do.
<wpwrak> dvdk: you just need to define the mapping from UBB to whatever you have
<wpwrak> (out of the box) i'm sure this will be taken care of before too long ;-)
<dvdk> wpwrak: is that a uart-chip hooked to the 8:10 port, or just a UBB?
<dvdk> desc="NanoNote UART 8:10 card"
<tuxbrain> dvdk wpwrak build finished :)
<wpwrak> dvdk: that one is ATmega48 playing uart, yes. for an example of ubb+cable, see http://projects.qi-hardware.com/index.php/p/ben-blinkenlights/source/tree/master/uart/avrdude/patches/nanonote-atusb.patch
<tuxbrain> dvdk btw I think to create an ardunote project triying to simplify at maximum Arduino Nanonote relations
<dvdk> ok, wpwrak, that's neat.
<wpwrak> dvdk: ubb just gives you access to the pins but doesn't "do" anything. so the two are structurally equivalent. only difference is that one has a led and that i've reshuffled the pins a little
<dvdk> wpwrak: know that.  just 6 gpios.
<dvdk> the difference is: I'll have a UBB, but I won't have an 8:10 UART :)
<dvdk> yeah, i'll put avrdude packaging on my todo list.  it will be nice to show people that Arduino hacking works out-of-the-box.
<wpwrak> dvdk: you'll probably end up with yet another pin mapping. i don't know what the arduino's connectors look like and what will be a convenient assignment. but all you need is one of those mappings, and avrdude will talk - via the common nanonote driver - to your device
<dvdk> wpwrak: ok.
<dvdk> is looking at the bit-banging code
<wpwrak> dvdk: there are lots of such assignments in avrdude.conf. it works the same for (pc) serial port and parallel port adapters. and there's a gazillion of these ;-)
<dvdk> yeah, figured that.
<dvdk> i really think we should get that stuff into the NN firmware image.
<dvdk> nobody likes to (cross-)compile for nanonote.
<dvdk> me neither :)
<wpwrak> (avrdude packaging) great, thanks ! there's still some work i need to do on the avrdude side for devices that need an external clock (the uart will become one of these), but it's already usable for the more common devices that don't need such a thing
<wpwrak> oh, i like cross-compiling very much ;-)
<wpwrak> that is, while it works, which is does quite well so far :)
<dvdk> going to reference git from the openwrt package, so it'll just be one line to change if you update.
<wpwrak> s/is/it/
<dvdk> yeah, the most important stuff is the Jz47xx GPIO support from userspace and that's already there.  nice.
<dvdk> ok, need to sleep.
<dvdk> good night.
<wpwrak> when the distributions upgrade to the .36 kernel, then i can also resume work on libbb, which would provide an abstraction layer that could also be used in avrdude
<wpwrak> (.36 or later)
<dvdk> wpwrak: even cooler.  kernel driver?
<wpwrak> for now just user space. but one that takes care of moving the mmc driver out of the way.
<dvdk> but really need to sleep now
<wpwrak> kernel is ffs ;-)
<dvdk> nice.  thought about using UIO?
<wpwrak> (we'll need the kernel for interrupts)
<dvdk> -> uio?
<dvdk> can do irq
<dvdk> lets continue tomorrow
<dvdk> cheers
<wpwrak> is uio something that's in mainline ?
<wpwrak> oh, it is. nice :)
<wpwrak> i thought these things would get shut down for political reasons forever ;-)
<qi-bot> [commit] David Kühling: plplot: minor cleanup (suggestions from kyak) http://qi-hw.com/p/openwrt-packages/29868ea
<wpwrak> "sleep" = "commit". intersting :)
<lekernel> first comment on UIO: "People in the embedded space don't do prototypes. They hack something until it works, then it's done."
<lekernel> hahaha
<wpwrak> ;-))
<lekernel> followed by that GPL debate... but the linux kernel management seems surprisingly free of such trolls
<wpwrak> well, the whole concept of user space i/o has only been on hold for something like a 1.5 decades due to gpl circumvention concerns ;-)
<wpwrak> that's why i was a bit surprised that it had finally made it :)
<wpwrak> lekernel: ... and with UIO_SERCOS3 and UIO_NETX we already seem to have two fine examples of closed source user spaces
<lekernel> NVidia already makes proprietary Linux drivers (let alone the proprietary algorithms in the chips), and it doesn't make such a fuss
<Fusin> wb /me ;)
<wpwrak> lekernel: well, everbody hates nvidia and would hate to see more of this even more
<lekernel> there's this funny "nouveau" project spending years on scratching the surface, but that's it
<wpwrak> lekernel: nouveau is my saviour. they provide exactly what i need.
<lekernel> and opengraphics which is a massive technical failure
<lekernel> last time I tried it (it's only one or two months ago), nouveau was very slow and did not support 3D
<wpwrak> lekernel: yeah, opengraphics is a disaster
<wpwrak> lekernel: i don't care much about 3d. i want screen real estate. and i figure it's more likely to work if i have two different cards in my pc than two with the same driver. thus i have one nvidia and one ati.
<wpwrak> lekernel: alas, no intel on-board video in that generation of pc. maybe in the next ...
<lekernel> so, I'm using the proprietary driver which works just fine, especially that, contrary to Debian, Fedora packages it, which does not waste my time with stupid system administration and kernel header mismatches problems
<Jay7> VIA/S3 ;)
<Jay7> but it is hard to get
<wpwrak> lekernel: well, despite your nick, you're not doing kernel development on your workstation :)
<wpwrak> Jay7: phew. yeah, that would be another challenge. i heard that there are also some nice multiheads from matrox. but i'd rather limit the complexity of my sourcing ...
<lekernel> btw, for your 2D use, it wouldn't be too hard to pull off a free GPU
<lekernel> but I'm not sure if it would make sense economically to do so
<lekernel> wouldn't be too hard, I mean hardware-wise. getting the X dinosaur to dance is something else.
<wpwrak> lekernel: yeah, and some niche design would be even more expensive to get in argentina. so i'd have to stock spares and such.
<wpwrak> (x dinosaur) kdrive ;-)
<lekernel> btw, how usable is kdrive?
<lekernel> can it work with the proprietary nvidia driver including 3D?
<lekernel> or maybe at least decent 2D acceleration
<lekernel> I don't need 3D so often
<wpwrak> i think it's strictly 2D. no idea how it relates to nvidia. i know it as a server for embedded systems with some very basic 2D acceleration, e.g., openmoko's freerunner
<Fusin> wpwrak: talking about freerunner. is there a channel which deals with freerunner here?
<Fusin> ok, found ;)
<wpwrak> ;-))
<Fusin> is called #openmoko :D
<Fusin> still needs to update his fr
<Jay7> kdrive is dead
<Jay7> afaik
<wpwrak> Jay7: dunno. i vaguely remember that it has been merged into x.org, but i'm not sure what specifically this means
<Jay7> we have used it on Zauruses
<Jay7> but it is hard to use now..
<Jay7> so we will switch to xorg-server soon
<Jay7> iirc, kdrive is unmaintained some years
<lekernel> yay! more bloat!
<lekernel> when will X die at last...
<lekernel> ;-)
<Jay7> wayland is proposed as replacement
<Jay7> not sure about embedded
<Jay7> iirc, wayland is using opengl actively