| 00:46.17 | *** join/#qi-hardware guanucoluis (~luis@2001:470:e450:0:225:56ff:fea1:2064) |
| 01:03.51 | *** join/#qi-hardware xiangfu (~xiangfu@fidelio.qi-hardware.com) |
| 01:24.43 | *** join/#qi-hardware rodgort (~rodgort@li125-242.members.linode.com) |
| 02:05.48 | *** join/#qi-hardware panda|x201 (~hzhang@2001:c08:3700:ffff::b01) |
| 02:45.52 | *** join/#qi-hardware rejon (~rejon@jp.fabricatorz.com) |
| 03:05.15 | kristianpaul | wpwrak: had you survey other people about the same wine effect from that brand? :-) |
| 03:10.58 | *** join/#qi-hardware heberth (~heberth@190.97.216.110) |
| 03:13.11 | wpwrak | only on smaller quantities. still need to do a more extensive study for my paper in Nature. |
| 03:20.12 | *** join/#qi-hardware rejon (~rejon@jp.fabricatorz.com) |
| 03:53.58 | *** join/#qi-hardware emeb (~ericb@75-94-3-36.war.clearwire-wmx.net) |
| 04:33.12 | *** join/#qi-hardware emeb1 (~ericb@75-94-3-36.war.clearwire-wmx.net) |
| 04:35.10 | kristianpaul | bye bye ansi c, welcome posix threads and semaphores |
| 04:36.34 | kristianpaul | hope this make code more portable between linux and rtems.. |
| 04:37.21 | DocScrutinizer05 | hmm |
| 04:37.53 | DocScrutinizer05 | how's ansi c in conflict with posix? |
| 04:38.50 | DocScrutinizer05 | aah wait, threads |
| 04:39.12 | DocScrutinizer05 | I seem to recall sth from 5+ years ago |
| 04:39.28 | DocScrutinizer05 | along lightweight threads or sth |
| 05:32.38 | *** join/#qi-hardware qwebirc63101 (626ce7c5@gateway/web/freenode/ip.98.108.231.197) |
| 05:33.19 | rjeffries | these speakers are rather cool. and open. http://web.media.mit.edu/~mellis/speakers/ |
| 05:49.17 | *** part/#qi-hardware emeb1 (~ericb@75-94-3-36.war.clearwire-wmx.net) |
| 05:56.07 | *** join/#qi-hardware LunaVorax (~LunaVorax@cau33-2-82-227-183-10.fbx.proxad.net) |
| 05:59.24 | LunaVorax | Hello |
| 06:06.04 | *** join/#qi-hardware xwalk (~crosswalk@ip-64-134-127-216.public.wayport.net) |
| 06:15.30 | *** join/#qi-hardware jekhor (~jek@leased-line-46-53-195-83.telecom.by) |
| 06:36.42 | *** join/#qi-hardware kilae (~chatzilla@catv-161-018.tbwil.ch) |
| 06:40.42 | wpwrak | @%$#*! when a usb low-speed device tries to register bulk EPs (which for some obscure reason isn't allowed by the usb spec), linux helpfully converts them to interrupt. this is of course breaks any use of them as bulk with protocols that do require bulk and that won't be satisfied with interrupt. such as mass storage :-( |
| 06:44.49 | wpwrak | so because of linux enforcing this arbitrary restriction in the usb spec, one can't implement mass storage with a low-speed device :-( |
| 06:45.58 | larsc | does it work on windows? |
| 06:46.39 | larsc | or any other OS |
| 06:47.11 | wpwrak | i don't have any windows around here, but someone who made such a device claimed "it usually works". and his files are full of \r\n. so i would suspect he tried it there. |
| 06:50.01 | wpwrak | of course, if it only doens't work on linux, that would be tolerable. on linux it's easy to use some other mechanism. |
| 07:25.15 | *** join/#qi-hardware LunaVorax (~LunaVorax@cau33-2-82-227-183-10.fbx.proxad.net) |
| 09:51.56 | viric | wpwrak: iirc, the gp2x offers a mass storage device at usb 1.1 |
| 09:52.11 | viric | 1.1 == low speed? or that is 'full' speed? |
| 10:21.35 | *** join/#qi-hardware jurting (~jurting@ip-125-46-149-91.dialup.ice.net) |
| 10:35.36 | *** join/#qi-hardware Ayla (~paul@ACaen-157-1-151-122.w90-62.abo.wanadoo.fr) |
| 10:36.35 | *** join/#qi-hardware kuribas (~user@94-227-93-194.access.telenet.be) |
| 10:59.56 | larsc | viric: I think 1.1 offered both full and low speed |
| 11:00.20 | larsc | low speed for stuff like mouse and keyboards and full speed for storage |
| 11:14.12 | *** join/#qi-hardware kuribas (~user@94-227-93-194.access.telenet.be) |
| 11:38.32 | viric | larsc: ah ok |
| 11:48.39 | wpwrak | yes, 1.1 = { low, full }. 2.0 = { low, full, high }. that's why you also see full-speed "USB 2.0" devices. |
| 11:57.58 | whitequark | wpwrak: erm, sorry, you are wrong afaik |
| 11:58.23 | whitequark | the linux behavior actually _allows_ you to use bulk endpoints on low-speed devices, which are indeed prohibited by usb spec |
| 11:58.43 | whitequark | I know that because I've played with V-USB, a software-defined USB device stack for ATmega processors |
| 11:58.52 | whitequark | and it obviously only offers low-speed 1.1 |
| 11:59.28 | whitequark | with these software-defined devices, bulk endpoints actually work in Linux and sometimes work on other OSes |
| 11:59.29 | wpwrak | yes, i'm also experimenting with v-usb |
| 11:59.44 | wpwrak | did you try mass storage ? |
| 12:01.55 | whitequark | in fact, that hack was added almost specifically for v-usb, because otherwise bulk polling was overloading the device. it's not there to break v-usb, it's there to fix it |
| 12:01.58 | whitequark | iirc yes |
| 12:02.03 | whitequark | that was some years ago, through |
| 12:05.24 | wpwrak | what i see is this: drivers/usb/core/config.c:usb_parse_endpoint converts all usb_endpoint_xfer_bulk() endpoints on low-speed devices to USB_ENDPOINT_XFER_INT |
| 12:05.51 | wpwrak | usb_endpoint_xfer_bulk() is the test wrapper, from include/linux/usb/ch9.h |
| 12:06.19 | *** join/#qi-hardware xwalk (~crosswalk@d47-69-35-236.try.wideopenwest.com) |
| 12:06.59 | wpwrak | then drivers/usb/storage/usb.c:get_pipes searches the list of EPs for bulk EPs and remembers them. it also remembers an usb_endpoint_is_int_in() EP, if it fonds one (for a different protocol variant) |
| 12:07.41 | wpwrak | since all the bulk EPs have become interrupt now, it then fails the sanity check right after the scan, and returns with -EIO |
| 12:07.47 | whitequark | hm |
| 12:07.57 | whitequark | could you just maybe try with .26 kernel? |
| 12:08.19 | whitequark | because, as I've been saying, that was quite a while ago and an unrelated change to the USB subsystem might have broken it |
| 12:08.30 | wpwrak | i looked at 2.6.36, and it looks the same there |
| 12:08.40 | whitequark | I'm pretty sure this used to work, but as this is quite an obscure feature |
| 12:09.50 | wpwrak | 2.6.8.1 doesn't seem to have the "correction" |
| 12:10.33 | whitequark | too old :) |
| 12:10.46 | whitequark | I used 2.6.26 these times |
| 12:10.51 | whitequark | or maybe .22 |
| 12:11.19 | larsc | commit 60aac1ec added it |
| 12:13.21 | whitequark | can't look at gitweb right now, sorry |
| 12:13.22 | wpwrak | hmm, when was that ? i don't have any kernel git repo around at the moment |
| 12:13.46 | whitequark | I'll be back after a few hours |
| 12:14.08 | wpwrak | ah wait, there's one |
| 12:14.11 | larsc | 2007 |
| 12:14.18 | wpwrak | Fri Jun 8 15:25:02 2007 -0400 |
| 12:19.12 | *** join/#qi-hardware guanucoluis (~luis@190.123.120.234) |
| 12:24.25 | *** join/#qi-hardware jekhor (~jek@178.120.112.123) |
| 12:28.38 | wpwrak | well, i'll return to this issue. then i'll disable the "fix" and see if this makes things work. that way, i could make something that can be tested with legacy operating systems. |
| 12:30.06 | wpwrak | the objective of the whole exercise is to find a way to put data (a few kB) on a USB device without needing drivers for windows and such. seems that storage is the only way to do this. |
| 12:47.59 | viric | ah this last sentence clarified a lot |
| 12:49.38 | wpwrak | heh, thought it might :) |
| 12:51.21 | viric | can't you have something like a keyboard, and send using the status leds ? :) |
| 12:51.31 | viric | capslock, numlock, ... |
| 12:51.56 | viric | it'd be nice to see the bandwidth for that |
| 12:52.02 | wpwrak | maybe. but then i'd need a special application that toggles the leds. |
| 12:52.20 | viric | and it may toggle the leds in all computer keyboards hehe |
| 12:52.31 | wpwrak | yeah, that too :) |
| 12:53.43 | wpwrak | well, one option would be DFU. that seems to be taken care of, even though the installation seems to be a bit on the ugly side. |
| 12:54.15 | viric | dfu? |
| 12:54.17 | wpwrak | of course, once we accept libusb in the mix, anything goes |
| 12:54.30 | wpwrak | a tftp-like firmware download protocol |
| 12:54.44 | wpwrak | pretty popular these days |
| 12:55.13 | wpwrak | the openmoko phones had it, idbg has it, atusb has it, ... |
| 12:55.50 | wpwrak | the only risk is that it finds some other device and sends your firmware there. now if that other device has no sanity checks, ... |
| 12:56.07 | wpwrak | e.g., seems many BT devices are dfu-upgradeable |
| 13:06.12 | *** join/#qi-hardware rejon (~rejon@jp.fabricatorz.com) |
| 13:07.06 | *** join/#qi-hardware kuribas (~user@94-227-93-194.access.telenet.be) |
| 13:47.48 | *** join/#qi-hardware GNUtoo (~gnutoo@90.84.144.201) |
| 14:04.00 | *** join/#qi-hardware emeb (~ericb@75-94-3-36.war.clearwire-wmx.net) |
| 14:13.30 | *** join/#qi-hardware DocScrutinizer (~halley@openmoko/engineers/joerg) |
| 14:13.37 | *** join/#qi-hardware DocScrutinizer05 (~HaleBopp@openmoko/engineers/joerg) |
| 14:21.29 | whitequark | wpwrak: WRONG |
| 14:21.54 | wpwrak | you tried with a recent kernel and it worked ? |
| 14:22.09 | whitequark | the easiest way of putting something on a low-speed device while writing as fewer drivers as possible isn't mass storage |
| 14:22.12 | whitequark | it's HID |
| 14:22.14 | whitequark | quite un-obviously |
| 14:22.21 | wpwrak | ah |
| 14:22.28 | whitequark | HID doesn't need a kernel driver on linux nor windows |
| 14:22.31 | wpwrak | yes, but you still need an application that mangles HID |
| 14:22.33 | whitequark | and it works perfectly with 1.1 devs |
| 14:22.34 | whitequark | yep |
| 14:22.57 | whitequark | but afaik windows won't recognize such an UMS device at all |
| 14:23.20 | whitequark | so even if it'll work with that hack or without it, it'll only be restricted to linuxen |
| 14:23.55 | wpwrak | (ls-ums & windows) would need testing to verify |
| 14:24.05 | wpwrak | well, plan B is "some other protocol" |
| 14:24.11 | whitequark | sure, don't trust my words alone |
| 14:24.40 | whitequark | I'm also not sure how would you handle the accesses |
| 14:24.46 | whitequark | do you want to provide a fake FATFS? |
| 14:24.57 | *** join/#qi-hardware woakas (~woakas@186.28.87.31) |
| 14:25.20 | GNUtoo | hi, there are a lot of gadgets drivers in mainline |
| 14:25.22 | wpwrak | plan C is to find a chip that can do full-speed. unfortunately, this is tricky. NXP may have one ... LPC11U12FHN33/201. but that needs further examinations. has a few quirks, i can tell that already |
| 14:25.36 | wpwrak | whitequark: yes, exactly |
| 14:26.17 | wpwrak | MBR, boot sector, FAT, and root directory provided by software. the clusters would be real flash blocks. |
| 14:26.38 | whitequark | wpwrak: flash? so you plan to provide your own FTL? |
| 14:26.43 | wpwrak | well, chunks of flash. much larger than the chip's "block"/"page" or whatever it's called |
| 14:26.58 | wpwrak | no, it's just for firmware |
| 14:27.06 | whitequark | erm, blocks and pages are different entities |
| 14:27.22 | whitequark | a page refers to write resolution, a block refers to erase resolution |
| 14:27.26 | wpwrak | in MCUs you find both words |
| 14:27.46 | wpwrak | and the two sizes are usually identical |
| 14:27.52 | whitequark | i.e. you can write the NAND in 2k or 4k pages (I worked with these chips), and erase them in 128k blocks or so |
| 14:27.55 | wpwrak | i'm talking about small critters |
| 14:27.58 | whitequark | maybe you have a different architecture |
| 14:27.59 | whitequark | hm |
| 14:28.11 | whitequark | I think I understand what do you want to do |
| 14:28.16 | whitequark | or maybe not |
| 14:28.17 | wpwrak | two cluster, 4 kB each. that order. |
| 14:28.19 | whitequark | can you elaborate? |
| 14:28.44 | wpwrak | when you plug the device in a pc, it would enumerate as USB storage |
| 14:29.07 | wpwrak | it would present MBR, boot sector, etc., as if it contained a FAT FS |
| 14:29.17 | whitequark | ok. what chip do you want to use for that? |
| 14:29.22 | whitequark | ATmega I guess? |
| 14:29.24 | wpwrak | MBR and boot sector are sw-generated |
| 14:29.26 | whitequark | which one? |
| 14:29.35 | wpwrak | attiny167, maybe attiny87 |
| 14:30.07 | whitequark | hm |
| 14:30.19 | wpwrak | FAT would be sw-managed - generate on boot, then remember what's written |
| 14:30.32 | wpwrak | smae for the root directory. two entries :) |
| 14:30.53 | wpwrak | then the two data clusters. (fw has two separate parts) |
| 14:31.20 | wpwrak | then all i need to remember in the end is in which cluster which part ended up. and whether it's actually present. |
| 14:32.03 | whitequark | well, that might work |
| 14:32.22 | whitequark | you don't have a lot of ram in that chip, but your bootloader doesn't require much either. |
| 14:32.26 | wpwrak | unless any nasty "sanity checks" get in the way, it should |
| 14:33.22 | wpwrak | just a few bytes. buffer the usb/scsi bureaucracy. flash data can be written as we go. so there's no need to buffer entire sectors or even clusters |
| 14:33.39 | wpwrak | and the fat and directory cache are also small. |
| 14:34.11 | kristianpaul | DocScrutinizer05: my conclusion was no try do that my self (threads library) no matter how light or cooperative it could be |
| 14:34.30 | whitequark | wpwrak: flash write operations can be quite lengthy. |
| 14:34.35 | whitequark | and CPU is halted during erase/write |
| 14:34.54 | whitequark | and if the device won't respond to SOF which is issued every 1ms it'll be reset |
| 14:35.23 | wpwrak | does it have to respond to SOF ? |
| 14:35.34 | whitequark | yes |
| 14:35.41 | whitequark | it's how host understands that the device is alive. |
| 14:35.44 | kristianpaul | whitequark: had you tried fram latelly? |
| 14:35.52 | whitequark | kristianpaul: definitely not me |
| 14:37.12 | whitequark | wpwrak: on the other hand, I have used USBasploader successfully |
| 14:37.33 | whitequark | ah, I know why it can work |
| 14:37.41 | *** join/#qi-hardware mafs (~mafs@bl8-67-191.dsl.telepac.pt) |
| 14:37.50 | whitequark | it has two separate flash partitions, and the bootloader isn't halted on application flash writes |
| 14:37.52 | wpwrak | "The SOF token does not cause any receiving function to generate a return packet;". so at least in full-speed and above, there is no response. checking low-speed, which uses different SOF signaling ... |
| 14:37.53 | mafs | hey can anyone help me? pleaseee graphic card problems |
| 14:38.06 | larsc | noooooooooooooooooo |
| 14:38.21 | whitequark | wpwrak: whether in your device you don't have two separate ones but just one single partition |
| 14:38.35 | kristianpaul | mafs: sorry not general hardware support channel |
| 14:38.54 | kristianpaul | at least you mean milkymist one graphic card :) |
| 14:39.00 | whitequark | judging from the parallel programming characteristics, a chip erase takes 7.5 to 9 ms, and a page write takes 3.7 to 4.5 ms |
| 14:39.19 | Ayla | larsc is the expert of graphic cards, ask him |
| 14:39.21 | whitequark | wpwrak: there's also another problem |
| 14:39.52 | whitequark | wpwrak: you can only write one page at a time and then you have to wait, but the host would happily send you data in whatever quantity it wants |
| 14:40.07 | whitequark | I don't quite remember how much one bulk transfer can be, but it's definitely more than 64 words |
| 14:40.24 | whitequark | you'll have to NAK it the (transfer_size / page_size) times |
| 14:41.37 | whitequark | kristianpaul: what's your need in a thread library? |
| 14:43.35 | wpwrak | whitequark: i don't see anything that suggests the device needs to take action on a keep-alive (SOF for full-speed and above, EOP for low-speed), except that it should suspend if it doesn't receive any |
| 14:44.46 | wpwrak | the bulk transfer will come in many little 8 byte chunks |
| 14:45.37 | whitequark | hm |
| 14:45.59 | whitequark | maybe, I don't remember USB spec that good anymore |
| 14:46.05 | whitequark | probably I'm wrong here |
| 14:46.09 | kristianpaul | whitequark: portabillity and parallel computing |
| 14:46.46 | wpwrak | whitequark: let's hope so :) |
| 14:53.56 | wpwrak | i also wonder if a 48 MHz NXP LPCxxx could be fast enough to do full-speed sw USB ;) |
| 14:58.11 | whitequark | wpwrak: quite certainly not |
| 14:58.22 | whitequark | because USB is, you know, 480 Mbit/s :) |
| 14:58.40 | whitequark | high-speed quite possibly, but I doubt you want to develop a USB stack |
| 14:58.46 | *** join/#qi-hardware kristoffer (~kristoffe@c-13dfe555.010-30-6c6b7012.cust.bredbandsbolaget.se) |
| 14:58.57 | wpwrak | full-speed is 12 Mbps |
| 14:59.11 | wpwrak | and you can do Mass Storage with full-speed ! ;-) |
| 14:59.21 | whitequark | ah, full- vs high-speed |
| 14:59.27 | whitequark | I always mix up the two |
| 14:59.36 | wpwrak | and it wouldn't exectly be the first usb stack i've made :) |
| 14:59.43 | whitequark | oh :) |
| 14:59.54 | whitequark | well, good luck then :) |
| 15:00.38 | wpwrak | well, so far the "stacks" had sat on hardware handling the bit-level stuff. i've written a bit-level decoder, though (for something like a logic analyzer) |
| 15:00.54 | wpwrak | besides, there's v-usb as a reference. and there's a PIC variant, too |
| 15:02.24 | wpwrak | now, a CPU clock of 48 MHz may not quite be enough, but perhaps the CPU could send/receive the data over 1/2 SPI links, with the appropriate trickery. |
| 15:02.47 | wpwrak | sw would then just have to move whole bytes/words and watch for EOP |
| 15:03.05 | wpwrak | then ACK and then figure out what it has actually received :) |
| 15:19.26 | *** join/#qi-hardware porchao (~hato@eatkyo221218.adsl.ppp.infoweb.ne.jp) |
| 16:23.42 | wpwrak | grmbl. the critter is so slow writing to its flash that the usb stack thinks the device is dead and gives up. even if defer the flashing until after usbPoll returns. |
| 16:25.17 | viric | wpwrak: what about a usb serial port or parallel port device? isn't that any standard at all? |
| 16:25.20 | viric | or usbaudio |
| 16:27.13 | wpwrak | hmm. printer. there's probably a massive software stack between a file and the printer. it's even bad on linux, with cups, printer-specific profiles, and so on. |
| 16:27.50 | viric | printing in linux never worked. |
| 16:28.18 | wpwrak | audio may be standard .. but the you probably have to reconfigure the system. not nice. |
| 16:28.35 | wpwrak | oh, printing worked perfectly ... in the days of "lpr" |
| 16:28.50 | wpwrak | lpr file-our-printer-will-understand |
| 16:29.21 | wpwrak | add gs to your print filter, for extra comfort (unless your printer already speaks ps natively, which back then only the really expensive ones did) |
| 16:34.32 | *** join/#qi-hardware Ornotermes (~rikard@78-69-248-123-no180.tbcn.telia.com) |
| 16:34.32 | *** join/#qi-hardware mth (ovmpizde@dhcp-089-098-069-120.chello.nl) |
| 16:44.06 | wpwrak | how that's funny: NXP put USB drivers in the ROM of some of their (pricier) MCUs. when with goodies like mass-storage and DFU. |
| 16:45.09 | *** join/#qi-hardware Ornotermes (~rikard@78-69-248-123-no180.tbcn.telia.com) |
| 16:45.09 | *** join/#qi-hardware mth (ovmpizde@dhcp-089-098-069-120.chello.nl) |
| 16:45.21 | *** join/#qi-hardware urandom__ (~user@p548A18E1.dip.t-dialin.net) |
| 16:49.56 | wpwrak | hah, and is seems that nxp are doing something very similar to what i have in mind. also with emulated mbr, boot sector, fat, directory. |
| 16:50.48 | viric | wpwrak: but this is the cups era. |
| 16:51.17 | viric | I remember that I had to touch cups code... it was a big mess, for my taste |
| 16:51.43 | viric | (I needed it to check certificates for https urls. It doesn't check anything otherwise) |
| 16:52.04 | wpwrak | cups is a mess, yes. that's why i'm pining for the good old days. the golden age of unix printing. |
| 16:52.24 | viric | then there was the ghostscript split too |
| 16:52.43 | viric | gnu ghostscript, vs ghostscript.com |
| 16:52.53 | viric | one lagging vs the other... |
| 16:53.13 | viric | both gplv3 :) |
| 17:10.54 | wpwrak | that must have been long before glpv3 |
| 17:39.17 | *** join/#qi-hardware wpwrak (~werner@234-171-231-201.fibertel.com.ar) |
| 17:48.19 | *** join/#qi-hardware xwalk (~crosswalk@d47-69-35-236.try.wideopenwest.com) |
| 17:49.35 | *** join/#qi-hardware DocScrutinizer (~halley@openmoko/engineers/joerg) |
| 17:58.01 | *** join/#qi-hardware GNUtoo (~gnutoo@90.84.144.201) |
| 17:58.01 | *** join/#qi-hardware rozzin (~rozzin@209-20-69-211.slicehost.net) |
| 17:58.01 | *** join/#qi-hardware Jay7 (jay@128-73-75-109.broadband.corbina.ru) |
| 17:58.01 | *** join/#qi-hardware liuqi (~liuqi@159.226.43.42) |
| 17:58.01 | *** join/#qi-hardware kanzure (~kanzure@131.252.130.248) |
| 18:18.42 | *** join/#qi-hardware zear (~zear@h196n1-g-kt-a31.ias.bredband.telia.com) |
| 18:21.54 | *** join/#qi-hardware kristoffer (~kristoffe@c-59dae555.010-30-6c6b7012.cust.bredbandsbolaget.se) |
| 18:26.44 | viric | wpwrak: they are still split and gnu updating from the .com. I think the gnu release only changes some docs and source code comments. |
| 18:31.20 | wpwrak | ah :) didn't hear of the non-gnu one for at least a decade :) |
| 18:35.12 | viric | the gnu one is the *lagged* |
| 18:36.31 | whitequark | wasn't it called "GPL Ghostscript"? |
| 18:48.10 | wpwrak | could be |
| 18:48.36 | *** join/#qi-hardware jekhor (~jek@leased-line-46-53-195-83.telecom.by) |
| 19:07.07 | *** join/#qi-hardware GNUtoo|laptop (~gnutoo@90.84.146.218) |
| 19:47.31 | *** join/#qi-hardware guanucoluis (~luis@2001:470:e450:0:225:56ff:fea1:2064) |
| 19:58.26 | *** join/#qi-hardware freakazoid0223 (~matt@pool-71-246-26-142.phlapa.fios.verizon.net) |
| 20:24.00 | *** join/#qi-hardware antgreen (user@nat/redhat/x-bnylhksdesobzajf) |
| 20:56.09 | *** join/#qi-hardware wej (~j@95.211.10.3) |
| 21:11.49 | *** join/#qi-hardware guanucoluis1 (~luis@2001:470:e450:0:225:56ff:fea1:2064) |
| 22:32.33 | *** join/#qi-hardware GeorgeH (~George@c-69-141-105-145.hsd1.nj.comcast.net) |
| 23:24.42 | *** join/#qi-hardware losinggeneration (~quassel@75-162-52-158.desm.qwest.net) |
| 23:44.49 | *** join/#qi-hardware xiangfu (~xiangfu@123.114.248.14) |
| 23:58.42 | *** join/#qi-hardware jow_laptop (~jow@ffx.subsignal.org) |