| *** tpb has joined #timvideos | 00:00 | |
| *** mparuszewski has quit IRC | 01:01 | |
| *** puck has quit IRC | 01:02 | |
| mithro | morning people | 03:00 |
|---|---|---|
| aps-sids | morning mithro | 03:03 |
| tija | Can anybody help me out with frame rates? If I am using my laptop as hdmi source, how can I know the frame rate of the video streaming from my laptop? | 04:04 |
| shenki | tija: hello | 04:58 |
| shenki | tija: i didn't hear from you for our vc? | 04:58 |
| shenki | tija: re: framerate, have you considered measuring it on the fpga? | 05:00 |
| shenki | you could have a counter that is exposed via the serial port comms | 05:00 |
| *** xfxf has joined #timvideos | 05:04 | |
| tija | shenki: wait for 2 mins. a blog post is coming | 05:11 |
| shenki | tija: ok | 05:11 |
| tija | shenki: Have you read my previos blog? | 05:12 |
| shenki | yep | 05:12 |
| shenki | I think you're converging on answering the correct questions | 05:12 |
| shenki | the same goes for your methadology; getting down to testing different parts in isolation is a good way to solve the problem | 05:13 |
| tija | shenki: another blog post. Read it and then we can have a VC | 05:14 |
| shenki | tija: ok. do you mind if we just chat? i'm sick | 05:14 |
| tija | shenki: it answers a lot of question | 05:14 |
| tija | shenki: no problem | 05:14 |
| shenki | tija: hrm, interesting | 05:17 |
| shenki | tija: my brain is working slowly today. can you explain to me where the frames are being dropped? | 05:19 |
| shenki | do we skip reading in frames from the HDMI source into our DDR? | 05:19 |
| tija | shenki: After a frame is read into DDR, it is send for processing. The next frame is read only when processing is complete which means all the frames in between were dropped. | 05:21 |
| shenki | cool | 05:22 |
| shenki | that's how i understood it too | 05:22 |
| tija | shenki: At 60Hz it means two frames | 05:22 |
| tija | are dropped | 05:22 |
| shenki | tija: so what if we have multiple buffers in the DDR? | 05:22 |
| shenki | one for the current frame, and one for the next? | 05:22 |
| shenki | writing a frame takes longer than processing it, so we should be able to keep up | 05:22 |
| tija | "one for the current frame, and one for the next?" I didn't get you | 05:23 |
| shenki | have two input frames buffered | 05:24 |
| shenki | n, and n+1 | 05:24 |
| shenki | while we are procesing n, n+1 is written | 05:24 |
| shenki | when we have processed (encoded) n, we start processing n+1 while n is filled with frame n+3 | 05:24 |
| tija | ddr2 does not allow simulatneous read and write | 05:24 |
| shenki | err, s/n+3/n+2/ | 05:24 |
| shenki | a question I had from yesterdays blog post: you said that we cannot read and write from the DDR. Isn't our memory controller multi-ported? | 05:24 |
| tija | Yes they are but one port can be written at a time. | 05:25 |
| tija | *written/read at a time | 05:25 |
| shenki | that's seems strange; it defeats the purpose of having a multi-ported controller | 05:26 |
| tija | the way it works is that if you have two ports to read from you send a command to the command fifo and the arbiter then reads them one by one | 05:27 |
| mithro | tija: I want to talk to you/shenki and get a better idea on where we are at. However I really need to finish some other stuff before I can do that | 05:29 |
| shenki | mithro: sure | 05:30 |
| tija | mithro: sure, meanwhile you can read my latest blog post. I think I have figured out the reason for difference in frame rates for different encoding quality. | 05:30 |
| mithro | I agree with shenki is that we should put frame counters into each part of the system and then have a way to report them via the serial port | 05:31 |
| shenki | tija: right, but i would imagine the latency of the bus would be reduced if we had a seperate read/write bus | 05:31 |
| mithro | some information about other things like byte throughput would be useful too | 05:31 |
| shenki | even if the actual controller cannot issue simultanious read/write commands | 05:31 |
| shenki | tija: okay, so from where | 05:36 |
| shenki | tija: okay, so from here | 05:36 |
| shenki | tija: where do you think we should go? | 05:36 |
| shenki | tija: i would suggest we add a few counters to the design; count each full frame that ends up in DDR from the HDMI, count each frame that is output by the JPEG decoder | 05:37 |
| shenki | tija: these counters then need to be made accessable. I suggest reporting them via the usb-cdc serial device on the fx2 | 05:37 |
| tija | shenki: to improve the frame rate one of the two thing has to be done. Either reduce the processing time or reduce the write time. | 05:38 |
| shenki | i agree. but first you need to confirm your suspicions | 05:39 |
| shenki | with real numbers from the design | 05:39 |
| shenki | not so much because we don't understand your explaination, but because you need to be able to show the effects that changes have as you improve the frame rate | 05:40 |
| tija | What ever is input in DDR is processed by encoder and sent to usb. I don't get why we need counter? | 05:40 |
| mithro | shenki: I'd like things like bytes/bits too | 05:40 |
| shenki | mithro: yep | 05:40 |
| shenki | tija: right, but if it was that straight forward then we wouldn't be here working on improving the frame rate | 05:41 |
| shenki | tija: it's a matter of confirming your analysis from today's blog post | 05:42 |
| tija | shenki: The state machine works that way. I am not making it up :D | 05:42 |
| shenki | think of it the same way as a science experiment (because it is!): you come up with a hypothesis, and then test it through observation | 05:43 |
| shenki | tija: yeah, i'm not debating weather or not the state machine works. what i'm suggesting is that we need to know exact numbers, from a real-life situation | 05:43 |
| shenki | we want to confirm your 17ms number, as well as the 25ms | 05:44 |
| mithro | tija: You never know what strange things the Xilinx compiler might be doing to your code, or the real world hardware, or any other part of the system | 05:45 |
| mithro | tija: or is if something else in the system is adversly effecting this part | 05:46 |
| mithro | tija: A good Engineer / Computer Scientist confirms things with real world, repeatable, *data* | 05:47 |
| tija | fine then, I guess then I need to get the UART working on linux. | 05:47 |
| mithro | tija: It's the same way if you find a bug, you should write a test which confirms the bug before you try and fix it. | 05:48 |
| shenki | tija: we already have a working uart | 05:48 |
| shenki | tija: it is exposed via the fx2 | 05:49 |
| shenki | also, i fixed the driver for the other UART so it works now | 05:49 |
| *** Palash has joined #timvideos | 05:50 | |
| tija | shenki: oh then its all good. Rohit was using my UART for debugging in windows and he reported the code is working fine. | 05:51 |
| shenki | excellent | 05:51 |
| shenki | i can't remember if i tested it - but i did find a heap more changes to make to the driver to have it work with newer kernels | 05:51 |
| mithro | ayush3504: ping me when you are about | 05:57 |
| tija | shenki: okay. So I will test the UART and then validate the data. Also I guess we have to find an optimum encoding quality 'cause 100% encoding quality is too much for fx2's bandwidth | 05:58 |
| mithro | tija / shenki: I think we need to rationalize (and actually design) the debugging / serial / etc infrastructure inside the firmware | 05:59 |
| shenki | tija: yeah, i think once we have all of these numbers we can start making educated decisions about things like the quality | 06:01 |
| ayush3504 | mithro: ping | 06:01 |
| shenki | tija: once you have the numbers coming out, do a blog post with them, and we can decide the next task to attack | 06:02 |
| shenki | tija: how long do you estimate it will take? | 06:02 |
| mithro | ayush3504: once shenki / tija are finished discussing stuff can you update me on your current status, where we are at, anything you need help with, etc. I'll reply as soon as I can. | 06:03 |
| ayush3504 | mithro: ok | 06:03 |
| tija | shenki: should not take long. | 06:05 |
| tija | 1-2 days maybe. | 06:07 |
| shenki | tija: okay, so lets say end of Wednesday? | 06:07 |
| tija | shenki:okay | 06:07 |
| mithro | tija / shenki: Would it be useful to have a shared Google Doc to do some "Design" in this area? | 06:07 |
| tija | mithro: are you talking about debugging design? | 06:10 |
| shenki | tija: yeah, i think he is | 06:11 |
| shenki | tija: i think a simple block diagram of the different parts | 06:11 |
| shenki | input, DDR, encoder, USB | 06:12 |
| shenki | and indicate where the counters will be, what they are counting | 06:12 |
| shenki | and where they are exposed | 06:12 |
| tija | shenki: okay I got the idea | 06:14 |
| ayush3504 | mithro: got the motherboard schematics ready, figured out auto-detection, doing the daughterboards. | 06:20 |
| *** slomo has joined #timvideos | 06:26 | |
| *** tija has quit IRC | 07:19 | |
| *** rohitksingh has joined #timvideos | 09:40 | |
| *** rohitksingh has quit IRC | 10:28 | |
| mithro | ayush3504: okay - I'm around now | 11:34 |
| mithro | bah, both ajit and rohitksingh are not about | 11:38 |
| shenki | ajit works strange hours (for someone in his timezone) as he doesn't have reliable power during the day | 12:21 |
| mithro | shenki: I was pondering the writing into DDR | 12:34 |
| mithro | shenki: any idea what width our DDR is? 1 byte? | 12:35 |
| shenki | doubtful | 12:43 |
| shenki | i would imagine 32bit | 12:43 |
| shenki | usually you can also do burst transfers of 64 or more | 12:43 |
| shenki | but it's more involved to interface with | 12:43 |
| shenki | i assume that HDMI is a continual stream of pixels? | 12:44 |
| shenki | or does it send a frame as fast as it can, and then wait to send the next one? | 12:44 |
| mithro | shenki: you get a full set of pixel data per clock | 12:46 |
| mithro | shenki: no HDMI is source synchronous | 12:46 |
| shenki | a full set of pixel data? | 12:46 |
| shenki | that's one frame? | 12:46 |
| shenki | "frame" | 12:47 |
| mithro | no, as in the full RBG (or other format) values for a pixel | 12:47 |
| mithro | actually that might be wrong | 12:47 |
| mithro | http://en.wikipedia.org/wiki/Digital_Visual_Interface | 12:48 |
| tpb | Title: Digital Visual Interface - Wikipedia, the free encyclopedia (at en.wikipedia.org) | 12:48 |
| mithro | Thinking about the values at a pixel level is probably the right level | 12:48 |
| mithro | According to wikipedia, you get "1 pixel per clock cycle" | 12:49 |
| mithro | 24 bits per pixel support is mandatory in all resolutions supported. | 12:49 |
| mithro | Less than 24 bits per pixel is optional.. | 12:49 |
| mithro | The DVI data channel operates at a bit-rate that is 10 times the frequency of the clock signal. In other words, in each DVI clock period there is a 10 bit symbol per channel. The set of three 10 bit symbols represents one complete pixel in single link mode and can represent either one or two complete pixels as a set of six 10 bit symbols in dual link mode. | 12:50 |
| mithro | I assume you'd had a pixel buffer in the VHDL, the HDMI -> pixel buffer -> DDR | 12:51 |
| mithro | I'd think the DDR should be much faster than the HDMI, so the pixel buffer is going to be mostly empty? | 12:52 |
| mithro | and the DDR is probably going to be doing nothing a lot of the time | 12:52 |
| *** Palash has quit IRC | 12:53 | |
| *** tvCommitBot has joined #timvideos | 13:02 | |
| tvCommitBot | [HDMI2USB-vmodvga] none pushed 3 new commits to master: http://git.io/y4Yv8w | 13:02 |
| tvCommitBot | HDMI2USB-vmodvga/master 059816d Jahanzeb Ahmad: PDF files updated. | 13:02 |
| tvCommitBot | HDMI2USB-vmodvga/master e08deca Tim 'mithro' Ansell: Renaming the README file and adding symlink. | 13:02 |
| tvCommitBot | HDMI2USB-vmodvga/master e2c2dd8 Tim 'mithro' Ansell: Adding a LICENSE file. | 13:02 |
| *** tvCommitBot has left #timvideos | 13:02 | |
| *** tvCommitBot has joined #timvideos | 13:03 | |
| tvCommitBot | [HDMI2USB-vmodserial] none pushed 3 new commits to master: http://git.io/BH_5eQ | 13:03 |
| tvCommitBot | HDMI2USB-vmodserial/master e5c304b ayushsagar: Added ISL83387E, deleted discarded daughterboard.sch | 13:03 |
| tvCommitBot | HDMI2USB-vmodserial/master ca638c3 ayushsagar: Changed project name Main to Motherboard to avoid confusion with independent daughterboard projects to be created | 13:03 |
| tvCommitBot | HDMI2USB-vmodserial/master c5da82b ayushsagar: Fixed major flaw in autodetection circuit - daughterboard header pinout changed to set address of ROMs depending on slot | 13:03 |
| *** tvCommitBot has left #timvideos | 13:03 | |
| *** FeltonChris has quit IRC | 13:10 | |
| shenki | spamy spam spam | 13:21 |
| shenki | mithro: ok | 13:21 |
| shenki | mithro: yes, the DDR shouldn't take long | 13:21 |
| *** rohitksingh has joined #timvideos | 13:21 | |
| shenki | mithro: my understanding was that it clocks in the entire frame before starting to encode | 13:22 |
| mithro | shenki: 128Mbyte DDR2 16-bit wide data | 13:22 |
| shenki | that's the chip? i don't think that describes the bus we're talking to on | 13:22 |
| mithro | shenki: The whole point of using the DDR ram was to not store large amounts of pixels on the FPGA. | 13:23 |
| shenki | the FPGA has a memory interface that i assume we're connecting to a AXI or simialr | 13:23 |
| shenki | well, i think that's the design you've paid for ;) | 13:23 |
| mithro | AXI? | 13:23 |
| mithro | Many Spartan-6's have dedicated memory controller I/O blocks | 13:24 |
| shenki | yeah, you have a memory controller that is part hardware part software | 13:24 |
| shenki | that sits between the DDR and the fabric | 13:24 |
| shenki | and on the fabric you connect your IP to ports on the controller | 13:24 |
| shenki | AXI is a modern bus standardised by ARM | 13:25 |
| mithro | A single 1Gbit DDR2 memory chip is driven from the memory controller block in the Spartan-6 FGPA. Previous versions of the Atlys were loaded with a Micron MT47H64M16-25E DDR2 component, however, newly manufactured Atlys boards now carry an MIRA P3R1GE3EGF G8E DDR2 component. The datasheet for the MIRA device can be found be performing an internet search for | 13:25 |
| mithro | P3R1GE3JGF, which is an equivalent part. Both of these chips provide a 16-bit data bus and 64M locations and have been tested for DDR2 operation at up to an 800MHz data rate. | 13:25 |
| shenki | right, that's the DDR specs. that doesn't tell us about the memory interface in the FPGA | 13:25 |
| mithro | From a bandwidth point of view, that would be 16-bit * 800MHz * 2(DDR) - or 3.2 gigabit/s | 13:27 |
| shenki | i doubt our system can run at 800MHz | 13:27 |
| mithro | shenki: my bet is we are using the memory controller code Xilinx provides | 13:28 |
| shenki | yes, we are | 13:28 |
| shenki | the MIG controll | 13:28 |
| shenki | er | 13:28 |
| shenki | memory interface generator | 13:28 |
| mithro | looking at the docs that are in ipcore_dir/ddr2ram/docs | 13:29 |
| mithro | They say a peak bandwidth of 12.8 Gb/s is possible with 16-Bit wide interface | 13:30 |
| mithro | ipcore_dir/ddr2ram/user_design/datasheet.txt seems to contain the details on the interface we asked to be generated.... | 13:32 |
| shenki | yep | 13:34 |
| shenki | we have one read port and one write port | 13:34 |
| mithro | shenki: I just figured out the Atlys jumpers :P | 13:36 |
| shenki | mithro: yeah? anything interesting? | 13:36 |
| mithro | shenki: https://github.com/timvideos/HDMI2USB/wiki/Digilent-Atlys-Board:-Loading-Firmware/_compare/dd0fd8e5065ffa85ca784b3c1661c9777d60a09a...ff5f0b0aa33e620e507528c2e0bfb5ed744d51cc | 13:42 |
| tpb | Title: Compare Revisions · timvideos/HDMI2USB Wiki · GitHub (at github.com) | 13:42 |
| shenki | ah, so just EDID | 13:56 |
| shenki | that's probably why no one has cared a whole heap | 13:56 |
| mithro | shenki: yeah, but also might be why people are getting different / unreliable EDID detection | 13:59 |
| mithro | shenki: if our firmware is thinking it has control over the EDID and hence stomping on the other signals, etc | 13:59 |
| mithro | CarlFK: please check out the jumper instructions! It might help with the deteciton issue | 14:00 |
| mithro | shenki: Could you take a look over this document -> https://docs.google.com/document/d/1-E4SGuPz4Wjqs2BP9ck8GL6wrxWUUAnE6lsq7E3uBgE/edit and add some comments? | 14:05 |
| tpb | Title: I2C VHDL Cores & their comparison - Google Docs (at docs.google.com) | 14:05 |
| shenki | mithro: yep | 14:06 |
| shenki | mithro: what kind of feedback? spelling/grammar? or just overall? | 14:06 |
| shenki | shall i edit it? | 14:06 |
| mithro | shenki: I don't think you have edit permissions? | 14:06 |
| mithro | shenki: more on your expert opinon on the I2C controllers and the analysis | 14:07 |
| mithro | shenki: IE what have they missed? | 14:07 |
| shenki | ah | 14:07 |
| mithro | hey rohitksingh! When did you sneak in? | 14:07 |
| shenki | "expert" hah | 14:07 |
| rohitksingh | mithro: around 1 hour before :) | 14:08 |
| shenki | hrm | 14:09 |
| shenki | "using about the same FPGA resources as a Picoblaze processor." | 14:09 |
| shenki | except we program the picoblaze in c | 14:10 |
| shenki | ah, im confusing picoblaze with microblaze | 14:10 |
| rohitksingh | shenki: the I3C2 has a custom assembler which translates the assembly code to VHDL | 14:11 |
| CarlFK | mithro: URL | 14:11 |
| shenki | hrm. my gut reaction is that these things introduce extra complexity into our system, and we would be better off implementing it in HDL | 14:11 |
| mithro | See above | 14:11 |
| shenki | what is the i2c controller going to be doing? | 14:12 |
| shenki | is it just EDID? | 14:12 |
| shenki | oh, nvm. | 14:12 |
| shenki | the AD9984A VGA capture chip uses I2C interface for initialization, configuration and current status monitoring | 14:12 |
| shenki | so we need to init/config the ADC | 14:12 |
| mithro | shenki: yeah | 14:12 |
| CarlFK | mithro: ah, I was expecting an image. jp2 6 7 .. got it. | 14:13 |
| shenki | if we didn't already have the EDID stuff there, i would suggest this is worth looking ito | 14:13 |
| shenki | s/ito/into/ | 14:13 |
| mithro | CarlFK: an image would be awesome! :P | 14:13 |
| rohitksingh | shenkiL yes for AD9984A init | 14:13 |
| shenki | but i think it would be more straight forward to code the hdl to init the ADC | 14:13 |
| shenki | as introducing a new system... now you have two problems | 14:13 |
| mithro | shenki: it also looked like we'll need an I2C controller for the expansion board auto-detection :P | 14:13 |
| mithro | shenki: your thoughts on https://docs.google.com/a/mithis.com/document/d/1ZhDz50rve5UmnmyKynxySLHqfFuOwBPM7pYFoHo9uvs/edit#heading=h.n1bsm4u66s8i would be good too | 14:14 |
| tpb | Title: Guidelines for Auto-Detection compliant Expansion Board - Google Docs (at docs.google.com) | 14:14 |
| rohitksingh | shenki: then the second core is more suited for that..just one-off init | 14:14 |
| shenki | rohitksingh: one-off init is well suited to coding in HDL, from my perspective :) | 14:14 |
| shenki | our system is rapidly bloating | 14:14 |
| shenki | so yeah, those i2c controllers look cool. they both have decent looking websites | 14:16 |
| rohitksingh | shenki: yeah...but if we decide on adding a I2C based auto-detection, then I think we would need some more powerful controller | 14:16 |
| CarlFK | can someone write scripts to do https://github.com/timvideos/HDMI2USB/wiki/libFPGALink ( and personally I would not use udev for dev/testing at this point) | 14:16 |
| tpb | Title: libFPGALink · timvideos/HDMI2USB Wiki · GitHub (at github.com) | 14:16 |
| mithro | CarlFK: that comments makes no-sense | 14:16 |
| CarlFK | https://github.com/timvideos/HDMI2USB/wiki/Firmware-load-scripts I think those were right at some point | 14:16 |
| tpb | Title: Firmware load scripts · timvideos/HDMI2USB Wiki · GitHub (at github.com) | 14:17 |
| mithro | CarlFK: those still use udev | 14:17 |
| mithro | wget http://www.digilentinc.com/Data/Products/ADEPT2/digilent.adept.runtime_2.15.3-x86_64.tar.gz <-- installing that installs udev rules | 14:17 |
| shenki | rohitksingh: hrm. it's still just a state machine. it would detect what the board is, and start clocking the correct periperhal lines into the IP that talks to it | 14:17 |
| CarlFK | mithro: udev is to run things when usb events happen, right? | 14:17 |
| shenki | rohitksingh: i'm not against the i2c as an idea, it's more in the context of our entire system, and the complexity it adds for maintainance, testing, etc | 14:18 |
| mithro | CarlFK: yeah, those udev rules are just to make sure the device nodes in /dev/XXXX have permissions that allow people to access them | 14:18 |
| * shenki doesnt use the udev scripts. sudo make-me-a-sandwich | 14:18 | |
| rohitksingh | shenki: yeah...valid point! | 14:18 |
| mithro | I think we already have some type of minimal controller in the design which takes the input from the CDC serial input and acts on it | 14:18 |
| shenki | rohitksingh: are you looking at the i2c controller as you want to do less HDL, or is there another motivation for using it? | 14:19 |
| shenki | sorry, i have to go to bed. recovering from a cold. i'll read scrollback in 8 hours or so :) | 14:20 |
| CarlFK | i don't have time today to translate docs into a script, but if someone else does I'll be happy to run the script. so whatever is needed to run, put it in the script. | 14:20 |
| rohitksingh | shenki: i wanted greater flexibility. But for AD9984A init, i can directly integrate the init code to the project | 14:20 |
| rohitksingh | shenki: okay...have a nice sleep! :) | 14:20 |
| rohitksingh | shenki: for example using a flexible core, the user can dynamically adjust the brightness and contrast settings for AD9984A instead of Auto-Adjustment.. | 14:23 |
| mithro | rohitksingh: did you see my email about enabling the github issues? | 14:26 |
| rohitksingh | yeah...will do it right now | 14:28 |
| rohitksingh | mithro: done | 14:31 |
| mithro | rohitksingh: added a heap of issues to your repositories | 14:48 |
| rohitksingh | mithro: yeah! resolving them one by one! :) | 14:50 |
| mithro | rohitksingh: great! | 14:51 |
| mithro | rohitksingh: sent you another email too | 14:51 |
| rohitksingh | mithro: got that! I'll merge that | 15:00 |
| mithro | well, I should have been in bed 1.5 hours ago | 15:19 |
| mithro | rohitksingh: talk to you tomorrow! | 15:19 |
| mithro | rohitksingh: I have some ideas on how to do testing | 15:19 |
| rohitksingh | mithro: Sure! Eager to learn! :) | 15:21 |
| rohitksingh | mithro: have a nice sleep! | 15:21 |
| *** mparuszewski has joined #timvideos | 15:50 | |
| *** Palash has joined #timvideos | 15:53 | |
| ayush3504 | mithro: sorry, went asleep | 16:03 |
| *** CarlFK has quit IRC | 16:12 | |
| *** sarwarc has joined #timvideos | 16:38 | |
| *** CarlFK has joined #timvideos | 17:24 | |
| *** ChanServ sets mode: +v CarlFK | 17:24 | |
| *** rohitksingh1 has joined #timvideos | 18:27 | |
| *** rohitksingh has quit IRC | 18:29 | |
| *** slomo_ has joined #timvideos | 19:02 | |
| *** slomo has quit IRC | 19:03 | |
| *** slomo__ has joined #timvideos | 20:01 | |
| *** slomo_ has quit IRC | 20:04 | |
| *** tija has joined #timvideos | 20:18 | |
| *** techdragon has quit IRC | 20:40 | |
| *** Joelw has quit IRC | 20:40 | |
| *** Palash has quit IRC | 21:01 | |
| *** Joelw has joined #timvideos | 21:04 | |
| *** techdragon has joined #timvideos | 21:04 | |
| *** slomo__ has quit IRC | 21:31 | |
| *** CarlFK has quit IRC | 22:23 | |
| *** rohitksingh1 has quit IRC | 22:35 | |
| *** sarwarc has quit IRC | 23:30 | |
| *** FeltonChris has joined #timvideos | 23:47 | |
Generated by irclog2html.py 2.12.1 by Marius Gedminas - find it at mg.pov.lt!