5 ms·

What are the hardware limitations? Surely this is possible if there was investment and interest in making this work? Or do the protocols really not allow this?

by _rs 4y ago

chmod775 4y ago
In theory you could have a monitor that handles both signals all the time, buffering the output. Then it could switch immediately. It would however be more expensive, since you would need to duplicate at least some of the electronics within the monitor, a few of which also incur licensing/certification/patent/whatever fees.
- yjftsjthsd-h 4y ago
  Why would you buffer? Monitors are capable of playing full-screen video, which implies the ability to update every pixel once per... 30hz? frame, doesn't it?
  - chmod775 4y ago
    Because when you want instant switching you need to already have the data you want to display available the moment someone flips the switch. You can't just tell the computer that you're now interested in the display data of the other display - that would incur latency. You'll have to be receiving the information for the second display the entire time, storing it in what is commonly called a framebuffer, aka a bitmap in memory somewhere. Most types of display have such a thing backing them anyways - one way or another - since they need to remember what they're supposed to display.
    - eurasiantiger 4y ago
      It’s ok, I can wait 17ms for the next frame.
      - chmod775 4y ago
        With basic analog you could set it up in a way where you would just wait for the next frame (or don't even wait that long), but with the new digital stuff there's bootstrapping/handshaking - whatever you want to call it. It's not so simple anymore.
        lostdog 4y ago
        What could they possibly be doing that takes 4 seconds? That's ~4,000,000,000 instructions on a typical embedded processor. It's much more likely that the handshaking was implemented by an incompetent organization that doesn't care about quality.
        MichaelZuo 4y ago
        It is extremely odd to see so many people in this thread ignore that a handshake requires billions of instructions to be executed for some reason....
        eurasiantiger 4y ago
        One of the grandparents of this comment thread explicitly ignored it; this is a discussion on frame buffering.
    - yjftsjthsd-h 4y ago
      Okay, I'm willing to wait 1/30th of a second while the screen gets its pixels; is that not an option? Or is there no way to request all pixels and it doesn't send them all every frame?
      - chmod775 4y ago
        I don't think I understand what you're saying. I think you're concerned that because there's "buffers" there would be extra latency? There doesn't have to be.
        yjftsjthsd-h 4y ago
        That's what I'm asking. When the monitor is live, it can draw a complete screen ~30+ times every second, so why does it take more than 1/30th of a second to start from nothing? Then, I speculated that the only reason I could think of was if the graphics card doesn't actually send every pixel every frame, and there's no way for the monitor to request a full refresh.
        TylerE 4y ago
        Monitors don’t request anything. The monitor has to do a basic handshaking/negotiation before it even knows what sort of video stream to expect
        yjftsjthsd-h 4y ago
        Ah. And we couldn't stick... What, 4 ints of metadata in the video steam (width, height, depth, frame rate)? Not like we don't have the bandwidth. I can believe that, but it's disappointing that nobody bothered.
        TylerE 4y ago
        Historically speaking bad things happen when you hand a display something it can’t handle - including not being able to see the settings dialog to fix it.
- wasmitnetzen 4y ago
  Quite a few monitors support a Picture-in-Picture mode, so they are able to receive and decode two signals at the same time. But if that mode isn't enabled, they only receive one signal.
alin23 4y ago
Most of the delay is I/O bound. Handshaking happens over the Display Data Channel (DDC) which is a protocol over I²C (a two-wire comunication bus). HDMI/DP/DVI have 2 dedicated wires inside the cable for this, USB-C has to switch over to use differential signaling on pins A8 and B8, and then switch back after communication is done. The bandwidth of that bus is small indeed, but most of the latency comes from artificial delays and error recovery in code: monitor is sending a message to host then sleeping 30ms to make sure the reply is ready, host doing the same thing, and this happens multiple times to negotiate pixel clock, signal timing, colors, resolution, additional features like suspend/reset/HDR/overscan etc.) You can see how in the MCCS specification [1] both host and display entrypoints for communication start with a delay: https://shots.panaitiu.com/e8D7tQ https://shots.panaitiu.com/e8D7tQ You can also see how that looks in Lunar's DDC code [2] [3]. For now, it's incredible that we actually have such a standard as DDC and most monitors work with most devices. A coordinated effort between monitor vendors and laptop/PC/GPU manufacturers into creating another faster standard with modern technology seems out of the question. But maybe with the advent of Thunderbolt this may change in the future. [1] https://files.lunar.fyi/mccs.pdf https://files.lunar.fyi/mccs.pdf [2] https://github.com/alin23/Lunar/blob/master/Lunar/DDC/DDC.c#L407 https://github.com/alin23/Lunar/blob/master/Lunar/DDC/DDC.c#... : Delay on requesting data from monitor [3] https://github.com/alin23/Lunar/blob/master/Lunar/DDC/DDC.c#L449 https://github.com/alin23/Lunar/blob/master/Lunar/DDC/DDC.c#... : Delay on communication error before retry
- wzdd 4y ago
  Naively it seems like you could optimise this at least for the second and subsequent switches: you could detect if the cable corresponding to the input you've previously switched to has been reconnected since last switch. If it hasn't, then you could re-use the previous EDID values for the device. You'd obviously want this to be optional for special cases, but would that work, if implemented in a monitor or KVM? It's not so much the delay that's annoying, but the renegotiation with something which is so obviously the same device.
  - alin23 4y ago
    I believe that is already being done. As I said in my comment here (https://news.ycombinator.com/item?id=34049171 https://news.ycombinator.com/item?id=34049171) switching between two active inputs takes about 1 second for me. The problem that OP is facing is switching to an inactive input that went into power saving mode. In that case, the link between the inactive device and the monitor may have been broken and it's impossible to know if the device is the same as the one before after reconnection (with the same exact video settings etc.). This doesn't have to be the case though. Before I found out how to use I²C on Apple Silicon Macs, I was using a Raspberry Pi connected to an HDMI input of the monitor that could listen to DDC commands through an HTTP server: https://alinpanaitiu.com/blog/journey-to-ddc-on-m1-macs/#the-raspberry-pi-idea https://alinpanaitiu.com/blog/journey-to-ddc-on-m1-macs/#the... And because I didn't want that Pi Zero to get hot, I managed to only keep the DDC lines open and stopped the video signal from being sent using `vcgencmd display_power 0`. With those settings, the monitor still switched between inputs in 1 second, with the added small latency of having to run `vcgencmd display_power 1` (which was fast enough once it was automated to run on input switching)

What are the hardware limitations? Surely this is possible if there was investment and interest in making this work? Or do the protocols really not allow this?

by _rs 4y ago

What are the hardware limitations? Surely this is possible if there was investment and interest in making this work? Or do the protocols really not allow this?

chmod775 4y ago

In theory you could have a monitor that handles both signals all the time, buffering the output. Then it could switch immediately. It would however be more expensive, since you would need to duplicate at least some of the electronics within the monitor, a few of which also incur licensing/certification/patent/whatever fees.

yjftsjthsd-h 4y ago
Why would you buffer? Monitors are capable of playing full-screen video, which implies the ability to update every pixel once per... 30hz? frame, doesn't it?
- chmod775 4y ago
  Because when you want instant switching you need to already have the data you want to display available the moment someone flips the switch. You can't just tell the computer that you're now interested in the display data of the other display - that would incur latency. You'll have to be receiving the information for the second display the entire time, storing it in what is commonly called a framebuffer, aka a bitmap in memory somewhere. Most types of display have such a thing backing them anyways - one way or another - since they need to remember what they're supposed to display.
  - eurasiantiger 4y ago
    It’s ok, I can wait 17ms for the next frame.
    - chmod775 4y ago
      With basic analog you could set it up in a way where you would just wait for the next frame (or don't even wait that long), but with the new digital stuff there's bootstrapping/handshaking - whatever you want to call it. It's not so simple anymore.
      - lostdog 4y ago
        What could they possibly be doing that takes 4 seconds? That's ~4,000,000,000 instructions on a typical embedded processor. It's much more likely that the handshaking was implemented by an incompetent organization that doesn't care about quality.
        MichaelZuo 4y ago
        It is extremely odd to see so many people in this thread ignore that a handshake requires billions of instructions to be executed for some reason....
        eurasiantiger 4y ago
        One of the grandparents of this comment thread explicitly ignored it; this is a discussion on frame buffering.
  - yjftsjthsd-h 4y ago
    Okay, I'm willing to wait 1/30th of a second while the screen gets its pixels; is that not an option? Or is there no way to request all pixels and it doesn't send them all every frame?
    - chmod775 4y ago
      I don't think I understand what you're saying. I think you're concerned that because there's "buffers" there would be extra latency? There doesn't have to be.
      - yjftsjthsd-h 4y ago
        That's what I'm asking. When the monitor is live, it can draw a complete screen ~30+ times every second, so why does it take more than 1/30th of a second to start from nothing? Then, I speculated that the only reason I could think of was if the graphics card doesn't actually send every pixel every frame, and there's no way for the monitor to request a full refresh.
        TylerE 4y ago
        Monitors don’t request anything. The monitor has to do a basic handshaking/negotiation before it even knows what sort of video stream to expect
        yjftsjthsd-h 4y ago
        Ah. And we couldn't stick... What, 4 ints of metadata in the video steam (width, height, depth, frame rate)? Not like we don't have the bandwidth. I can believe that, but it's disappointing that nobody bothered.
        TylerE 4y ago
        Historically speaking bad things happen when you hand a display something it can’t handle - including not being able to see the settings dialog to fix it.
wasmitnetzen 4y ago
Quite a few monitors support a Picture-in-Picture mode, so they are able to receive and decode two signals at the same time. But if that mode isn't enabled, they only receive one signal.

alin23 4y ago

Most of the delay is I/O bound. Handshaking happens over the Display Data Channel (DDC) which is a protocol over I²C (a two-wire comunication bus). HDMI/DP/DVI have 2 dedicated wires inside the cable for this, USB-C has to switch over to use differential signaling on pins A8 and B8, and then switch back after communication is done. The bandwidth of that bus is small indeed, but most of the latency comes from artificial delays and error recovery in code: monitor is sending a message to host then sleeping 30ms to make sure the reply is ready, host doing the same thing, and this happens multiple times to negotiate pixel clock, signal timing, colors, resolution, additional features like suspend/reset/HDR/overscan etc.) You can see how in the MCCS specification [1] both host and display entrypoints for communication start with a delay: https://shots.panaitiu.com/e8D7tQ https://shots.panaitiu.com/e8D7tQ You can also see how that looks in Lunar's DDC code [2] [3]. For now, it's incredible that we actually have such a standard as DDC and most monitors work with most devices. A coordinated effort between monitor vendors and laptop/PC/GPU manufacturers into creating another faster standard with modern technology seems out of the question. But maybe with the advent of Thunderbolt this may change in the future. [1] https://files.lunar.fyi/mccs.pdf https://files.lunar.fyi/mccs.pdf [2] https://github.com/alin23/Lunar/blob/master/Lunar/DDC/DDC.c#L407 https://github.com/alin23/Lunar/blob/master/Lunar/DDC/DDC.c#... : Delay on requesting data from monitor [3] https://github.com/alin23/Lunar/blob/master/Lunar/DDC/DDC.c#L449 https://github.com/alin23/Lunar/blob/master/Lunar/DDC/DDC.c#... : Delay on communication error before retry

wzdd 4y ago
Naively it seems like you could optimise this at least for the second and subsequent switches: you could detect if the cable corresponding to the input you've previously switched to has been reconnected since last switch. If it hasn't, then you could re-use the previous EDID values for the device. You'd obviously want this to be optional for special cases, but would that work, if implemented in a monitor or KVM? It's not so much the delay that's annoying, but the renegotiation with something which is so obviously the same device.
- alin23 4y ago
  I believe that is already being done. As I said in my comment here (https://news.ycombinator.com/item?id=34049171 https://news.ycombinator.com/item?id=34049171) switching between two active inputs takes about 1 second for me. The problem that OP is facing is switching to an inactive input that went into power saving mode. In that case, the link between the inactive device and the monitor may have been broken and it's impossible to know if the device is the same as the one before after reconnection (with the same exact video settings etc.). This doesn't have to be the case though. Before I found out how to use I²C on Apple Silicon Macs, I was using a Raspberry Pi connected to an HDMI input of the monitor that could listen to DDC commands through an HTTP server: https://alinpanaitiu.com/blog/journey-to-ddc-on-m1-macs/#the-raspberry-pi-idea https://alinpanaitiu.com/blog/journey-to-ddc-on-m1-macs/#the... And because I didn't want that Pi Zero to get hot, I managed to only keep the DDC lines open and stopped the video signal from being sent using `vcgencmd display_power 0`. With those settings, the monitor still switched between inputs in 1 second, with the added small latency of having to run `vcgencmd display_power 1` (which was fast enough once it was automated to run on input switching)