Live data from Hacker News

Why open source rocks – a new SM750 (Silicon Motion GPU) HDMI Driver

github.com

41–47 of 47 posts

Re: Why open source rocks – a new SM750 (Silicon Motion GPU) HDMI Driver

#41
post #37

I wrote* a modern Linux driver that supports ultrawide resolutions, higher refresh, and faster performance than the original driver(s) on this cheap HDMI only variant server GPU. I created it because I wanted my Nvidia GPUs to be compute only, and needed a cheap and small display GPU to run X11. I bought this GPU on AliExpress, after learning it had Linux support. It does, but kernel 5.x series and the sm750 driver i…

Nice. Is your vibecoded driver from scratch or does it bring the old driver forward ?

Bit of both. It uses the GPL low-level sm750 chip/DDK code from Linux’s old sm750fb driver, but it's not just that framebuffer driver updated. The DRM/KMS architecture, board specific SiI9024 HDMI support, modes, DMA updates, hardware cursor, ultrawide support and custom dither are new.

Re: Why open source rocks – a new SM750 (Silicon Motion GPU) HDMI Driver

#43
post #33

Earlier quoted context omitted.

It's the HDMI output that's the oddity; mid-90s cards with that much (little?) VRAM could already do 2048x1536x32, but usually had a VGA connector.

datacenter guys didn't like digitals. they embrace blurry SVGA pictures coming through excessively long cables and sometimes mechanical switches, and to them DVI/HDMI felt to be an all-or-nothing risk factor

It's a chicken-and-egg problem. Server hardware comes with VGA, because everything in the server room (think KVM switches, external remote KVM, local 19" consoles) is built with VGA. And that will be the case as long as server hardware comes with VGA.

Re: Why open source rocks – a new SM750 (Silicon Motion GPU) HDMI Driver

#46
post #33

Earlier quoted context omitted.

datacenter guys didn't like digitals. they embrace blurry SVGA pictures coming through excessively long cables and sometimes mechanical switches, and to them DVI/HDMI felt to be an all-or-nothing risk factor

It's a chicken-and-egg problem. Server hardware comes with VGA, because everything in the server room (think KVM switches, external remote KVM, local 19" consoles) is built with VGA. And that will be the case as long as server hardware comes with VGA.

I will be very surprised if it doesn't start switching over to USB-C over the next decade or two. Having a single port capable of doing the entire local KVM dance using readily-available hardware is just a no-brainer.

Some switches have already started using USB-C for serial instead of RJ45. When the technician is 100% already carrying a smartphone and C-to-C cable to charge it, making the console available with zero additional adapters is quite attractive.

Re: Why open source rocks – a new SM750 (Silicon Motion GPU) HDMI Driver

#47
post #46

Earlier quoted context omitted.

It's a chicken-and-egg problem. Server hardware comes with VGA, because everything in the server room (think KVM switches, external remote KVM, local 19" consoles) is built with VGA. And that will be the case as long as server hardware comes with VGA.

I will be very surprised if it doesn't start switching over to USB-C over the next decade or two. Having a single port capable of doing the entire local KVM dance using readily-available hardware is just a no-brainer. Some switches have already started using USB-C for serial instead of RJ45. When the technician is 100% already carrying a smartphone and C-to-C cable to charge it, making the console available with zero…

So, display out from USB-C cable is not display signal over USB 3.x digital signal, it's just an electronic analog patch-through to GPU. The pins in the port actually run raw DisplayPort signals when that feature is activated. So you can't plug a laptop to a server and get nicely packetized screen frames out over the USB host hardware. This is often not clearly communicated...

You can put a USB to RS232C or USB to Ethernet adapter behind the port to then expose ttyS0 or to serve a management webpage, that could happen, but I think the DB-9 and/or RGB would have to stay in that case.

Post reply on HN