| 00:36.53 | *** join/#qi-hardware cladamw (~Adam@host-222.80-43-115.dynamic.totalbb.net.tw) |
| 00:50.13 | *** join/#qi-hardware rejon (~rejon@jp.fabricatorz.com) |
| 01:19.09 | *** join/#qi-hardware xiangfu (~xiangfu@fidelio.qi-hardware.com) |
| 01:38.31 | *** join/#qi-hardware antgreen (~user@CPE0021910f07ac-CM0019477f82fc.cpe.net.cable.rogers.com) |
| 01:47.33 | pabs3 | more open hardware folks: https://lwn.net/Articles/491515/ |
| 01:51.47 | *** join/#qi-hardware crosswalk (~crosswalk@d47-69-35-236.try.wideopenwest.com) |
| 01:52.24 | *** join/#qi-hardware xwalk (~crosswalk@d47-69-35-236.try.wideopenwest.com) |
| 01:53.16 | *** join/#qi-hardware wej (~j@95.211.92.234) |
| 02:14.03 | *** join/#qi-hardware xiangfu (~xiangfu@fidelio.qi-hardware.com) |
| 03:34.17 | *** join/#qi-hardware frankblues (~alex@c-67-182-230-190.hsd1.ut.comcast.net) |
| 04:42.45 | qi-bot | The build was successful: http://fidelio.qi-hardware.com/~xiangfu/build-nanonote/openwrt-xburst.full_system-20120409-2355 |
| 05:09.04 | kyak | yeah! |
| 05:11.47 | kyak | mth: thanks, i'll try the fix |
| 05:17.25 | kyak | jow_laptop: i agree with what you said about the toolchain name.. i added your comment to https://dev.openwrt.org/ticket/11264 |
| 05:28.16 | wolfspraul | I regret a little that we stopped working on the atben/atusb casing |
| 05:28.25 | wolfspraul | that asks for resurrection :-) |
| 05:29.07 | wolfspraul | I just want to embed the whole thing in a blob of epoxy or so. or a transparent plastic/glue, then you can still see the innards. it should not deteriorate the rf performance though. |
| 05:30.03 | xiangfu | kyak, this build is for release |
| 05:30.37 | kyak | wolfspraul: having atusb upstream would be so much nicer than a casing! |
| 05:30.58 | xiangfu | downloading... |
| 05:31.16 | kyak | xiangfu: yea, this looks good for release.. most fallouts have been fixed |
| 05:32.17 | xiangfu | kyak, Hi. since you have the directvnc. do you have the Makefile already? I would like try directvnc here. |
| 05:32.32 | kyak | yes, i got the Makefile |
| 05:32.55 | kyak | should i commit or rather upload it somewhere? it builds and runs, but the screen is mangled |
| 05:33.01 | xiangfu | kyak, do you think if a normal openwrt router can running a vnc server? |
| 05:33.17 | xiangfu | kyak, commit is better. |
| 05:33.51 | xiangfu | kyak, it builds and runs. better then those @BROKEN packages. :-) |
| 05:33.52 | *** join/#qi-hardware xwalk (~crosswalk@rrcs-98-102-156-195.central.biz.rr.com) |
| 05:34.11 | kyak | xiangfu: i didn't see any vnc servers ported to openwrt so far.. i also think that X11 is a requirement |
| 05:34.19 | kyak | which may be problematic for routers |
| 05:35.09 | xiangfu | ok. |
| 05:35.25 | xiangfu | just asking. |
| 05:35.44 | xiangfu | if there is vnc server running on openwrt router. then Ben Nanonote can be used as 'Monitor' :-) |
| 05:35.53 | xiangfu | be back later. |
| 05:36.02 | qi-bot | [commit] kyak: directvnc: initial port (master) http://qi-hw.com/p/openwrt-packages/96cd146 |
| 05:36.22 | wolfspraul | kyak: what can we do? [atusb upstream] |
| 05:36.28 | wolfspraul | let's break it down into smaller tasks |
| 05:36.55 | wolfspraul | don't underestimate the casing though, I think the current bare-pcb makes the boards essentially unusable, confining them to a lab-only developer desk |
| 05:37.09 | wolfspraul | every time I even carry them around I have to take special precautions |
| 05:37.54 | *** join/#qi-hardware jekhor (~jek@leased-line-46-53-195-5.telecom.by) |
| 05:38.18 | kyak | wolfspraul: ressurect the atusb software development :) i might be mistaken, but i think it is currently in a half-tested stage, and not able to compile as kernel module (only monolitically).. when it's nice and clean and working and tested, then it perhaps can be accepted by upstream |
| 05:39.32 | kyak | and helping with atusb driver development is beyond my limits/knowledge.. so i could only help by testing |
| 05:40.35 | wolfspraul | yes, ok. let's see. |
| 05:40.53 | wolfspraul | my use case here would probably be that I have an atusb in an openwrt-based router, and atben in the Ben |
| 05:40.57 | wolfspraul | (for networking) |
| 05:41.24 | wolfspraul | that should be super easy to setup and get to work |
| 05:41.28 | wolfspraul | *should* :-) |
| 05:41.35 | wolfspraul | agreed? is that the use case we are targeting? |
| 05:43.37 | kyak | yeah, putting atusb in openwrt router is the use case.. putting atusb in a laptop from time to time is also a use case |
| 05:44.14 | kyak | the latest commit in ben-wpan-stefan is from 25 Sep 2011. .this is the problem |
| 05:44.18 | wolfspraul | that's probably a little harder to achieve initially, so I'd rather target openwrt on the other side first |
| 05:44.43 | wolfspraul | sure, it's, let's say, "on hold" :-) |
| 05:45.07 | kyak | so you mean, upstream it to openwrt, then perhaps it will find its way to upstream kernel.. sounds good |
| 05:45.31 | wolfspraul | not 'perhaps', but yes |
| 05:45.40 | kyak | ok, 'yes' :) |
| 05:45.41 | wolfspraul | I am thinking about the shortest path to a practical use case |
| 05:45.43 | wolfspraul | I want to use this thing |
| 05:45.47 | wolfspraul | NOW! |
| 05:45.48 | wolfspraul | :-) |
| 05:46.02 | wolfspraul | (other than looking at it, which is a start but not enough :-)) |
| 05:46.49 | wolfspraul | and like I said I think I also want to experiment with some casing |
| 05:46.57 | wolfspraul | probably in the form of an epoxy or glue blob |
| 05:47.07 | wolfspraul | yes it takes away 'hackability', but what exactly would one want to do? |
| 05:47.29 | wolfspraul | so it makes more sense to document some good materials and how to exactly get it sealed, and impact on RF performance |
| 05:59.53 | *** join/#qi-hardware cladamw (~Adam@host-222.80-43-115.dynamic.totalbb.net.tw) |
| 06:11.21 | *** join/#qi-hardware xiangfu (~xiangfu@fidelio.qi-hardware.com) |
| 06:15.25 | *** join/#qi-hardware pabs3 (~pabs@d175-38-167-124.per801.wa.optusnet.com.au) |
| 06:33.20 | xiangfu | kyak, the build host mplayer still have faad2. :( http://pastebin.com/W1JdwxtD |
| 06:33.35 | xiangfu | kyak, I try to disable it under './configure' |
| 06:33.56 | xiangfu | re-generate the rootfs now. |
| 06:35.15 | kyak | argh |
| 06:35.27 | wolfspraul | don't worry, be happy |
| 06:35.39 | kyak | maybe just add faad2 to rootfs? |
| 06:35.43 | wolfspraul | kyak: have you found any time to play with your milkymist board? |
| 06:35.49 | xiangfu | kyak, it's patent package. |
| 06:36.04 | kyak | really? oh.. |
| 06:36.39 | xiangfu | it's for AAC. mpeg-4 |
| 06:37.27 | kyak | wolfspraul: not yet really.. but it's on my desk in front of me, so i won't forget :) just need some time |
| 06:37.56 | xiangfu | kyak, how to find out the ./configure option. ./configure --help give me nothing . |
| 06:38.23 | kyak | lemme have a look.. |
| 06:39.46 | wolfspraul | excellent! |
| 06:40.16 | wolfspraul | the fpga is really a new angle/dimension to think of, so having it there for a while is good |
| 06:43.56 | kyak | xiangfu: --disable-faad should do the trick |
| 06:45.08 | kyak | i think this can be put into CONFIGURE_ARGS under the else for CONFIG_BUILD_PATENTED |
| 06:45.24 | *** join/#qi-hardware pabs3 (~pabs@d175-38-167-124.per801.wa.optusnet.com.au) |
| 06:57.07 | *** join/#qi-hardware DocScrutinizer (~halley@openmoko/engineers/joerg) |
| 06:57.28 | xiangfu | kyak, v |
| 06:57.31 | xiangfu | unrecognized options: --disable-faad |
| 07:08.45 | xiangfu | kyak, easy way is just './scripts/feeds uninstall faad2' :) |
| 07:16.31 | *** join/#qi-hardware xiangfu (~xiangfu@fidelio.qi-hardware.com) |
| 07:21.52 | *** join/#qi-hardware xwalk (~crosswalk@rrcs-98-102-156-195.central.biz.rr.com) |
| 07:23.12 | xwalk | Can anyone assist me in the process of hooking up the Ben Nanonote to a Fedora Machine through usb? I can ssh into the Nanonote no problem, but I can't seem to get a ping sent from the Nanonote to a web address (e.g. google.com). |
| 07:33.49 | kyak | xiangfu: some package pulls that faad2 as a dependency, i guess |
| 07:35.30 | kyak | xwalk: did you follow instructions in http://en.qi-hardware.com/wiki/Ethernet_over_USB ? |
| 07:39.15 | kyak | xiangfu: it doesn't complain for --disable-faad for me.. |
| 07:39.49 | xiangfu | kyak, ok. then we also add this to makefile. |
| 07:40.19 | xiangfu | kyak, I driect test this option under build_dir/.../mplayer.../ |
| 07:41.10 | kyak | xiangfu: better add this to Makefile and make package/mplayer/{clean,compile} V=99 |
| 07:42.06 | kyak | then i see faad2 in disabled codecs |
| 07:42.17 | kyak | at the end of configure process |
| 07:42.33 | xiangfu | great. |
| 07:43.18 | xiangfu | I am re-generate the rootfs now... after (./scriptfs/feeds uninstall faad) |
| 07:43.40 | kyak | do yo umean clean rebuild? |
| 07:43.48 | xiangfu | no. no. |
| 07:44.17 | xiangfu | not make clean. just make for re-generate the rootfs and packages. |
| 07:44.22 | kyak | hm |
| 07:44.46 | kyak | this might be not sufficient, as ./scriptfs/feeds uninstall faad doesn't remove the faad2 headers/libs |
| 07:44.58 | kyak | very strange, as faad2 depends on BUILD_PATENDED |
| 07:45.09 | kyak | how did it even get built? |
| 07:45.15 | xiangfu | make package/faad/clean && ./scripts/feeds uninstall faad. |
| 07:45.27 | xiangfu | strange. |
| 07:45.33 | kyak | yes, this should work.. but then again, why is it even there |
| 07:46.06 | xiangfu | strange. |
| 07:46.11 | xiangfu | bug somewhere. |
| 07:46.46 | kyak | i don't see faad anywhere in config as well |
| 07:47.02 | kyak | it should not have been built |
| 07:47.39 | kyak | it's not in resulting packages as well |
| 07:51.46 | qi-bot | [commit] kyak: mplayer: disable faad explicitely (master) http://qi-hw.com/p/openwrt-packages/e07e941 |
| 07:57.39 | kyak | it seems that CONFIG_ALL makes it so that all packages are built; but only those packages not depending on BUILD_PATENTED are actually installed (i.e. actual ipk created). |
| 07:58.46 | kyak | by looking into build log i see that libfaad2 is built, but no ipk is created with "WARNING: skipping libfaad2 -- package not selected" |
| 07:59.11 | kyak | this is pretty strange.. i would say that BUILD_PATENTED must be stronger than CONFIG_ALL |
| 07:59.19 | xiangfu | make sense. |
| 07:59.29 | xiangfu | report bug again :) |
| 07:59.53 | kyak | so we need to disable shit very explicitely.. |
| 08:01.18 | kyak | there are other packages that exhibit the same behaviour |
| 08:02.05 | kyak | ah... |
| 08:02.12 | kyak | i think i get it now |
| 08:02.33 | kyak | package pianobar has libfaad2 as PKG_BUILD_DEPENDS |
| 08:03.28 | xiangfu | so BUILD_PATENTED must be stronger than PKG_BUILD_DEPENDS and all others. |
| 08:03.54 | kyak | indeed |
| 08:08.52 | kyak | the problem in this particular case is that the package pianobar provides several packages, like 'pianobar' and 'libpiano'; and only 'pianobar' depends on libfaad2, but 'libpiano' doesn't depend on anything patented, so it gets build. And it leads to building of packages in PKG_BUILD_DEPENDS, which has faad2 |
| 08:09.12 | kyak | in principal, this particular package is just poorly packaged |
| 08:09.20 | kyak | but there might be more packages like that |
| 08:12.12 | kyak | it could also mean that some other ipk's might require patented libraries as well, because they were present at build time, but (luckily) ipk's for these libraries are not built anyway |
| 08:13.03 | kyak | so we are not limited to mplayer problem |
| 08:15.35 | xiangfu | true. |
| 08:16.41 | xiangfu | kyak, please report a bug to upstream since you already dig such information |
| 08:17.34 | wolfspraul | I think dependency issues are potentially and in reality infinite. so I would try to clean them up carefully on an as-needed basis |
| 08:17.37 | kyak | ok.. |
| 08:17.55 | wolfspraul | rather than trying to fix "them all", which must be the ultimate job for sysiphos |
| 08:18.31 | wolfspraul | but little by little we can make the dependencies both more accurate and flexible at the same time, sure |
| 08:18.59 | kyak | that's quite true |
| 08:19.14 | kyak | find the bug - fix the bug :) |
| 08:22.10 | qi-bot | [commit] Xiangfu: nanonote buils scripts file: add patch-openwrt.sh (master) http://qi-hw.com/p/openwrt-packages/caa7c09 |
| 08:22.23 | xwalk | kyak: Sorry for the delayed response. At work showing a new employee the ropes. Yes, I certainly did. |
| 08:22.45 | xwalk | kyak: I made sure I am using wicd as well. |
| 08:25.24 | xiangfu | Fedora have some default rules at 'iptables' |
| 08:25.54 | xiangfu | xwalk, you may just disable all iptables. then add iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.254.0/24 |
| 08:26.02 | xiangfu | and sysctl -w net.ipv4.ip_forward=1 |
| 08:26.16 | xiangfu | xwalk, then your nanonote should able to access Internet. |
| 08:30.08 | xwalk | Is removing the iptables service going to need a reboot to take effect? |
| 08:30.49 | xiangfu | xwalk, iptables -F should be ok. |
| 08:31.04 | kyak | xiangfu: https://dev.openwrt.org/ticket/11266 (lots of letters) |
| 08:31.35 | xwalk | xiangfu: Got it working. Thank you very much. =) |
| 08:31.46 | xwalk | kyak: Thank you as well. |
| 08:32.02 | xiangfu | kyak, thanks |
| 08:49.00 | *** join/#qi-hardware xiangfu (~xiangfu@fidelio.qi-hardware.com) |
| 09:08.16 | *** join/#qi-hardware cladamw (~Adam@host-222.80-43-115.dynamic.totalbb.net.tw) |
| 09:10.23 | *** join/#qi-hardware rejon (~rejon@jp.fabricatorz.com) |
| 09:21.44 | *** join/#qi-hardware Ayla (~paul@241.45.123.78.rev.sfr.net) |
| 09:22.43 | *** join/#qi-hardware LunaVorax (~LunaVorax@ABordeaux-651-1-155-243.w109-222.abo.wanadoo.fr) |
| 09:42.53 | *** join/#qi-hardware Ayla (~paul@171.215.73.86.rev.sfr.net) |
| 09:46.48 | *** join/#qi-hardware orsonzhai (~zhai@1.202.15.210) |
| 10:43.41 | qi-bot | [commit] Xiangfu: js28f256j3f105: add missing A8 pin (master) http://qi-hw.com/p/kicad-libs/1025859 |
| 10:43.43 | *** join/#qi-hardware jivs_ (~jivs@nat-sta-slph1.tvu.ac.uk) |
| 10:48.48 | cladamw | xiangfu, nice now, you can back up me. ;-) |
| 10:49.42 | *** join/#qi-hardware Ayla (~paul@47.215.73.86.rev.sfr.net) |
| 11:05.41 | *** join/#qi-hardware jekhor (~jek@mx2.promwad.com) |
| 11:10.06 | DocScrutinizer | tsunami warning cancelled |
| 11:12.38 | wpwrak | DocScrutinizer: in nuernberg ? that must be a big one |
| 11:12.52 | DocScrutinizer | bwahaha |
| 11:14.56 | DocScrutinizer | I raely spam IRC with nuernberg local news |
| 11:15.36 | wpwrak | so it's a global tsunami ? even scarier |
| 11:15.37 | DocScrutinizer | at least not the "global" channels of IRC |
| 11:15.53 | DocScrutinizer | nah, only indian ocean, like 2004 |
| 11:16.24 | DocScrutinizer | so 'only' a few millions affected |
| 11:16.36 | DocScrutinizer | not exactly *global* |
| 11:22.09 | DocScrutinizer | a global tsunami would mean either a) yellowstone exploded and took USA with it, or b) some meteorite size in km-range hit some ocean. In both cases I think you couldn't globally cancel the tsunami warning |
| 11:23.17 | wpwrak | well, sometimes meteorite trajectories get mis-calculated |
| 11:44.19 | DocScrutinizer | aftershock quake 8.1, tsunami warning still extended by 2 hours |
| 11:56.01 | *** join/#qi-hardware GNUtoo (~gnutoo@host149-73-dynamic.56-82-r.retail.telecomitalia.it) |
| 11:56.13 | *** join/#qi-hardware cladamw (~adamwang@host-222.80-43-115.dynamic.totalbb.net.tw) |
| 12:10.59 | *** join/#qi-hardware cladamw (~Adam@host-222.80-43-115.dynamic.totalbb.net.tw) |
| 12:14.05 | *** join/#qi-hardware qwebirc39331 (50206335@gateway/web/freenode/ip.80.32.99.53) |
| 12:15.08 | qwebirc39331 | anyway of upgrading all openwrt packages from nanonote? |
| 12:18.21 | xiangfu | qwebirc39331, Hi |
| 12:18.35 | qwebirc39331 | Hi |
| 12:19.46 | xiangfu | qwebirc39331, first you needs make sure the nanonote connect to Internet: openwrt-xburst.full_system-20120409-2355 |
| 12:20.33 | xiangfu | qwebirc39331, I think so far no one have tried to upgrading all packages. |
| 12:20.43 | qwebirc39331 | a new image? so I hace to use usbboot instead? |
| 12:21.11 | xiangfu | usbboot is faster. |
| 12:21.52 | qwebirc39331 | I was trying to use a command I saw on a website, but didn't work. |
| 12:22.49 | xiangfu | qwebirc39331, you mean usbboot? |
| 12:23.13 | xiangfu | http://en.qi-hardware.com/wiki/Updating_Ben_NanoNote_software |
| 12:24.13 | qwebirc39331 | no, the command I saw was " opkg upgrade 'list-upgradable' " |
| 12:24.49 | qwebirc39331 | also, where can I find a pygame package? |
| 13:01.59 | DocScrutinizer | "tsunami aftershock not causing any tsunami either" says German TV ZDF correspondent Peter Kunz |
| 13:02.12 | DocScrutinizer | err |
| 13:02.29 | DocScrutinizer | "aftershock earthquake not causing any tsunami either" says German TV ZDF correspondent Peter Kunz |
| 13:02.59 | xiangfu | hmm... we have some base components on board-qi-avt2 and milkymist |
| 13:03.02 | xiangfu | like testpoint. |
| 13:03.47 | xiangfu | Now we have kicad-libs. should add all the components we used to that repo. |
| 13:04.11 | wolfspraul | sure you can clean that up, - BUT - only if we can keep the quality up |
| 13:04.29 | wolfspraul | if it's a blind copy/paste activity then maybe let's wait until we really use those parts |
| 13:04.37 | xiangfu | yes. |
| 13:04.47 | wolfspraul | the #1 problem of kicad libraries is low quality imho |
| 13:04.52 | xiangfu | agree. I will copy the testpoint first. since I start to need that. |
| 13:04.58 | wolfspraul | good |
| 13:07.29 | qi-bot | [commit] Xiangfu: add testpoint (master) http://qi-hw.com/p/kicad-libs/a7b0a8b |
| 13:09.17 | xiangfu | sorry. what you mean "low quality" ? leak feature? |
| 13:09.47 | wolfspraul | incomplete, buggy |
| 13:09.56 | wolfspraul | the parts I mean |
| 13:09.58 | xiangfu | ok. |
| 13:12.44 | Fallenou | kyak: not sure if X11 is required by VNC server, I've seen it working on an Android plateform without X11. Android was just using the OMAP3 framebuffer (omapfb) in /dev/graphics/fb0 |
| 13:13.00 | Fallenou | so I guess there is a way of using VNC server with a framebuffer |
| 13:13.41 | viric | the vnc server is an X11 server |
| 13:14.10 | viric | (at least the traditional Xvnc) |
| 13:48.30 | qi-bot | [commit] Xiangfu: add common.lib include R, C, LED (master) http://qi-hw.com/p/kicad-libs/75a4fba |
| 13:50.44 | xiangfu | wpwrak, adam please check the NORFlash sheet. I just finished it. |
| 13:51.33 | xiangfu | I am not sure on junction. please give some advice. |
| 13:51.45 | xiangfu | check log tomorrow. |
| 13:54.35 | wpwrak | hmm, LibDir is a bit of a problem |
| 13:55.00 | wpwrak | if you have /home/qi/kicad-libs and /home/qi/board-m1, then the components aren't found |
| 13:55.24 | wpwrak | (substitute /home/qi for anything you like) |
| 13:56.29 | wpwrak | and yes, shorting all the FLASH_{RESET*,etc.} lines together doesn't look right :) |
| 13:57.02 | wpwrak | you also picked A3 paper. does everyone around here have an A3 printer ? |
| 13:57.29 | wolfspraul | I think we should merge those styles & units things into a file in the repo, no? |
| 13:57.32 | wolfspraul | and remove it from the wiki |
| 13:58.32 | wpwrak | yes, there should be a proper manual |
| 13:59.45 | wpwrak | not sure how to deal with the current flurry of changes, though. my current plan is to wait until adam runs out of steam and then start fixing things :) |
| 14:00.20 | wolfspraul | well it's better to discuss early |
| 14:00.51 | wolfspraul | or wait until the current status has reached consensus quality level |
| 14:01.29 | wpwrak | LibDir has an easy solution. good :) |
| 14:01.30 | wolfspraul | are any of the things you see being done a waste of time and need to be redone? |
| 14:01.54 | wolfspraul | as long as we are lifting each other up that's ok. but if someone goes in a wrong direction we should notify early. |
| 14:02.18 | wpwrak | there are several font size issues |
| 14:02.32 | wpwrak | i'm also not very happy with naming negated signals FOO# |
| 14:03.13 | wpwrak | the pin number in TPxx is useless. there's only one anyway. |
| 14:04.30 | wpwrak | sheet size is probably the worst time-wasting risk |
| 14:14.10 | *** join/#qi-hardware jivs_ (~jivs@193.63.24.74) |
| 14:38.46 | *** join/#qi-hardware panda|x201 (~hzhang@2001:5c0:1000:a::1a3) |
| 14:41.57 | *** join/#qi-hardware roh (~roh@static.30.226.46.78.clients.your-server.de) |
| 14:42.01 | roh | re |
| 14:56.50 | kyak | Fallenou: are you sure what you've seen wasn't vnc client |
| 14:57.06 | kyak | ? |
| 14:58.26 | *** join/#qi-hardware Ayla (~paul@103.179.26.93.rev.sfr.net) |
| 15:09.37 | *** join/#qi-hardware freespace (~steve@64.16.211.113) |
| 15:14.41 | Fallenou | kyak: it was a VNC server running on an Android gadget |
| 15:17.10 | *** join/#qi-hardware jivs_ (~jivs@nat-sta-slph1.tvu.ac.uk) |
| 15:34.37 | kyak | Fallenou: probably something like that: http://code.google.com/p/fastdroid-vnc/ |
| 15:35.19 | kyak | don't see how it can be done on a router though.. first need to implement some kind of virtual framebuffer device? |
| 15:37.01 | *** join/#qi-hardware Ayla (~paul@53.121.101.84.rev.sfr.net) |
| 15:38.56 | Fallenou | well yes you need what you want to share through VNC to be drawned in a framebuffer |
| 15:39.46 | Fallenou | the vnc server I've seen was some proprietary official vnc server |
| 15:39.50 | Fallenou | which needed a license |
| 15:41.38 | Fallenou | but it seems you have found a project which support android framebuffer which is nice :) |
| 15:41.55 | Fallenou | will it support other framebuffers ... for your router ... dunno |
| 15:45.22 | Fallenou | the code seems to be rather generic, it should work with any other framebuffer I think |
| 15:45.41 | Fallenou | see http://code.google.com/p/fastdroid-vnc/source/browse/trunk/fbvncserver.c |
| 15:45.44 | Fallenou | init_fb() |
| 15:53.19 | *** join/#qi-hardware kilae (~chatzilla@catv-161-018.tbwil.ch) |
| 16:18.32 | *** join/#qi-hardware Ayla (~paul@47.215.73.86.rev.sfr.net) |
| 16:39.39 | *** join/#qi-hardware emeb (~ericb@ip72-223-81-94.ph.ph.cox.net) |
| 16:45.20 | *** join/#qi-hardware mth (uzaypffy@dhcp-089-098-069-120.chello.nl) |
| 17:11.48 | kyak | mth: the bug in gmenu2x is no more. Thank you! |
| 17:12.33 | mth | good to have that confirmed, thanks |
| 17:12.51 | qi-bot | [commit] kyak: gmenu2x: update to latest git (master) http://qi-hw.com/p/openwrt-packages/7671b2b |
| 17:35.48 | *** join/#qi-hardware green` (~user@CPE0021910f07ac-CM0019477f82fc.cpe.net.cable.rogers.com) |
| 17:44.03 | *** join/#qi-hardware kilae (~chatzilla@catv-161-018.tbwil.ch) |
| 17:51.35 | *** join/#qi-hardware Ayla (~paul@47.215.73.86.rev.sfr.net) |
| 18:17.00 | *** join/#qi-hardware jurting (~jommpa90_@ip-196-213-241-92.dialup.ice.net) |
| 18:42.14 | *** join/#qi-hardware viric (~viric@unaffiliated/viric) |
| 18:52.04 | *** join/#qi-hardware Ayla (~paul@19.215.73.86.rev.sfr.net) |
| 19:44.52 | *** join/#qi-hardware LunaVorax (~LunaVorax@ABordeaux-651-1-155-243.w109-222.abo.wanadoo.fr) |
| 19:51.52 | *** join/#qi-hardware jekhor (~jek@leased-line-46-53-195-5.telecom.by) |
| 19:55.54 | *** join/#qi-hardware jekhor (~jek@leased-line-46-53-195-5.telecom.by) |
| 20:32.43 | qi-bot | [commit] Werner Almesberger: kicad-patches/README: added quilt-based update process for KiCad (master) http://qi-hw.com/p/eda-tools/1a72c97 |
| 20:32.44 | qi-bot | [commit] Werner Almesberger: kicad-patches/README: bump KiCad version to bzr 3494 (master) http://qi-hw.com/p/eda-tools/5083973 |
| 20:59.39 | *** join/#qi-hardware roh (~roh@static.30.226.46.78.clients.your-server.de) |
| 21:29.14 | *** join/#qi-hardware viric_ (~viric@unaffiliated/viric) |
| 22:54.09 | *** join/#qi-hardware GeorgeH (~George@c-69-141-105-145.hsd1.nj.comcast.net) |
| 23:00.15 | wpwrak | wolfspraul: btw, i couldn't build kicad bzr 3493 (pcbnew didn't link). so i bumped it to 3494. |
| 23:00.31 | wolfspraul | and that worked? |
| 23:01.28 | wpwrak | it compiled fine. there was a change in just the area where the problem appeared, which i take as a good omen. (didn't try to dig deeper) |
| 23:02.22 | wolfspraul | let me know if you need upleveling |
| 23:02.30 | wolfspraul | I think next time I can do it in 1h |
| 23:02.50 | wolfspraul | I have a simple test bench now, the uplevel steps are documented, etc. |
| 23:02.55 | wpwrak | your patches applied fine to 3494 |
| 23:04.09 | wpwrak | afk for a bit |
| 23:18.25 | wpwrak | back |
| 23:38.21 | wolfspraul | it seems kicad is moving to metric here and there |
| 23:38.43 | wolfspraul | so in the modules position file for example, I changed the default (and only) to metric |
| 23:38.59 | wolfspraul | and front and back in the same file _all.pos (before it was _Front.pos and _Back.pos) |
| 23:39.02 | wolfspraul | just fyi |
| 23:39.04 | wolfspraul | I don't think we are using that anyway |
| 23:41.06 | wpwrak | the .pos file ? of yes, we're using that for fab output |
| 23:41.20 | wolfspraul | oh |
| 23:41.37 | wolfspraul | then my upleveling certainly broke that |
| 23:42.00 | wolfspraul | kicad now has a dialog with some options there, metric or inches, 'force smd', front and back in separate files or in one file |
| 23:42.12 | wolfspraul | what do you want? |
| 23:44.19 | wpwrak | right now, pos2fab (from eda-tools/fab/) assumes inches. not sure what "force smd" means. not sure whether fabs are happier with front and back split or together. |
| 23:44.46 | wpwrak | pos2fab takes the .pos file and turns it into an excel-friendly .csv table |
| 23:45.05 | wolfspraul | just tell me what you want :-) |
| 23:45.13 | wolfspraul | you can look at the dialog now, see the options there |
| 23:45.32 | wpwrak | see http://downloads.qi-hardware.com/people/werner/wpan/fab/atusb-smt-110330.tar.gz |
| 23:45.39 | wpwrak | file atusb/atusb-bom.csv |
| 23:46.01 | wpwrak | err, wsorry |
| 23:46.23 | wpwrak | atusb/atusb-pos.csv |
| 23:46.26 | wpwrak | that's the one |
| 23:48.49 | wpwrak | the defaults look nice: inches, one file per side, with INSERT attribute set |
| 23:49.23 | wpwrak | i don't care much about the inches. just pos2fab needs to agree with what we extract from kicad |
| 23:49.46 | wpwrak | perhaps we should have a switch |
| 23:58.01 | wpwrak | and afk again. may take a bit. proprietor's reunion ... |