Hi everyone,
If I understand correctly, next week a bunch of you will be meeting up in
Paris for a DebConf video sprint? Sadly, I won't be able to attend in
person but I'm very interested in trying to help support you remotely from
Australia. Luckily Paris daytime is my evening, so I should be available!
Do you have a todo list / agenda / other task tracking for what you hope to
achieve at the event? I assume that there are a bunch of things related to
your Opsis boards that would make sense to be worked on?
A couple of things which I would really love to see done are;
* Finish the VGA board changes.
- This is currently pending on RattusRattus changes around the ESD
protection.
- Once this has been finished, I can get my PCB designer to finish the
routing and we can look at getting them made!
* Getting the HDMI2USB-mode-switch tool (
https://github.com/timvideos/HDMI2USB-mode-switch) packaging for Debian
(and getting upstream).
- This tool will be the primary mechanism for people to manage their
HDMI2USB compatible boards and do things like upgrade the firmware on them.
- There are some custom udev rules included with the tool (
https://github.com/timvideos/HDMI2USB-mode-switch/tree/master/udev) which
probably need hitting with a stick to be acceptable (they current set
things to permission 0666).
- There are extra features that I would love to add but these are not
Debian specific things (IE Checking the existing firmware version and then
downloading newer firmware from the prebuilt repo).
* Start using the HDMI2USB-controlproxy-daemon (
https://github.com/timvideos/HDMI2USB-controlproxy-daemon) and packaging it
for Debian.
- This tool converts the serial interface into a TCP socket and works
around problems with the crappy serial implementations. It does things like
sending data slowly, allowing multiple connections, etc.
- The idea would be able to use this to allow monitoring of the state of
your HDMI2USB boards. Things like the error rate, resolution detected,
firmware versions in usage.
- This is also the connection point for some type of GUI which allows
controlling the connections and setup (see
https://github.com/timvideos/HDMI2USB-misoc-firmware/issues/41)
For those who aren't following the HDMI2USB firmware development closely,
the following information is probably important for deciding where you
spend your time;
We are currently trying to upgrade the firmware onto the newest version of
litex + misoc. Doing this will enable things like a significantly faster
build time, Ethernet support and merging a bunch of the GSoC student's
work. This means substantial changes to the current firmware (found in
https://github.com/timvideos/HDMI2USB-misoc-firmware) which can't be easily
ported forward are not a good idea.
This mean that the "little white bar" issue (which gets worse the more
inputs and outputs you enable) probably does *not* make sense for you guys
to investigate. The new versions include a rewritten DRAM controller and
the old DRAM controller is likely what is causing this white bar issue. We
are working on trying to reproduce with the newer controller and will fix
the problem there.
If you have the time, we would of course *love* help getting this upgraded
firmware to feature parity with the current firmware so we can switch over
ASAP. We are doing the work in the repository at
https://github.com/enjoy-digital/opsis-soc/tree/hdmi2usb. This firmware can
*not* currently be used for recording but it is getting very close to being
able to do that. To work on this repo, use the following script ->
https://gist.github.com/mithro/604da515edc1061a77a8ee6c1fe729e6
We also have a long term goal of porting Linux to the LM32 architecture.
This is a "fun" thing that people could definitely help out with but is not
really on the "critical path".
* We can reuse a lot of the Linux kernel infrastructure like the EDID and
DisplayPort processing (plus all the workarounds for broken monitors and
other hardware).
* Most of the non-timing critical features can be done in user space,
opening up the ability for more people to help out.
* In theory it could run Debian (very slowly :).
Joel 'shenki' Stanley is currently working on rebase the ancient port onto
a modern kernel version and would definitely love help (
https://github.com/shenki/linux-lm32/wiki). There are options like qemu and
verilator which allow this work to be done without needing access to the
actual hardware. If you know any kernel developers who are interested in
helping out please do point them our way.
Hope everyone has huge amount of fun!
Tim 'mithro' Ansell
PS It seems like I might be visiting Germany in late December. I'd love to
come say Hi to people anywhere in Europe (it's a long flight from
Australia), so send me an email if you want to hang out.
PPS We would love to have people come to Linux.conf.au 2017 in Hobart in
January. We will be having a TimVideos sprint the week before the
conference too.
_______________________________________________
Debconf-video mailing list
[email protected]
http://lists.debconf.org/mailman/listinfo/debconf-video
