*** tpb has joined #timvideos | 00:00 | |
mithro | ysionneau: I assume you are asleep, but I'm pretty sure if those i2c-tools above can read your virtual EEPROM, then the fx2 will be able too | 03:17 |
---|---|---|
CarlFK | mithro: when versions get promoted to testing and stable, how do we know what the source is? | 03:25 |
mithro | CarlFK: the git ID is encoded in the firmware and in the firmware name | 03:25 |
CarlFK | oh cool | 03:25 |
mithro | CarlFK: see https://github.com/timvideos/HDMI2USB-firmware-prebuilt/tree/master/archive | 03:26 |
tpb | Title: HDMI2USB-firmware-prebuilt/archive at master · timvideos/HDMI2USB-firmware-prebuilt · GitHub (at github.com) | 03:26 |
mithro | CarlFK: stable / testing are really just symlinks | 03:26 |
*** Bertl_zZ_ has joined #timvideos | 04:12 | |
*** [d__d] has quit IRC | 04:13 | |
*** Bertl_zZ has quit IRC | 04:13 | |
*** se6astian|away has quit IRC | 04:14 | |
*** se6astian|away has joined #timvideos | 04:14 | |
*** se6astian|away is now known as se6astian | 04:14 | |
*** [d__d] has joined #timvideos | 04:17 | |
*** CarlFK has quit IRC | 07:21 | |
*** CarlFK has joined #timvideos | 07:51 | |
*** ChanServ sets mode: +v CarlFK | 07:51 | |
*** jamesh_ has joined #timvideos | 08:03 | |
*** jamesh has quit IRC | 08:06 | |
*** jamesh_ is now known as jamesh | 08:12 | |
xfxf | mithro: how can I help to fix/progress this issue talking to the hdmi2usb? | 08:19 |
xfxf | you said it was an issue with the driver? | 08:19 |
xfxf | any workarounds that come to mind? | 08:19 |
mithro | xfxf: The issue is with the exart-uart-driver USB serial adapter | 08:44 |
mithro | xfxf: so, unless you think you can work on that driver there isn't much you can help with that | 08:45 |
xfxf | i'm no kernel hacker, that's for sure | 08:45 |
mithro | xfxf: the code I wrote tries to work around the pyseral / exart-uart-driver weirdness | 08:45 |
xfxf | is this something we can report upstream? | 08:45 |
mithro | xfxf: there is no "upstream" | 08:46 |
mithro | xfxf: upstream is currently shenki :-P | 08:46 |
xfxf | oh, right, you guys wrote the driver | 08:46 |
xfxf | i assumed it was in the kernel | 08:46 |
xfxf | so i should prod shenki? :P | 08:46 |
mithro | xfxf: well, no we didn't - we make the old crappy obsolete driver work again | 08:46 |
xfxf | right, but it's still evidently crappy | 08:46 |
mithro | xfxf: correct | 08:47 |
xfxf | like i'm happy hacking away at application level stuff hence my interest in getting this basic switcher more fleshed out as basic capture software | 08:47 |
xfxf | to use 'for now' until voctomix or gst-switch is in a usable state | 08:47 |
xfxf | and i'm keen to get my hands dirty with python again, been doing too much php/rails lately | 08:47 |
xfxf | oh, while i remember too - i'm keen on solving the issue with gstreamer only capturing at 15fps | 08:48 |
xfxf | you wanted to know what the encoer was running at? | 08:48 |
xfxf | i can test that now | 08:48 |
_florent_ | xfxf: have tried commenting the line I sent you the other day for the 15fps? | 08:58 |
_florent_ | https://github.com/timvideos/HDMI2USB-misoc-firmware/blob/master/firmware/lm32/encoder.c#L170 | 08:59 |
tpb | Title: HDMI2USB-misoc-firmware/encoder.c at master · timvideos/HDMI2USB-misoc-firmware · GitHub (at github.com) | 08:59 |
xfxf | _florent_: ah, sorry, i completely forgot about that. will do! i haven't been home, am now | 08:59 |
_florent_ | ok thanks | 09:00 |
*** Bertl_zZ_ is now known as Bertl | 09:08 | |
xfxf | hmm | 09:11 |
xfxf | encoder says | 09:11 |
xfxf | encoder: 1280x720 @ 30fps (19Mbps) from input0 (q: 85) | 09:11 |
xfxf | captured file when poked with avprobe | 09:11 |
xfxf | Stream #0.0(eng): Video: mjpeg, yuvj422p, 1280x720 [PAR 1:1 DAR 16:9], 15 fps, 15 tbr, 1k tbn (default) | 09:12 |
xfxf | capture command: | 09:12 |
xfxf | gst-launch-1.0 v4l2src device=/dev/video1 ! image/jpeg,width=1280,height=720 ! matroskamux name=mux alsasrc device='hw:0,0' ! audio/x-raw,channels=2,rate=48000 ! audioconvert ! vorbisenc ! queue ! mux. mux. ! queue max-size-bytes=100000000 max-size-time=0 ! filesink location=hdmi2usb_recording_`date +%s`.mkv | 09:12 |
mithro | xfxf: does the file actually have 15fps or does it have 30fps in it? | 09:12 |
xfxf | totem is claiming 15fps, it looks less juddery than the previous content captured | 09:13 |
xfxf | i'd normally rely on what the file reports though and not my perception, not really scientific | 09:14 |
xfxf | i assume you're implying the headers might say 15fps but the content is 30? | 09:14 |
mithro | xfxf: break the file apart and see how many frames per second are in the file? | 09:14 |
xfxf | what tools would i use to splice apart the files and inspect the frames? | 09:14 |
xfxf | well, mplayer with -fps 15 displays slower than -fps 30 | 09:17 |
xfxf | -fps 30 looks the same as if played normally | 09:17 |
xfxf | so perhaps it is 30 fps now | 09:18 |
xfxf | aah | 09:20 |
xfxf | okay | 09:20 |
xfxf | so | 09:20 |
xfxf | the content i captured the other day | 09:20 |
xfxf | with the gstreamer line above | 09:20 |
xfxf | actually is 30fps i think | 09:20 |
xfxf | just because the headers say 15fps then my ffmpeg conversion just converted it to a 15fps file | 09:20 |
xfxf | as it looked at the fps of the original file | 09:20 |
xfxf | i'm playing back the mjpeg recording now, looks fine | 09:20 |
xfxf | although the player is claiming it's 15fps | 09:20 |
xfxf | why is that happening? | 09:21 |
xfxf | so _florent_ commenting out that line doesn't make any difference | 09:21 |
_florent_ | ok, so the issue is probably in the UVC header inserted by the FX2 (fixed to 15fps) | 09:22 |
xfxf | also wierd, so each mjpeg frame can contain data about the playback rate? i had always thought that was the responsibility of the container | 09:23 |
xfxf | right | 09:23 |
mithro | kind of | 09:23 |
mithro | the source is likely to be the UVC header, but it goes USB->V4L2->gstreamer | 09:23 |
mithro | https://github.com/mithro/HDMI2USB-misoc-firmware/blob/fx2-refactor/firmware/fx2/descriptors_hdmi2usb_alt.c | 09:25 |
tpb | Title: HDMI2USB-misoc-firmware/descriptors_hdmi2usb_alt.c at fx2-refactor · mithro/HDMI2USB-misoc-firmware · GitHub (at github.com) | 09:25 |
mithro | Probably either line 316 or 331 | 09:26 |
xfxf | ah, i assume they're defaults? why not default to 30? | 09:26 |
mithro | xfxf: because that is what the old code did | 09:27 |
mithro | This is the previous version -> https://github.com/mithro/HDMI2USB-misoc-firmware/blob/fx2-refactor/firmware/fx2/descriptors_hdmi2usb.a51#L255 | 09:27 |
tpb | Title: HDMI2USB-misoc-firmware/descriptors_hdmi2usb.a51 at fx2-refactor · mithro/HDMI2USB-misoc-firmware · GitHub (at github.com) | 09:27 |
mithro | I spent a whole bunch of time converting that a51 into that .c file so I could understand what was going on | 09:28 |
xfxf | right | 09:28 |
xfxf | https://github.com/mithro/HDMI2USB-misoc-firmware/blob/fx2-refactor/firmware/fx2/uvclocal.h | 09:29 |
tpb | Title: HDMI2USB-misoc-firmware/uvclocal.h at fx2-refactor · mithro/HDMI2USB-misoc-firmware · GitHub (at github.com) | 09:29 |
xfxf | so i see FRAME_INTERVAL_30FPS is defined there | 09:29 |
xfxf | should i just change 15 to 30 in that c file? | 09:29 |
mithro | xfxf: Yes, I just added that | 09:29 |
mithro | xfxf: I have no idea if that .c file works yet | 09:29 |
xfxf | oh, right, you're still using the a51 | 09:29 |
mithro | xfxf: this is my fx2-refactor branch | 09:29 |
xfxf | right | 09:30 |
mithro | which is trying to get the FX2 firmware into a better state were we can improve it | 09:30 |
mithro | and get it working reliably under Linux, Windows and Mac | 09:30 |
xfxf | that explains why trying to egrep for FRAME_INTERVAL locally found nothing | 09:31 |
xfxf | neat, sounds good | 09:31 |
xfxf | so i should hang tight until you've done that? | 09:31 |
mithro | xfxf: well, it seems like you might have a work-around for now? | 09:32 |
mithro | xfxf: btw did you try my changes to your code? | 09:33 |
xfxf | sort of, i know what the issue is now, i'll just need to figure out how to get to create a 30fps file (it's only the mjpeg dumped off the device that is playing back properly) | 09:33 |
xfxf | i did a basic straight capture + manual conversion the other day just to prove this works to myself | 09:34 |
xfxf | my intention was to mangle up the gstreamer pipeline more so it's transcoding to disk as part of the capture | 09:34 |
xfxf | not sure if the 15fps wierdness might complicate that | 09:34 |
mithro | I'm sure thaytan and help you figure out a gstreamer pipeline which overrides the information that v4l2 is telling it | 09:35 |
xfxf | cool, can you do that to the above so the mjpeg saved out does have the right header info? | 09:37 |
xfxf | above line i pasted, that is | 09:37 |
xfxf | i assume if that's done early enough in the pipeline then i shouldn't have an issue adding extra stuff after it | 09:38 |
xfxf | pretty much as soon as i have some basic switching working | 09:38 |
xfxf | i'll start recording stuff with it | 09:38 |
xfxf | even if it requires some wierd workarounds | 09:38 |
xfxf | as long as i get usable video out at the other end | 09:38 |
mithro | xfxf: I don't know how | 09:43 |
xfxf | thaytan: ping :) | 09:45 |
thaytan | hmm? | 09:45 |
xfxf | see above - the hdmi2usb device with the gstreamer line i pasted seems to be writing out 30fps data with a 15fps header (i assume) | 09:46 |
xfxf | need a way to force it to 30fps | 09:46 |
thaytan | capssetter | 09:46 |
thaytan | gst-launch-1.0 v4l2src device=/dev/video1 ! image/jpeg,width=1280,height=720 ! capssetter caps='image/jpeg,width=1280,height=720,framerate=30/1' ! .... | 09:47 |
thaytan | like that | 09:47 |
xfxf | right, ta, was just looking up the syntax | 09:47 |
xfxf | will give it a go | 09:47 |
xfxf | neat, works, thanks again! | 09:50 |
xfxf | mithro: another thing that happens too is my canon HDMI camera when plugged into the HDMI2USB doesn't actually feed it any data | 09:52 |
xfxf | you have to turn it off and turn it back on again then HDMI2USB will see it | 09:52 |
xfxf | given you force the output resolution on the camera my assumption is it's possibly not handshaking (as much, at all? i don't know) | 09:52 |
xfxf | may be common with other cameras or scalers, not sure | 09:53 |
xfxf | (this is my XA20 camera, not the LCA ones) | 09:53 |
ysionneau | morning | 09:54 |
mithro | xfxf: the camera or the HDMI2USB? | 09:56 |
xfxf | the camera has to be power cycled | 09:57 |
xfxf | this throws one out in a normal setup routine because you plug everything in, turn it on, and the camera doesn't work | 09:57 |
mithro | xfxf: have you tried resetting the video_mode with the camera plugged in? | 09:57 |
xfxf | i believe i did, but i'm happy to try that now | 09:57 |
mithro | Please do | 09:58 |
ysionneau | I guess that to use the tools you linked mithro I need to connect somehow my i2c pins to my computer motherboard? | 09:58 |
ysionneau | since those tools run on host | 09:58 |
mithro | ysionneau: I was going to ask if you had a beaglebone or buspirate or something? | 09:58 |
mithro | xfxf: I was wondering if it was a form of https://github.com/timvideos/HDMI2USB-misoc-firmware/issues/80 or not? | 09:59 |
tpb | Title: Support resetting an video input without resetting the output · Issue #80 · timvideos/HDMI2USB-misoc-firmware · GitHub (at github.com) | 09:59 |
ysionneau | hmmm I don't, but I think I might have some compatible board | 09:59 |
ysionneau | I think there are alternative firmware for other boards | 09:59 |
ysionneau | oh, I have a minnowboard Max | 10:00 |
ysionneau | let's hope it has i2c | 10:00 |
mithro | ysionneau: if you had a beaglebone or similar board, Rohit might actually be able to help | 10:00 |
mithro | he's done a whole bunch of i2c work for talking to the VGA chipset | 10:00 |
ysionneau | yay i2c | 10:00 |
xfxf | mithro: nope, doesn't work | 10:00 |
xfxf | https://www.irccloud.com/pastebin/05wlA5Gp/ | 10:00 |
tpb | Title: Pastebin | IRCCloud (at www.irccloud.com) | 10:00 |
xfxf | i turn camera on and off | 10:01 |
xfxf | input1: 1280x720 | 10:01 |
mithro | https://github.com/rohit91/HDMI2USB-vmodvga-misoc/blob/c6b961489b114526e65de70c44ccadfe9638b92e/firmware/lm32_vga/ad9984a.c | 10:01 |
tpb | Title: HDMI2USB-vmodvga-misoc/ad9984a.c at c6b961489b114526e65de70c44ccadfe9638b92e · rohit91/HDMI2USB-vmodvga-misoc · GitHub (at github.com) | 10:01 |
xfxf | oh also | 10:01 |
xfxf | i keep having to do 'output0 off' | 10:01 |
xfxf | else the board freaks out | 10:01 |
xfxf | you'll note my script does it after every input change | 10:01 |
mithro | define "freaks out" | 10:01 |
xfxf | the HDMI out feeding a small monitor i have starts flicking on and off | 10:01 |
xfxf | er, output1 off rather | 10:02 |
xfxf | it's coming out of output0 | 10:02 |
xfxf | this was the issue where having all inputs+outputs+encoder caused it to run out of DDR bandwidth | 10:02 |
ysionneau | http://wiki.minnowboard.org/MinnowBoard_MAX < ctr+F i2c , got it | 10:02 |
tpb | Title: MinnowBoard MAX - MinnowBoard Wiki (at wiki.minnowboard.org) | 10:02 |
ysionneau | mine runs Debian Jessie, so those i2c-tools should run | 10:02 |
ysionneau | it's actually my mail server so I must take care of not frying it | 10:03 |
xfxf | i'm not clear on what happens but if i do 'output1 off' initially, and then video_matrix toggle encoder/output0, output1 somehow gets re-enabled | 10:03 |
xfxf | which is again why my script just does 'output1 off' after every switch | 10:04 |
xfxf | seems to work around it | 10:04 |
xfxf | mithro: and no your script doesn't work for me, will figure out why | 10:08 |
mithro | xfxf: if you are running out of DDR bandwidth you will be getting FIFO errors reported on the USB output | 10:09 |
xfxf | would i see that in dmesg on the host, or in the console of hdmi2usb? | 10:09 |
xfxf | either way, unless i do 'output1 off' after every switch then the HDMI output to my little confidence monitor starting flicking on and off | 10:10 |
mithro | serial console HDMI2USB | 10:10 |
xfxf | which i assumed was a bug | 10:10 |
xfxf | right, i'm not getting FIFO errors there | 10:10 |
xfxf | wait, perhaps if i tried actually capturing at the same time i would, i can try | 10:11 |
xfxf | this is with the encoder on but not actually doing any capture | 10:11 |
xfxf | input0+input1+encoder+output0 on | 10:11 |
mithro | xfxf: I need a clearer explanation of exactly what is happening and exactly your set up | 10:12 |
xfxf | yeah, sure, let me reproduce | 10:12 |
xfxf | ah, wait, i think i might have found the issue | 10:13 |
xfxf | does changing video_mode enable both outputs? | 10:13 |
mithro | xfxf: Not sure, you can look at the code you know | 10:13 |
xfxf | ah, that fixed it | 10:14 |
mithro | xfxf: that is what I do | 10:14 |
xfxf | i was doing 'output1 off' before setting the video_mode | 10:14 |
xfxf | the latter appears to turn it back on again | 10:14 |
mithro | xfxf: you should only be doing video_mode once on start up | 10:14 |
xfxf | all good, not an issue | 10:14 |
xfxf | yeah i am, the INIT= part of my script | 10:14 |
xfxf | i just changed the order | 10:14 |
xfxf | would it be good behaviour to have hdmi2usb return the status on every command? | 10:19 |
xfxf | or at least output from commands fed to it? | 10:19 |
xfxf | it'd stop somebody else from falling into this same trap | 10:19 |
mithro | xfxf: my changes added a status command | 10:21 |
mithro | (after each change) | 10:21 |
xfxf | yeah i notice that | 10:21 |
xfxf | i mean at the firmware level | 10:21 |
xfxf | so every time you type a command you get something back from the device that tells you what happened | 10:22 |
mithro | xfxf: This is all C code, so please feel free to hack on it | 10:41 |
mithro | https://github.com/timvideos/HDMI2USB-misoc-firmware/blob/master/firmware/lm32/ci.c | 10:42 |
tpb | Title: HDMI2USB-misoc-firmware/ci.c at master · timvideos/HDMI2USB-misoc-firmware · GitHub (at github.com) | 10:42 |
mithro | xfxf: you just need to do a "make lm32-firmware; make load-lm32" - don't even need to rebuild the gateware | 10:42 |
xfxf | sure, i don't mind attempting to hack on it, just verifying if that is a sane design decision | 10:43 |
mithro | I can't guarantee that :P | 10:43 |
mithro | I do think ever command having some type of success / error code result seems pretty reasonable | 10:43 |
mithro | but I'm going to go home now | 10:43 |
xfxf | i was just typing the success/error code thing | 10:44 |
xfxf | nod | 10:44 |
xfxf | seems more sane, means i can parse that in my switchy thingy and handle errors properly | 10:44 |
xfxf | rather than having it do things blind | 10:44 |
_florent_ | each valid command should already return a ack message no? | 10:48 |
_florent_ | if you want to print the status after a command, just send the status command | 10:48 |
mithro | xfxf: you might want to take a look at the other lm32 firmware issues on GitHub too | 10:52 |
mithro | xfxf: I got most of the way through the custom EDID adding patch - would be helpful to finish that | 10:59 |
mithro | it is rather wet outside | 11:14 |
mithro | ysionneau: is wiki.minnowboard.org down? | 11:14 |
ysionneau | hmmm works from here | 11:16 |
mithro | oh, there DNSSec is broken | 11:23 |
mithro | s/there/their/ | 11:23 |
*** rohitksingh has joined #timvideos | 11:35 | |
mithro | ysionneau meet rohitksingh | 11:43 |
rohitksingh | ysionneau: hi! I follow you on twitter! :) | 11:43 |
ysionneau | hi rohitksingh :) | 11:44 |
ysionneau | nice to meet you! | 11:44 |
ysionneau | I'm going to play a bit with i2c | 11:44 |
ysionneau | rohitksingh: what's your twitter handle? | 11:45 |
rohitksingh | ysionneau: awesome! | 11:45 |
rohitksingh | its RohitK_Singh | 11:45 |
ysionneau | and now I follow you as well :) | 11:45 |
rohitksingh | haha... :) | 11:46 |
ysionneau | I'm going to use the i2c.c from lm32 fw, but to make a i2c slave acting like an EEPROM | 11:46 |
ysionneau | so I'm going to need a master to test my code | 11:46 |
ysionneau | I'm thinking of using my Minnow board Max which has i2c pins and runs Debian Jessie | 11:46 |
rohitksingh | ysionneau: ohkay... it should work, I haven't tried using it as slave yet...But, I can try that | 11:49 |
rohitksingh | any problem you are encountering? | 11:49 |
rohitksingh | Minnowboard Max side must be working well and good, i guess? | 11:51 |
ysionneau | so far I don't have much to test | 11:52 |
ysionneau | but I'll keep you posted if I have any issue or news | 11:52 |
ysionneau | 12:48 < rohitksingh> Minnowboard Max side must be working well and good, i guess? < it's a pretty good machine, I'm using it as my email server | 11:52 |
rohitksingh | ysionneau: Awesome! Pls do inform me in case of any issues! | 11:54 |
ysionneau | very kind of you, thx! | 11:54 |
ysionneau | what's your timezone? | 11:54 |
ysionneau | I'm UTC+1 | 11:54 |
rohitksingh | ysionneau: I had looked about Minnowboard Max, ~6 months back...neat little board.... | 11:55 |
ysionneau | yep | 11:55 |
rohitksingh | mine is GMT+5:30 | 11:55 |
ysionneau | very little power consumption, no fan (so : no noise), and ... x86! so all your preferred OS are working | 11:55 |
rohitksingh | I must try it! Just that it is little inaccessible in India at affordable rate (w/o huge import duties) | 11:56 |
ysionneau | arg | 11:56 |
ysionneau | I think I had lots of shipping cost as well :/ | 11:57 |
rohitksingh | I'm generally available online everyday from now to 7 hrs from now (UTC 12:00PM to UTC 7:00PM) | 11:57 |
rohitksingh | yeah...shipping also is around 30 USD :/ | 11:58 |
_florent_ | ysionneau: are you sure your i2c slave will be fast enough? You have no restriction using bitbanging when you are the master, but when you are the slave you are not controlling the clock, so you will probably need to implement it in hardware (reuse code from edid) | 11:59 |
rohitksingh | yeah...thats a valid point... | 12:00 |
rohitksingh | if hardware implementation is possible/allowed, for slave it would be better to go for it | 12:01 |
ysionneau | ok, first short between gnd+vcc , board reboot | 12:04 |
ysionneau | I hope I won't kill my email server | 12:04 |
ysionneau | _florent_: ah good point | 12:05 |
_florent_ | that the reason why edid is done in hardware | 12:05 |
ysionneau | yep I saw your implementation | 12:05 |
mithro | i2c clock rate is either 100kHz or 400kHz | 12:06 |
_florent_ | that's not mine, sb0 did it | 12:06 |
ysionneau | ah ok | 12:06 |
_florent_ | mithro: so that's probably too fast for a cpu that is doing others things | 12:07 |
rohitksingh | mithro: 10kHz also is an allowed speed IIRC | 12:07 |
mithro | _florent_: The lm32 runs at ~50MHz, right? | 12:07 |
_florent_ | yes | 12:08 |
ysionneau | means 100 times the speed | 12:08 |
ysionneau | but bitbanging is really slow | 12:08 |
ysionneau | but maybe 100 instructions per cycle are enough | 12:08 |
mithro | How many cycles per instruction? | 12:08 |
ysionneau | (per i2c cycle) | 12:09 |
rohitksingh | mitro: sorry, 10KHz not defined for I2C..only allowed in SMBus...I take my words back :p | 12:09 |
rohitksingh | *mithro | 12:09 |
mithro | If you have 100 instructions per clock transition seems pretty dooable | 12:10 |
ysionneau | yep | 12:10 |
ysionneau | _florent_: for now I think we want to be able to act as a slave while doing nothing else | 12:10 |
ysionneau | so full time polling as a slave | 12:10 |
_florent_ | that's for the FX2 configuration? | 12:11 |
ysionneau | yes | 12:11 |
_florent_ | what's the size of the emulated EEPROM? | 12:11 |
ysionneau | you want to put everything in blockram :p | 12:12 |
ysionneau | mithro: what's the size of the fx2 fw? | 12:12 |
mithro | 16k | 12:12 |
_florent_ | I'm just going to remove the big buffer of 1280*8 lines for the encoder, so yes there will be block rams availables :) | 12:13 |
mithro | I think kbytes but it could be kbit | 12:13 |
ysionneau | that can fit in block rams | 12:13 |
_florent_ | removing this buffer reduce blockram usage from 88% to less than 50% | 12:13 |
mithro | _florent_: \o/ | 12:14 |
ysionneau | but blockram issue is that you need to re synthesize the bitstream to change the fx2 fw | 12:14 |
_florent_ | why? | 12:14 |
ysionneau | or you give access to the blockram via wishbone/etherbone from the host | 12:14 |
_florent_ | yes, that's what is done for edid | 12:14 |
ysionneau | having the fw in spi flash is better I think | 12:15 |
ysionneau | so that when you change it, and you reboot, it stays | 12:15 |
ysionneau | you don't have to re-upload it to the blockram each time | 12:15 |
ysionneau | or ... let's put it in a an array in the BIOS and let the bios initialize the blockram at boot | 12:16 |
ysionneau | changing the fx2 fw would mean reflashing the bios then | 12:16 |
ysionneau | which is ok I would say | 12:17 |
_florent_ | you can also store the fx2 firmware in the flash | 12:17 |
_florent_ | and the lm32 just copy the content of the flash to the i2cslave memory at startup | 12:17 |
mithro | blockram, not blockrom :) | 12:17 |
ysionneau | ah yes also, sure | 12:18 |
ysionneau | so, mithro, you prefer I keep on the sw bitbanging approach? or I go the hw way? | 12:19 |
mithro | I'd say get the software bitbanging working first then accelerate with hardware if needed afterwards | 12:19 |
ysionneau | ack | 12:22 |
rohitksingh | mithro: did you see this? http://hackaday.com/2015/11/04/digging-hdmi-out-of-udp-packets/ | 12:28 |
tpb | Title: Digging HDMI Out Of UDP Packets | Hackaday (at hackaday.com) | 12:28 |
mithro | rohitksingh: they are reporting on some very old stuff there | 12:29 |
rohitksingh | mithro: oh..okay...I'm reading it now...thought maybe it was interesting :D | 12:30 |
*** wanig___ is now known as wanig | 12:30 | |
rohitksingh | oh article is almost 2 years old | 12:31 |
mithro | https://github.com/timvideos/HDMI2USB/wiki/Alternatives#lenkeng-hdmi-over-ip-extender | 12:31 |
tpb | Title: Alternatives · timvideos/HDMI2USB Wiki · GitHub (at github.com) | 12:31 |
rohitksingh | Quite ahead of the curve!! | 12:32 |
ysionneau | ok I can't get my minnowboard to toggle its i2c pins | 13:16 |
ysionneau | even using i2cdetect on its 10 i2C buses | 13:17 |
ysionneau | sometimes arduinos are usefull :) | 13:17 |
ysionneau | when you need one, you don't have any | 13:17 |
*** travis-ci has joined #timvideos | 13:59 | |
travis-ci | [timvideos/HDMI2USB-misoc-firmware/master#280] (4f2aac2): The build passed. (https://travis-ci.org/timvideos/HDMI2USB-misoc-firmware/builds/89216562) | 13:59 |
*** travis-ci has left #timvideos | 13:59 | |
*** thaytan has quit IRC | 14:22 | |
*** thaytan has joined #timvideos | 14:22 | |
*** ChanServ sets mode: +v thaytan | 14:22 | |
*** Bertl has quit IRC | 14:52 | |
*** Bertl has joined #timvideos | 15:14 | |
*** Bertl is now known as Bertl_oO | 15:14 | |
*** se6astian is now known as se6astian|away | 15:52 | |
tumbleweed | I remember mithro announcing that the opsis can do 1080p, but this isn't one of the video modes it lists | 17:16 |
tumbleweed | was that just theoretical? | 17:16 |
CarlFK | tumbleweed: I can at least confirm I know what you are talking about ;) | 17:17 |
CarlFK | I think something was implemented, but maybe as an experiment in some branch/repo | 17:18 |
tumbleweed | we were wondering if 1080p would cause less trouble with laptops | 17:21 |
tumbleweed | e.g. all that mode fighting I had to do to enable mirroring at 1080p on people's machines | 17:21 |
tumbleweed | err at 720p | 17:21 |
tumbleweed | and with available VGA->HDMI adaptors | 17:21 |
tumbleweed | CarlFK: any idea how to drive the outputs at modes other than 9? | 17:22 |
CarlFK | for sure there is no scaling going on, so whatever comes in goes out | 17:23 |
tumbleweed | yeah, I know there is no scaling | 17:23 |
tumbleweed | but say I wanted to use mode 8 on the input, how do I get something useful on the output | 17:23 |
tumbleweed | where useful = anything at all | 17:24 |
CarlFK | ill set up my Atlys so I can see what that is, but it should output whatver mode 8 is | 17:25 |
tumbleweed | I can't make it do that | 17:26 |
tumbleweed | hrm, I think it just wasn't happy with the input | 17:32 |
CarlFK | try pattern | 17:33 |
tumbleweed | I'm really trying to get something useful in via VGA | 17:35 |
tumbleweed | and that seems possible, but not at HDTV modes | 17:35 |
CarlFK | flterm --port /dev/ttyVIZ0 --speed 115 | 17:37 |
tumbleweed | we can get 1024x768@75 to capture | 17:37 |
CarlFK | Unable to open serial port: Device or resource busy | 17:37 |
CarlFK | any idea whats going on? | 17:38 |
tumbleweed | something else has it open | 17:38 |
CarlFK | lsof | grep VIZ ... nothing | 17:38 |
tumbleweed | lsof /dev/ttyVIZ0 | 17:39 |
CarlFK | lsof /dev/ttyVIZ0 ... nothign | 17:39 |
tumbleweed | oerugh | 17:41 |
tumbleweed | does the device exist? | 17:42 |
CarlFK | yes | 17:42 |
CarlFK | [ 652.198082] vizzini 5-1:1.0: ttyVIZ0: XR21v14x usb uart device | 17:42 |
tumbleweed | btw, have you used a rpi or beagle bone black or something, to gst-dvswitch,yet? | 17:42 |
CarlFK | crw-rw---- 1 root dialout 248, 0 Nov 4 11:35 /dev/ttyVIZ0 | 17:42 |
tumbleweed | you're in dialout? | 17:42 |
CarlFK | $ groups | 17:43 |
CarlFK | juser adm dialout cdrom sudo audio video plugdev lpadmin | 17:43 |
CarlFK | but let me log in and out again | 17:43 |
CarlFK | that fixed it. | 17:43 |
tumbleweed | lol | 17:43 |
CarlFK | this is the 3 week old install.. I should re-image it so I am not wordering if this stuff has been fixed | 17:44 |
CarlFK | I tried something with the pi, forget exactly what, but decided there wasn't enough cpu | 17:45 |
tumbleweed | yeah, not suprised :) | 17:45 |
tumbleweed | rpi1 or 2? | 17:45 |
CarlFK | 1 | 17:46 |
tumbleweed | right | 17:46 |
tumbleweed | 2 could be better | 17:46 |
CarlFK | I have access to all of those things, including the $9 chip, but that all needs to wait till after Node... | 17:46 |
CarlFK | output0: 1024x768@75Hz from pattern | 17:46 |
CarlFK | that works on my lcd | 17:47 |
tumbleweed | yeah, we eventually got that to work | 17:47 |
tumbleweed | but it didn't the first time I tried | 17:47 |
tumbleweed | then we started at mode 1 and worked our way up | 17:47 |
CarlFK | I added Cut to the gui | 17:49 |
CarlFK | can't figure out how to connect it to code | 17:49 |
*** CarlFK has quit IRC | 18:47 | |
*** CarlFK has joined #timvideos | 18:47 | |
*** ChanServ sets mode: +v CarlFK | 18:47 | |
*** springermac has quit IRC | 20:28 | |
*** springermac has joined #timvideos | 20:30 | |
*** rohitksingh has quit IRC | 20:44 | |
ysionneau | hmm | 21:24 |
ysionneau | so, I've been doing some tests. I hooked up an arduino UNO R3 (acting as I2C master) to my pipistrello FPGA board (acting as I2C slave via the lm32 in bitbang mode) | 21:24 |
ysionneau | The arduino sends SCL (i2c clock) at ~ 97 kHz | 21:25 |
ysionneau | it seems that the lm32 is too slow to send the ACK on time | 21:25 |
ysionneau | it sends it half a clock cycle late | 21:25 |
ysionneau | so the packet is NACKed :/ | 21:25 |
ysionneau | and this is with a 83.3 MHz lm32 | 21:26 |
ysionneau | I'm able to synchronize to START bit and read the slave address though | 21:27 |
ysionneau | ACK is 5 us late | 21:29 |
ysionneau | calling it a day! | 21:32 |
ysionneau | here is the logic analyzer dump https://framapic.org/TPcDnWIl2uuE/Jt3IOGOj | 21:34 |
ysionneau | Channel 1 is SCL , Channel 2 is SDA | 21:34 |
ysionneau | the master is writing to slave 0x8 | 21:34 |
ysionneau | cursor 3 is when ACK show happen (SDA low), cursor 4 is when it actually happens | 21:35 |
ysionneau | and btw cursor 4 length is worth 3 lm32's nop (+ a store word to set SDA to input/high again) | 21:36 |
ysionneau | gn8 | 21:37 |
CarlFK | mithro: Cut button in vocto: https://github.com/CarlFK/voctomix/commit/6668240e1569de63aec8fc25cfb735b09c67b39f | 23:40 |
tpb | Title: Add Cut button. · CarlFK/voctomix@6668240 · GitHub (at github.com) | 23:40 |
*** CarlFK has quit IRC | 23:43 |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!