PS We obviously could use help! :) tumbleweed has been good at getting various things packaged but I don't think he has time to tackle bigger things like lm32 cross compilers.
If you know Linux Kernel hackers we have a whole bunch of interesting things which we would love their help with; from helping improve host side kernel drivers, to helping getting the Linux kernel running directly on the Opsis board itself (it'll be slow, but usable for things like running a HTTP server with a JSON control endpoint and SSH server). If we had more people with Linux kernel experience, we could do some awesome custom driver stuff on the host too. For example; * We could use a better option for supporting multiple serial ports. Maybe something based on http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/usb/serial/io_ionsp.h (We'd need something like that for libCEC support.) * We could use a better option for exposing the I2C buses on the device to the host computer. Maybe something based on http://lxr.free-electrons.com/source/drivers/i2c/busses/i2c-tiny-usb.c In fact any C hackers would be super useful! A large amount of the HDMI2USB firmware is in C (see https://github.com/timvideos/HDMI2USB-misoc-firmware/tree/master/firmware). Hardware wise, I'm sure that seaLne on the channel would love help with reviewing the VGA board schematics (work will be at https://github.com/timvideos/HDMI2USB-TOFE-VGA). Nobody is looking at SDI stuff yet. It would be good if someone started helping with that (both looking at creating boards and FPGA based decoders). Of course, anyone who has *any* FPGA experience would be *super* useful too, but I understand that is much less common :). So much to do, so little time :) Tim 'mithro' Ansell On 9 November 2015 at 20:26, Andy Simpkins <[email protected]> wrote: > > > On 07/11/2015 14:44, Tim Ansell wrote: > >> On 8 November 2015 at 01:22, Stefano Rivera <[email protected]> wrote: >> >> Hi Tim (2015.11.07_09:35:22_+0200) >>> >>>> *Ethernet Streaming* >>>> There is experimental support for streaming out via the Gigabit Ethernet >>>> rather than using USB. This would remove the need for the BeagleBone >>>> >>> Black >>> >>>> in your proposed set up. >>>> >>> That BeagleBone Black is also for outputting things via the HDMI2USB - >>> the second input. Non-critical, but nice for: >>> * Putting up X minutes remaining warnings on the confidence monitor >>> * Displaying now and next information on the projector between talks >>> * Playing a stream, broadcast from another room. >>> >>> If there was a way of slinging the odd JPEG (or MJPEG stream, for the >>> room-repeat use-case) at the HDMI2USB, then the BBB could be dropped >>> entirely. >>> >>> Gigabit Ethernet is full-duplex, so I can't see why we couldn't do some >> type of incoming stream (even pretty high bandwidth) without effecting the >> output in any way. >> >> Tim 'mithro' Ansell >> >> >> >> _______________________________________________ >> Debconf-video mailing list >> [email protected] >> http://lists.debconf.org/mailman/listinfo/debconf-video >> > > > Sorry not been reeding email during the Mini-Conf. > > Fantastic! > Tim seriously that is great, thank you so much for your feedback > I am pretty certain that with Ethernet fully working then we can make > Opsis do pretty much anything we want. Having something like a Beagle bone > connected will allow us to do pretty much the same until such time that > Opsis boots from FLASH / Ethernet becomes available etc etc. > > At the start of the week I was expecting to use our existing twinpact > solution as the frame grabber, instead we ended up using an Atlys, attached > to a laptop and a confidence monitor. The laptop dealing with programming > at boot time, and transcoding the MJPEG steam to 'DV' to be passed up to > DV-Switch. > > We were able to use HDMI, DP (& DVI) and VGA as our input sources using a > number of adapters, and we ran a VGA feed to the projector again using an > adapter. > > I believe that we only had *ONE* device that didn't automatically pick up > and 'just-work' with our selected 1024x768 resolution (IIRC this was a > Chromebook) and that was probably because it didn't want to do such an > outdated video mode ;-) > > The system was stable and worked for the entire weekend and already IMO > surpasses the twinpact solution. And this is going to get better... > > Regards > /Andy > _______________________________________________ > Debconf-video mailing list > [email protected] > http://lists.debconf.org/mailman/listinfo/debconf-video >
_______________________________________________ Debconf-video mailing list [email protected] http://lists.debconf.org/mailman/listinfo/debconf-video
