Asking for more details about today's coffee break(2), he said that some USB keyboards (like scan3) didn't work, PS/2 to USB didn't work, and RS232-to-USB it did not work, so forget about the USB part, it's not very useful for my purpose.
Right; it sounds like a very limited USB implementation!
Question:
Do you actually need a hardware solution on both ends?
Or would it suffice for the VGA input side to be a hardware solution, with a fully-featured computer on the remote side?
You see, generating 1000Base-T (802.3ab) signaling and say raw Ethernet frames from an FPGA is feasible. Then, stick e.g. TP-Link MC220L (or a pair), and you can use 1000Base-SX, 1000Base-LX, or 1000Base-LH fiber. On the other end, you'd have a computer decoding and replying to the Ethernet frames. You can even use one unmanaged switch in between (the switch must directly see both endpoints) without having to implement an IP stack at all.
I believe Intel EK-10CL025U256 (
93€ at Mouser) might be a suitable development kit.
Details. It is based on Intel Cyclone 10 LP, has GbE, ample HyperRAM for a couple of full framebuffers (at 1024×768 24bpp), plenty of 3.3V I/O pins (for the VGA input based on TVP7002, as well as level translators/isolators for UART, and/or RS-232 transceivers, on a 2×20-pin header, making "daughtercard" handling VGA and serial ports easy to build). Again, the Open Source Scan Converter
schematics would show how the VGA input with TVP7002 is done. (The idea being that TVP7002 is self-clocking, and the FPGA only needs to be fast enough to read the digital inputs. 1024×768 60fps pixel clock is 65MHz, i.e. 24 bits of data every 15 nanoseconds. It seems to be too much for the HyperRAM (142 MB/s, the blurb says it can do 100 MB/s), so only every other scan line per field could be transmitted, leading to tearing. Essentially, it would combine the digitized video data and UARTs into Ethernet frames (jumbo frames, of say 4k to 8k bytes per frame) as the video is digitized.
Altera DK-DEV-10M50-A (
185€ at Mouser) would be a surer opyion. It is based on Intel MAX 10 (10M50D), with two GbE ports, HDMI output, lots of DDR3 RAM, programmable clock generator, two PMOD connectors with eight I/O pins at 3.3V logic levels (well suited for serial port level translators or isolators or RS-232 drivers), Cypress EZ-USB 2.0 (FX2LP), and a
HSMC connector suitable for interfacing to TVP7002 (2.5V CMOS, input is 3.3V compatible). (The connector itself is bloody expensive, though:
14€ in singles at Mouser.)
(2) (a bit of humor here, but ...) I guess, we should stop talking about work stuff during breaks, otherwise they are not "breaks" but rather "work extensions" done at the coffee machine

Noooo... my favourite part of the work day: brainstorming with cow-orkers with hot beverages.
there were problems with some VGA cards(4) and video resolutions, so problems which manifested themself with various glitches, as if it occasionally lost synchronization.
That's why I like the TVP7002 –– if its image quality is sufficient; it is
not the best available, I understand, but just sufficient ––: it has been found to work with a lot of older equipment (see scan converter!), and you can fine-tune the details over I2C to get the best image quality possible, but it really handles the sync stuff itself. (It would be a good idea to also wire the hsync and vsync outputs to the FPGA, so it can look at the intervals and polarity to determine the most likely VESA mode. I would also allow the remote end to tune the I2C parameters.)
The DK-DEV-10M50-A has so much DDR3 RAM it can buffer entire video frames
and queue many Ethernet jumbo frames, and even dynamically adapt the video frame rate to the available bandwidth (for example, if you want to also provide many Mbaud serial connections in parallel, and they all happen to transfer data at the same time). Or "lock" to an integer fraction of the original, perhaps, for a "smoother" user experience.
Oh, and I do recommend considering using UART isolators in any case: TI ISO6721 oir ISO7721 for RX+TX only, ISO6742/ISO7742 for RX+TX+RTS+CTS; plus an isolated DC-DC converter if powering an RS232 transceiver on the isolated side. The reason is that the VGA connector ground may not be exactly the same potential as the UARTs/RS-232 –– heck, they might even be connected to different machines, couldn't they –– and this way your FPGA board could share the VGA ground.
I'm perplexed that a "VGA extender" doesn't work with some video cards and resolutions (XVGA) that should be supported.
Although VESA defines a precise set of display mode timing information (see e.g.
this), not all displays conform to them. There is even a "sub-standard", "CVT" or reduced blanking, which greatly reduces the retrace durations. Some devices might have soft or glitchy sync pulses. Many VGA monitors do support EDID (via DDC2B, based on I2C), which the graphics card could easily parse and adopt its settings accordingly; very few VGA extenders bother to support that, because they'd really need to read it first from the remote end, before the local end queries it. I don't think I2C clock stretching to cover a fiberoptic data transfer twice plus the actual query, would work well.