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!
- 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 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).
- 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.
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.
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.