Hacker News Reader

Comment by ajross | Hacker News Reader

Also, "Hey monitor, are you there?" "Yes, I just got power, give me another 100ms for the backlight capacitors to charge and your content will be visible"

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.

View on HN

I wish there was a way just to actually manage the display settings from a computer. Brightness, contrast, ...

2019 and one still has use the display's buttons to control settings, unless it is a laptop's fixed display.

there's ddc, which has existed for a long time. It even worked back in VGA days. I automated some stuff with bash scripts and ddcutil on Linux.

Edit: DDC/CI to be precise, introduced in 1998: https://en.wikipedia.org/wiki/Display_Data_Channel#DDC/CI

It can be also exposed as kernel backlight device, then standard laptop GNOME/KDE brightness widgets just work.

How does one do this? On my desktop I currently use the ddccontrol and gddccontrol packages, but it would be awesome if the backlight slider existed the same as on my laptop.

There is simple driver: https://lore.kernel.org/patchwork/patch/753233/

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 :(

Under Windows this is what I use https://clickmonitorddc.bplaced.net to change such things.

This is great, thanks for sharing!

You are welcome. I just yesterday found about about this which updates most nVidia cards so that when the monitor in a multiple display setup are turned off all the windows on that screen do not get moved to the main screen.

https://www.nvidia.com/object/nv-uefi-update-x64.html

Holy crap! This has been one of those things I've been wanting for so long!

Thanks!

Thank you! This works great! Another app for my list of portable tools.

There's ddcutil for linux and this app for macOS

https://github.com/the0neyouseek/MonitorControl

My early-2000's Apple DVI displays support software brightness controls. Is that some proprietary feature that still hasn't been added to the general protocols?

On Mac, I wrote a config [1] which uses `ddcctl` [2] cli tool to sync both brightness and volume using keyboard buttons. It worked quite well, although I haven’t used it for a while. I guess similar idea could be extended for linux too.

[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!

> 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"

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!

Does Freesync make switching monitor resolutions faster..?

No, it does not. Freesync just allows for variable refresh rates.

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

What I hate is the instant power saving of most displays. You try to reboot and see some BIOS info or even the key to enter ... and you end up booting the OS because the display is too slow.

And why do all monitors display a message, usually on a bright white background, saying they are going into power saving mode shortly when the connected device is turned off?

I doubt they'll ever fix it. Setting a timer is among the hardest problems in computer science.

> 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"

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?

You skipped the "in a new resolution" part. I'm talking about mode switch time. Change resolutions or swap an input on your monitor and watch it dance for a few seconds trying to "resync" in a digital environment where AT MOST you need to wait through one frame of data to find the right timings.

For some reason most if not all screens even cycle their backlight when switching modes.

Yeah, the fact that it's not a single frame but, in fact, like 1 to 3 seconds to switch resolutions is absolutely insane. Trying to watch a PC bios boot on my new-ish monitor is an exercise in frustration—it spends more time off than on!

what are you walking about? OP just used 30 ms as example, replace it with 9 ms or 3 ms or whatever the example of a new resolution from OP still works..

> replace it with 9 ms or 3 ms or whatever the example of a new resolution from OP still works

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.

In an ideal world it would only take one frame to switch resolutions, and even if the frame time is usually 16.66ms, it is sometimes faster than that. Since mostly what a monitor needs to do is resample the image from the source resolution to destination resolution, and possibly composite in the UI for adjusting the settings, it seems quite possible to implement. I'm sure if we actually looked at what all the layers are doing (X, video drivers, PCIe commands, etc) then we would probably be pretty horrified. Hacks and work-arounds and backwards compatibility at every level.

Reply on news.ycombinator.com