That way we won’t have this window shuffling nonsense that has plagued multi monitor setups since we started putting pcs to sleep instead of turning them off.
That way we won’t have this window shuffling nonsense that has plagued multi monitor setups since we started putting pcs to sleep instead of turning them off.
Also, "Hey monitor, here's a frame in a new resolution" "Right away, ma'am, I just need to wait 30ms for the next refresh and your content will be visible"
Modern display management is... well, it's just absolute garbage. We don't tolerate it when our storage devices or graphics cards take 3+ seconds (seconds!) to respond. Why are we OK with the display? I mean, some amount of delay and synchronization for some things is inevitable, but this subindustry has just gotten completely out of hand.
I think FreeSync somewhat alleviates that. But of course Nvidia doesn't agree to do it the same way. I do agree that video latency is atrocious. It takes longer to do a screen refresh than to send an ethernet packet across the country!
Well you do need to consider (according to my naive estimated calculations) that:
a 1920x1080 picture is worth 4000 ethernet packets.
Eh? There's no shortage of monitors with well under 10ms of signal to photon latency: https://www.tftcentral.co.uk/images/gigabyte_aorus_ad27qd/la...
That's processing time + pixel response time measured across a handful of monitors. None of them are higher than 9ms. I have no idea where you got 30ms from? Or even what you're talking about at all. Are you exclusively talking about bottom of the barrel monitors here? Even IPS panels are being driven at 144hz these days and adaptive vsync is increasingly everywhere. Nobody is tolerating being slow?
No, it doesn't. I missed that they were talking about mode switch, but if the mode switch happened in 9ms the OP's example doesn't work anymore because the switch becomes faster than refresh rate.
2019 and one still has use the display's buttons to control settings, unless it is a laptop's fixed display.
Edit: DDC/CI to be precise, introduced in 1998: https://en.wikipedia.org/wiki/Display_Data_Channel#DDC/CI
As noted in discussion, Luminance VCD while worked for my monitors, backlight level 0x6B or legacy 0x13 would be better choice.
It then can be used by instantiating it at proper I²C monitor bus, e.g.:
insmod ddcci_bl.ko
modprobe i2c-dev
echo ddcci_bl 0x37 > /sys/bus/i2c/devices/i2c-2/new_device
(oh, and it now over 2 years and I still haven't got time to integrate it with DRM display hotplug so it could be upstreamed :(Thanks!
[1] https://github.com/prashnts/dotfiles/blob/master/etc/hammers...
[2] https://github.com/kfix/ddcctl/blob/master/README.md
Edit: Just noticed further down in the comments that an app exists for it now!
Sometimes I can't get to them at all on the laptop screen without forcing it closed and reopening.
The regular [win] + [left/right] for snapping to 1/2 screen positions will also move it across screens if you hit it repeatedly.
Sadly MS figured we all wanted to have to shit move around as soon as you use a KVM.
(Also, there's usually a 90% chance that windows will not correctly handle the monitor reconnecting without having to either power cycle the monitor or using the video card's 'really truly scan for monitor changes' feature.)
[0]: https://superuser.com/questions/630555/turning-displayport-m...
NVIDIA firmware update [0] solved the problem for me. It seems they ditched the naughty part of DisplayPort standard for good and stopped passing hot-plug events to OS.
Waking from sleep will periodically just not find a monitor at all, or they will come up with the wrong positioning (left and right swapped). If I turn a monitor off, the other one (and the laptop) do some sort of resync operation that interrupts the display. It's annoying, but not something I would expect the industry to consider a priority; I'm not really sure it's a monitor issue at all.
So yeah, it's better than when off really meant off and ports lacked cable detection.
Don't think it's the hardware that's pushing 20-80Gb/s through 10ft of cable causing the issue... they don't specify OS/driver interactions. They just report available resolutions/rates in their PID and display on SleepOut command from the host register/packet interface.
I wonder if at least part of this is for DRM reasons, because having an always-on and "unauthenticated" video signal output does tends to frighten those IP control-freaks.
I do agree with all the others here that the time newer monitors take to sync to the signal is horribly long. CRTs and some older LCDs were basically instant (although the latter would sometimes auto-adjust on signal changes, meaning a slightly unstable display, at least it was still somewhat readable and visible --- crucial for reading things like BIOS screens, for example.)
Probably not, DVI has hot-plug.
I fully understand that tiling WM are not and will never be mainstream, so finding a general solution would be desirable, but I guess for a tech-savvy crowd like HN I want to proselytize tiling WMs a bit. Every time I have to use a regular "hey here are a stack of overlapping windows, have fun" destop I'm genuinely frustrated. It's nice when you're working on a new flow with new apps you're unfamiliar with but once you've got your development "stack" figured out I couldn't imagine coding in an environment where I can't switch to my editor, terminal, browser with a single non-context sensitive command, regardless of where I am.
I suppose just having virtual desktops can be a decent enough compromise (put your editor in a virtual desktop, your browser in an other etc...) but as far as I know even that is relatively uncommon outside of linux DEs.
You can imagine what that does to my windows ;-)
You also have to do this with certain desktop streaming solutions if the host PC doesn't have a display. You can buy fake HDMI connectors that are just a cap over the HDMI port to trick the video card into thinking there is a display attached.
I don't know how DP does it but previously there was a good old I2C link in the cable that was used to figure out what the screen supported[1]. You only needed an I2C EPROM on the other hand containing the various modes. Without this the computer on the other end can't really prepare itself properly, preallocate the framebuffers etc...
Since the EPROM requires very little energy it might even work if the monitor is not powered, just using the +5V coming from the HDMI cable.
I still have to move them back once in the morning when I unhibernate, but it's better than 5 times a day.
It would be really great if someone could figure this out.
gsettings set org.cinnamon.settings-daemon.plugins.xrandr active false
EDIT: apparently not anymore, but there's another solution: https://github.com/linuxmint/Cinnamon/issues/6646EDIT2: per this PR, you should be able to disable it in the configuration panel: https://github.com/linuxmint/cinnamon-settings-daemon/pull/1...
What you're complaining about is entirely a software problem. No improvements to display standards will move the situation forward.
By the way, if you're using Linux, consider switching your desktop environment.
Now, if only we could convince PC graphics manufacturers to support CEC instead of ignoring it. It seems the only people who do care are the little set-top boxes that run Nvidia Tegra or Qualcomm chips.