| *** tpb has joined #timvideos | 00:00 | |
| mithro | nueces: there are better / updated (but unfinished) ones at 10:55 PM <@ mithro> https://github.com/mithro/HDMI2USB-misoc-firmware/tree/docs-scripts-update/scripts | 00:20 |
|---|---|---|
| tpb | Title: HDMI2USB-misoc-firmware/scripts at docs-scripts-update · mithro/HDMI2USB-misoc-firmware · GitHub (at github.com) | 00:20 |
| nueces | mithro, thanks | 00:20 |
| nueces | I get this output after enable the debug input0 | 00:42 |
| nueces | http://dpaste.com/1GBPDMH | 00:42 |
| tpb | Title: dpaste: 1GBPDMH (at dpaste.com) | 00:42 |
| nueces | and this when I do a make view http://dpaste.com/2997DG0 | 00:43 |
| tpb | Title: dpaste: 2997DG0 (at dpaste.com) | 00:43 |
| nueces | dmesg http://dpaste.com/1KKJ3MA | 00:47 |
| tpb | Title: dpaste: 1KKJ3MA (at dpaste.com) | 00:47 |
| mithro | hey nueces, sorry was still getting up | 01:28 |
| mithro | nueces: the failure to set the probe control is normal | 01:30 |
| mithro | nueces: Do you have the serial console open when you did a "make view" there is a known bug which causes the first viewing attempt to fail if the serial console is open | 01:31 |
| *** aom_ has joined #timvideos | 01:37 | |
| nueces | mithro, yes, but I try several times, when the console closed I get this http://img.ctrlv.in/img/16/07/04/5779bdaab6212.png | 01:40 |
| nueces | http://dpaste.com/1A9ZS2R this is the make view output | 01:42 |
| tpb | Title: dpaste: 1A9ZS2R (at dpaste.com) | 01:42 |
| mithro | Nobody is using the device at res:720x480 at the moment | 01:45 |
| mithro | nueces: What type of output source are you using? | 01:46 |
| nueces | http://dpaste.com/23ZSHTP | 01:47 |
| tpb | Title: dpaste: 23ZSHTP (at dpaste.com) | 01:47 |
| nueces | I connect the camera recording a 720@60fps | 01:47 |
| nueces | there is a way to set the input resolution? | 01:48 |
| mithro | nueces: the camera is outputting 720x480 which isn't 720p60 (which would be 1280x720) | 01:48 |
| nueces | the camera manual specified when it is connect to an HDTV | 02:14 |
| nueces | :/ | 02:14 |
| nueces | sorry | 02:15 |
| nueces | I set the output in auto mode, that should work as the manual say in the same format as the video is recorded | 02:16 |
| CarlFK | nueces: what camera? | 02:17 |
| nueces | samsung hmx q20 | 02:17 |
| mithro | nueces: You can set the mode the HDMI2USB advertises as being supported | 02:18 |
| mithro | nueces: Try setting that to a value and then unplug/replug the camera | 02:18 |
| nueces | I did that, but still don't work | 02:21 |
| nueces | sorry, could you explain in more details what you say about set the mode? | 02:22 |
| nueces | how i could do that? | 02:24 |
| mithro | nueces: on the serial console, I think the command is "video_mode <number>" help should tell you | 02:29 |
| nueces | i did that, but only change the output values | 02:30 |
| mithro | nueces: after changing the mode, you may need to change plug/unplug the camera for it to pick it up? | 02:31 |
| nueces | http://dpaste.com/3E8CVJB | 02:32 |
| tpb | Title: dpaste: 3E8CVJB (at dpaste.com) | 02:32 |
| mithro | nueces: yeah, it looks like your camera isn't outputting 720p | 02:33 |
| nueces | :/ | 02:34 |
| mithro | nueces: can you try plugging your camera into a monitor/TV and see what resolution that detects? | 02:36 |
| mithro | nueces: your camera might be confused by the HDMI2USB edid and just falling back to the "default" resolution.... | 02:36 |
| nueces | I don't have a tv at home. But tomorrow I going to try that | 02:38 |
| CarlFK | nueces: can you find me the manual on line? I dont see it at http://www.samsung.com | 02:38 |
| tpb | Title: Electronics & Appliances: Tablets, Smartphones, TVs | Samsung US (at www.samsung.com) | 02:38 |
| CarlFK | I did find http://www.bhphotovideo.com/c/product/838573-REG/Samsung_HMX_Q20BN_XAA_HMX_Q20_HD_Flash_Camcorder.html | 02:38 |
| tpb | Title: Samsung HMX-Q20 HD Flash Camcorder (Black) HMX-Q20BN/XAA B (at www.bhphotovideo.com) | 02:38 |
| CarlFK | Video Format 1280 x 720p / 60 fps | 02:39 |
| CarlFK | so that's encouraging | 02:39 |
| nueces | CarlFK, http://static.highspeedbackbone.net/pdf/Samsung%20HMX-Q20%20Series%20Manual.pdf | 02:39 |
| CarlFK | nueces: p 101, Set the video resolution. HD 720/60p ( ): Records in the HD (1280x720/60p) format. | 02:41 |
| CarlFK | did you do that? | 02:41 |
| nueces | I trying playing a video recorder in the camera, but with the same result | 02:41 |
| nueces | yes | 02:41 |
| CarlFK | hmm, can you transfer a video file to your computer? | 02:42 |
| nueces | yes, | 02:43 |
| nueces | when I'm playing a video from the camera and set in the console the video_mode 9 the camera stop playing and after a moment start again | 02:47 |
| CarlFK | I hope you have a linux box... | 02:47 |
| CarlFK | $ mediainfo --Inform="Video;%Height%" 09_07_10.ts | 02:47 |
| CarlFK | 720 | 02:47 |
| CarlFK | can you do 'that' / | 02:48 |
| CarlFK | ? | 02:48 |
| nueces | in the console i did a status and the input was first at 720x480, later empty and finally 720x480 again | 02:48 |
| nueces | mediainfo --Inform="Video;%Height%" HDV_0229.MP4 | 02:49 |
| nueces | 720 | 02:49 |
| CarlFK | well thats encouraging | 02:49 |
| mithro | nueces: how did you get a .MP4? | 02:50 |
| nueces | mithro, i connect the camera as usb mass storage | 02:50 |
| CarlFK | mediainfo HDV_0229.MP4 will dump all sorts of fun stuff.. but 720 is all that matters | 02:50 |
| nueces | http://dpaste.com/36AGBKK | 02:51 |
| tpb | Title: dpaste: 36AGBKK (at dpaste.com) | 02:51 |
| mithro | nueces: at the moment we only support RGB video, it might be the case that you need YUV 4:2:0 support for it to output 720p - but really everything is just guessing until you can confirm that the camera outputs 720p with something other than the HDMI2USB | 02:53 |
| nueces | mithro, ok. I will do that tomorrow | 02:54 |
| CarlFK | well.. if you hook it to a display that supports 1080, I bet the camera is going to send 1080 | 02:55 |
| CarlFK | hmm. maybe. I have a camera here that I think behaves like that... | 02:55 |
| mithro | CarlFK: if the camera only supports 720x480 output, then it will always output that resolution | 02:56 |
| mithro | I know some older/cheap cameras can't output full resolution while still being able to record at it | 02:57 |
| CarlFK | HDMI TV Out Auto*: The video signals are output in the same format as the recorded file. | 02:58 |
| CarlFK | that should be 720 | 02:58 |
| nueces | there is a way to debug the negotiation that the camera do with the board when the camera is connected? | 03:05 |
| nueces | DMI2USB>debug edid | 03:05 |
| nueces | port has no EDID capabilities | 03:05 |
| *** sb0 has quit IRC | 03:13 | |
| CarlFK | k, I have a similar setup now | 03:23 |
| nueces | :) | 03:23 |
| CarlFK | nueces: debug edid is for a display device plugged into the output (I think) | 03:23 |
| nueces | ok | 03:24 |
| CarlFK | also, you may be able to just type s to get status | 03:24 |
| CarlFK | (depends on your firmware version) | 03:24 |
| nueces | yes, I did the firmware upgrade, but it is not permanent, when i unplug the power cord from the board it loose the changes | 03:26 |
| mithro | CarlFK: you seen http://konopas.org/ before? | 03:27 |
| tpb | Title: KonOpas (at konopas.org) | 03:27 |
| CarlFK | mithro: no.. let me guess, another format of data for me to consume ? | 03:28 |
| mithro | CarlFK: they are a format consumer | 03:28 |
| CarlFK | um.. so why do I want to look at this ? | 03:29 |
| mithro | CarlFK: because they have a "specification for the data formats" - probably terrible but worth 2 minutes poking around | 03:31 |
| nueces | thanks for the help o/ | 03:31 |
| nueces | bye | 03:31 |
| mithro | nueces: Talk to you later in the week I assume | 03:31 |
| nueces | Ok, thanks again for all the work | 03:32 |
| CarlFK | mithro: I have a camera hooked up to an atlys. I don't ever expect to use it but if you want to look into debugging things | 03:32 |
| CarlFK | like: | 03:32 |
| CarlFK | HDMI2USB>m 11 | 03:32 |
| CarlFK | Setting video mode to 1920x1080 @29Hz | 03:32 |
| CarlFK | HDMI2USB>s | 03:32 |
| CarlFK | input0: 720x480 | 03:32 |
| mithro | 720x480 is likely to be interlaced too - which we *definately* don't support yet | 03:36 |
| mithro | CarlFK: what does the camera do when you hook it up to a TV/Monitor? | 03:36 |
| CarlFK | mithro: monitor says 480p | 03:39 |
| CarlFK | I was expecting 1080i | 03:39 |
| mithro | Sounds like your camera is outputting 480p then? | 03:39 |
| CarlFK | yep. fiddled with options, not monitor says 720p ... lets see if I can get the Atlys to see that | 03:41 |
| CarlFK | HDMI2USB>m 9 | 03:43 |
| CarlFK | Setting video mode to 1280x720 @60Hz | 03:43 |
| CarlFK | HDMI2USB>s | 03:43 |
| CarlFK | input0: 720x480 | 03:43 |
| CarlFK | going back to lcd... | 03:43 |
| mithro | It sounds like 480p is the fallback option? | 03:44 |
| CarlFK | well, plugged into lcd, it shows 720p | 03:44 |
| CarlFK | so without changing anything on the cam, lcd shows 720p, atlys shows 480, lcd shows 720 | 03:44 |
| CarlFK | oh hell... | 03:45 |
| CarlFK | camera manual http://resources.jvc.com/Resources/00/01/53/15365.PDF Image quality ... there is no 720p options | 03:46 |
| CarlFK | im not sure why the lcd is showing 720... | 03:46 |
| mithro | CarlFK: what does the lcd actually show? Any more detail then just 720? | 03:46 |
| CarlFK | mithro: "720p 60Hz" | 03:47 |
| CarlFK | mithro: there is nothing in the manual about 720p options. I kinda think there isn't much point in poking at this more, but happy to if you think there is something to be learned | 03:54 |
| mithro | CarlFK: not at the moment | 03:54 |
| CarlFK | mithro: does this ask the source (cam) renegotiate ? hdp_toggle 0 | 03:56 |
| mithro | CarlFK: in theory, no guarentee it actually works | 03:56 |
| mithro | CarlFK: definitely doesn't work on the Atlys | 03:57 |
| mithro | (as the hpd pins are not connected) | 03:57 |
| *** nueces has quit IRC | 04:10 | |
| mithro | aom_: ping? | 04:13 |
| *** Bertl_zZ is now known as Bertl | 04:57 | |
| mithro | _florent_: ping? | 05:08 |
| *** sb0 has joined #timvideos | 05:13 | |
| *** sb0_ has joined #timvideos | 05:15 | |
| *** sb0 has quit IRC | 05:15 | |
| _florent_ | mithro: pong | 05:20 |
| mithro | _florent_: How goes things? | 05:20 |
| mithro | _florent_: I wanted to discuss finishing off the rebase/litedram stuff a little more if you have time | 05:22 |
| _florent_ | mithro: just sent you a mail | 05:22 |
| _florent_ | mithro: but no progress during the weekend here, I'm going to work a bit on it this morning | 05:23 |
| mithro | _florent_: yeah, I guessed you were only testing the opsis_video one | 05:24 |
| mithro | _florent_: Any idea how much work getting the encoder working again might be? | 05:25 |
| _florent_ | the encoder will be easy to get working | 05:26 |
| _florent_ | I don't think there is too much change here | 05:26 |
| _florent_ | maybe just around the DMA | 05:26 |
| _florent_ | but I arlready refactored it for the video framebuffer | 05:27 |
| mithro | _florent_: it currently fails because it's trying to import the lamsi dma stuff | 05:27 |
| _florent_ | yes possible | 05:27 |
| _florent_ | I'll look at that | 05:27 |
| mithro | _florent_: so, my plan for merging is that we get a minimal working version in your opsis-soc repo | 05:28 |
| _florent_ | yes | 05:28 |
| mithro | _florent_: I think do a "merge" of the opsis-soc repo into the HDMI2USB-misoc-repo's nextgen branch, replacing most of the existing stuff | 05:29 |
| mithro | s/think/then/ | 05:29 |
| _florent_ | yes, can we just wait a few days before that | 05:29 |
| mithro | _florent_: We then fix up the bits needed so that Atlys and miniSpartan6 work | 05:29 |
| _florent_ | I want to get opsis_video and opsis_hdmi2usb working before merging | 05:30 |
| mithro | _florent_: yes, prerequisite for starting the merging is a minimal "opsis_hdmi2usb" working in the opsis-soc repo | 05:31 |
| mithro | _florent_: Do you have Redmere cables for use with the Opsis? | 05:33 |
| mithro | _florent_: The inputs currently have issues which are helped by the amplifier in the Redmere cable | 05:34 |
| _florent_ | no I don't have the Redmere cables | 05:34 |
| mithro | _florent_: Properly investigating and understanding that problem is on the todo list once we finish this rework | 05:34 |
| mithro | _florent_: Should I ship you some? | 05:35 |
| _florent_ | and with current opsis_video gateware (refactoring), I only hdmi input 1 working, hdmi input 0 was not working | 05:35 |
| _florent_ | but I didn't investigate that much | 05:35 |
| mithro | _florent_: I assume you'll compare it to the existing firmware and see if you get the same behaviour | 05:36 |
| _florent_ | yes I'm going to do that | 05:36 |
| mithro | _florent_: but the HDMI inputs on the Opsis are more sensitive then the Atlys ones | 05:36 |
| *** ssk1328 has joined #timvideos | 05:36 | |
| _florent_ | then we'll see if I need Redmere cable or not | 05:36 |
| *** Bertl is now known as Bertl_oO | 05:36 | |
| mithro | Morning ssk1328 | 05:36 |
| ssk1328 | mithro: I just sent you a big fat mail. | 05:37 |
| mithro | ssk1328: Did you figure out how to set the target for quicker bit generation | 05:37 |
| ssk1328 | mithro: Morning! | 05:37 |
| mithro | ssk1328: yes, just about to read it | 05:37 |
| ssk1328 | mithro: Using base target it was taking about 8-9 minutes on my i7 with 8GB of RAM | 05:37 |
| mithro | ssk1328: Another option is to try using the "opsis-soc" at https://github.com/enjoy-digital/opsis-soc for the moment | 05:39 |
| tpb | Title: GitHub - enjoy-digital/opsis-soc: Opsis SoC based on LiteX (at github.com) | 05:39 |
| mithro | ssk1328: I'm unsure how long that will take to build (compared to the base target in the HDMI2USB-misoc-firmware) | 05:39 |
| shenki | mithro: what's the difference between the two? | 05:40 |
| mithro | shenki: opsis-soc is based of _florent_'s rewritten litedram and the newer litex (which has updated migen/misoc) | 05:40 |
| shenki | okay | 05:41 |
| mithro | shenki: It only supports the opsis though | 05:41 |
| shenki | so it will become HDMI2USB-misoc-firmware once it's finished? | 05:41 |
| *** sb0_ has quit IRC | 05:41 | |
| mithro | shenki: Pretty much | 05:41 |
| shenki | cool | 05:41 |
| mithro | _florent_: I think it's perfectly reasonable to leave out things like the SPI flash support and the FX2 I2C loading stuff until after we do the merging | 05:42 |
| mithro | ssk1328: My machine took real 5m15.962s for "opsis_minisoc" target in the opsis-soc repo, but my machine is probably a bit more powerful than your average | 05:44 |
| mithro | actually, we should look at the travis build times | 05:44 |
| mithro | BOARD=opsis TARGET=base seems to take between 6 and 10 minutes on Travis lately | 05:46 |
| ssk1328 | mithro: Okay. I might try this opsis_minisoc as well | 05:46 |
| ssk1328 | mithro: For now I figured out the problem though | 05:46 |
| mithro | ssk1328 / shenki: This is what I used to get me a "lite environment" - https://gist.github.com/mithro/604da515edc1061a77a8ee6c1fe729e6 | 05:47 |
| tpb | Title: Script to get all the enjoy-digital repos and set up a conda environment for using them in · GitHub (at gist.github.com) | 05:47 |
| shenki | mithro: so conda is just for a cross binutils, gcc, gdb? | 05:55 |
| mithro | shenki: It also provides a "Python virtualenv" like thing for installing python modules into | 05:56 |
| shenki | ok | 05:56 |
| mithro | shenki: also, all of migen/misoc/lite stuff is Python 3 and needs a recent version of that | 05:58 |
| mithro | shenki: conda provides a newer version of Python 3 | 06:01 |
| shenki | ok | 06:15 |
| *** CarlFK has quit IRC | 06:39 | |
| mithro | shenki: ping? I have a question about "volatile" meaning with pointers in C code..... | 06:47 |
| shenki | mithro: yup | 06:47 |
| mithro | shenki: https://github.com/timvideos/HDMI2USB-misoc-firmware/pull/266/files#r69414008 | 06:48 |
| tpb | Title: Added heartbeat functionality by ssk1328 · Pull Request #266 · timvideos/HDMI2USB-misoc-firmware · GitHub (at github.com) | 06:48 |
| *** CarlFK has joined #timvideos | 06:49 | |
| *** ChanServ sets mode: +v CarlFK | 06:49 | |
| mithro | ssk1328: Did you miss the pattern.{h,c} deliberately? | 06:49 |
| ssk1328 | mithro: I didn't get you? | 06:50 |
| shenki | mithro: it's saying the thing that is being pointed to will change | 06:50 |
| mithro | ssk1328: in the heartbeat pull request | 06:51 |
| mithro | shenki: so it should be read as a "pointer to a (volatile unsigned int)" ? | 06:51 |
| shenki | http://cdecl.ridiculousfish.com/?q=volatile+unsigned+int+*framebuffer | 06:51 |
| shenki | yes | 06:51 |
| shenki | declare framebuffer as pointer to volatile unsigned int | 06:51 |
| ssk1328 | I haven't made any changes in pattern.c/ pattern.h files if thats what you are asking? | 06:52 |
| mithro | ssk1328: https://github.com/timvideos/HDMI2USB-misoc-firmware/pull/266/files#diff-5a0393c8ed31103fa40d44bc7a05f3af | 06:52 |
| tpb | Title: Added heartbeat functionality by ssk1328 · Pull Request #266 · timvideos/HDMI2USB-misoc-firmware · GitHub (at github.com) | 06:52 |
| mithro | shenki: ahh, I'd forgotten about cdecl | 06:53 |
| mithro | shenki: thanks for the reminder! | 06:54 |
| shenki | :) | 06:54 |
| shenki | the pointer shouldn't be volatile | 06:54 |
| ssk1328 | mithro: I added a small change in pattern.h, this is for initializing framebuffers with some value, which is address to pattern base | 06:55 |
| *** panther has joined #timvideos | 06:55 | |
| ssk1328 | mithro: Hence, added PATTERN_FRAMEBUFFER_BASE to pattern.h | 06:55 |
| *** panther is now known as sab_123 | 06:56 | |
| mithro | shenki: hrm? | 06:56 |
| mithro | ssk1328: Ideally the change to pattern.h should probably be in a separate pull request as I think you are saying it makes sense even without your heartbeat change? | 06:57 |
| mithro | ssk1328: color_bar doesn't seem to be used anywhere? | 06:58 |
| ssk1328 | mithro: Not used. Correct. | 06:59 |
| shenki | ssk1328: can you explain why you made the 'framebuffer' pointer volatile? | 06:59 |
| mithro | ssk1328: hrm, I don't think the change to pattern.h is needed? | 06:59 |
| mithro | shenki: you mean, why the frame buffer is pointing to a volatile int? | 07:00 |
| shenki | mithro: yeah | 07:00 |
| ssk1328 | shenki: I don't think I have a very good answer for this, I wrote this code, building up on pattern.c, and pattern.c had used a similar definition for defining framebuffer | 07:02 |
| mithro | shenki: do you know why and want to know if ssk1328 does, or is it a genuine query? | 07:02 |
| shenki | mithro: i know why, and i wanted to hear ssk1328's reasoning | 07:02 |
| mithro | shenki: I'm interested to know why you think it is :) | 07:03 |
| shenki | mithro: :) | 07:03 |
| ssk1328 | shenki: I don't my reasoning is what you were expecting me to say | 07:04 |
| shenki | cyou can use volatile to ensure memory acess is ordered | 07:04 |
| shenki | but there's no code in that function that depends on the writes to the memory location being in a certain order | 07:05 |
| shenki | mostly becuase it's not reading or writing to the same location twice | 07:05 |
| shenki | but also becuase the writes do not have any ordering dependanices between themselves | 07:05 |
| shenki | that is, we don't care if the top left pixel is written first, or the bottom right | 07:06 |
| ssk1328 | shenki: Okay. So if we don't use volatile the os uses some reordering in memory access generally for some optimizations? | 07:07 |
| shenki | the compiler. this has nothing to do with operating systems | 07:07 |
| mithro | ssk1328: s/os/C compiler+optimizer/ | 07:07 |
| ssk1328 | shenki: Okay | 07:08 |
| shenki | ssk1328: yes, the c standard defines what the compiler is allowed to do. it can change the order in which memory accesses appear | 07:08 |
| shenki | ssk1328: (as can the cpu memory model, but that doesn't concern us on the CPUs we're playing with, nor on x86) | 07:08 |
| shenki | ssk1328: what's your background? have you studied any computer science? | 07:09 |
| ssk1328 | shenki: My major is in Microelectronics but I have done courses in Computer Architecture | 07:09 |
| mithro | shenki: So, the reason I think/thought it was declared volatile is because the DMA can be writing to the frame buffer locations at the same time the CPU is accessing/writing to it -- thus two reads from the same memory location are not guaranteed to return the same value... | 07:09 |
| shenki | ssk1328: cool! i studied that area a lot | 07:09 |
| shenki | mithro: if we were reading, that might be a good reason to use volatile | 07:10 |
| shenki | ssk1328: have a read of this: https://en.wikipedia.org/wiki/Memory_ordering | 07:10 |
| tpb | Title: Memory ordering - Wikipedia, the free encyclopedia (at en.wikipedia.org) | 07:10 |
| ssk1328 | shenki: From what I understand volatile is required in pattern because we are writing text over the actual pattern and we need text to go aon the top of color pattern | 07:12 |
| mithro | shenki: Hrm, I've never seen "asm volatile("" ::: "memory");" before - that seems to be very different to the normal "volatile xyz" type thing? | 07:13 |
| shenki | mithro: that's a memory barrier. that's the "proper" thing to do, in many cases, where doing "volatile xyz" is the sledgehammer approach | 07:14 |
| shenki | ssk1328: you don't do that in the function i was revewing | 07:14 |
| ssk1328 | shenki: Yeah correct. I guess I should change that. | 07:15 |
| mithro | ssk1328: I'm unsure that the volatile is needed in pattern.c either... | 07:15 |
| mithro | My guess is that _florent_ copied from the hdmi_XXX.c code and didn't remove it.... | 07:16 |
| shenki | it's not a big deal - it probably woudln't have made the code any worse | 07:16 |
| shenki | but it's good to understand why you're doing things, instead of just copying them :) | 07:16 |
| mithro | Actually, I think for consistency we should keep the volatile for now | 07:16 |
| shenki | nak | 07:17 |
| mithro | and then go and cleanup it's usage in all the files | 07:17 |
| shenki | you should't do something wrong because someone else is doing it wrong | 07:17 |
| *** aom_ has quit IRC | 07:17 | |
| shenki | it's your code review tho :) | 07:17 |
| mithro | shenki: If you are going to do something wrong, do it consistently wrong everywhere :) | 07:17 |
| ssk1328 | Seems like I am not making this change for now | 07:18 |
| shenki | :/ | 07:19 |
| mithro | ssk1328: Good habit if we do something like this is to log a github issue | 07:19 |
| mithro | ssk1328: So, please log a Github issue with something like "Clean up the usage of volatile in the lm32 firmware" add some details and links to where it is used and maybe a link to this conversation in the logs | 07:21 |
| ssk1328 | mithro: okay | 07:24 |
| CarlFK | mithro: update on https://plus.google.com/u/0/101817321389198875733/posts/AwubvKxLk7E?pid=6302268158548946674&oid=101817321389198875733 | 07:40 |
| mithro | CarlFK: does it work on older versions? | 07:41 |
| CarlFK | different Atlys, different lcd, same firmware rev, can't repoduce the noise | 07:41 |
| mithro | CarlFK: IE can you pinpoint when it started doing that? | 07:41 |
| mithro | CarlFK: can you try different Atlys, same LCD, same firmware? | 07:41 |
| CarlFK | sorry - it is all in a box on its way to NY | 07:42 |
| mithro | CarlFK: I assume you will eventually get access to it again at some point? | 07:42 |
| CarlFK | mithro: in 3 of 4 days. | 07:43 |
| CarlFK | 3 or 4... | 07:43 |
| mithro | CarlFK: Nothing is going to happen in the next 3 or 4 days which fixes that deliberately :P | 07:44 |
| CarlFK | mithro: it seemed odd that it only happened on output1. | 07:45 |
| mithro | CarlFK: output 2 is the little micro HDMI connector right? | 07:45 |
| CarlFK | I call them 0 and 1. 1 is the little micro | 07:46 |
| mithro | CarlFK: sorry yeah | 07:46 |
| mithro | The micro HDMI connector is unamplified | 07:46 |
| mithro | CarlFK: are you using a redmere cable there? | 07:46 |
| CarlFK | mithro: no redmere. | 07:47 |
| mithro | CarlFK: use a redmere and see if it cleans it up? | 08:15 |
| CarlFK | mithro: that's worth a shot. assuming I can remember to bring some with me ... | 08:17 |
| mithro | CarlFK: worth checking if different firmware revisions also cause it more or less | 08:18 |
| mithro | sab_123: consistency is one of the most important things in coding | 08:56 |
| sab_123 | mithro, ok | 08:56 |
| *** sab_123 has quit IRC | 11:44 | |
| *** sab_123 has joined #timvideos | 11:45 | |
| Neuron1k | @ssk1328 When we are discuting about memory: great paper by Drepper https://www.akkadia.org/drepper/cpumemory.pdf It gives good insight about how CPU uses memory and caches. | 12:31 |
| *** miselin has quit IRC | 13:14 | |
| *** nueces has joined #timvideos | 13:24 | |
| *** ssk1328 has quit IRC | 14:04 | |
| *** ssk1328 has joined #timvideos | 15:48 | |
| *** miselin has joined #timvideos | 15:50 | |
| *** miselin has joined #timvideos | 15:50 | |
| *** sab_123 has quit IRC | 15:57 | |
| *** nueces_ has joined #timvideos | 16:13 | |
| *** nueces has quit IRC | 16:15 | |
| *** nueces_ is now known as nueces | 16:47 | |
| *** nueces_ has joined #timvideos | 17:23 | |
| *** nueces has quit IRC | 17:25 | |
| *** nueces_ is now known as nueces | 17:29 | |
| *** ssk1328 has quit IRC | 18:04 | |
| *** Bertl_oO is now known as Bertl_zZ | 19:38 | |
| *** springermac has quit IRC | 22:20 | |
| *** springermac has joined #timvideos | 22:21 | |
| *** CarlFK has quit IRC | 22:28 | |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!
