DDC pins (was: DDC info refresh)
> I don't know which pin(s) it is. And it's been a while since I read > the description. But I as I recall, there is a pin that carries > digital data from the monitor to the computer. Memory is very fuzzy by > now, but I _think_ it's something like I²C slowed down by an order of > magnitude or two. As I recall, it's GND, the two I2C pins plus a power pin intended for the Computer powering the I2C EEPROM in the Monitor even if the Monitor is off. Regarding the power pin, it's like SCSI TERMPWR: It's clearly specified and utterly simple (only source it via a diode, power the terminator from it) but nearly every vendor gets it wrong in interesting ways.
Re: DDC info refresh?
On Tue, Apr 21, 2020 at 06:22:39PM -0400, Mouse wrote:
> > If I was working on this, I would aim for something like this:
> > - Report an event to userland upon a monitor hotplug.
>
> I've been investigating more, and it turns out all the infrastructure
> is there - there is already such an event defined by Xrandr. In 8.0 it
> doesn't actually work - the event isn't sent upon monitor connect or
> disconnect, at least not in the case of my test machine, but is instead
> delayed until some (other) client queries state - but there is no need
> to define a new event or a new event-carrying mechanism or any of that.
Most of this code in Xorg is dependent on udev, a systemd library.
It uses the same userland reports next to the code I altered to have a
netbsd equivalent.
Except the netbsd equivalent doesn't do anything with the events.
#ifdef CONFIG_UDEV_KMS
...
static void
drmmode_handle_uevents(int fd, void *closure)
{
...
if (changed) {
RRSetChanged(xf86ScrnToScreen(scrn));
RRTellChanged(xf86ScrnToScreen(scrn));
}
Re: DDC info refresh?
>> I've been investigating more, and it turns out all the >> infrastructure is there - there is already such an event defined by >> Xrandr. > Do you mean "monitor connected" or "DDC info populated" as the event? I meant "monitor connected", but "DDC info newly available" is perhaps closer to what is actually possible. >> In 8.0 it doesn't actually work - the event isn't sent upon monitor >> connect or disconnect, at least not in the case of my test machine, >> but is instead delayed until some (other) client queries state > I've always wondered about this. In my case, I've got some > superstition that having the VGA HD15 connector present when the > machine powers on has been needed in some cases. I always felt like > the DDC-getting mechanism was a bit of magic (which one of those pins > carries that data? I thought VGA was pretty much all analog...). I don't know which pin(s) it is. And it's been a while since I read the description. But I as I recall, there is a pin that carries digital data from the monitor to the computer. Memory is very fuzzy by now, but I _think_ it's something like I²C slowed down by an order of magnitude or two. >> but there is no need to define a new event or a new event-carrying >> mechanism or any of that. > So, in your experimentation are you able to connect the VGA HD15 to > the monitor after the system starts up, issue some xrandr command to > gather DDC, then reset your video mode with that updated timing? The sequence of my test was: - Disconnect monitor cable - Boot system - Start X - Verify (env DISPLAY=:0 xdpyinfo) that X started 800x600 and (env DISPLAY=:0 xrandr) that nothing higher-resolution is available - Start my RandR-using test program, which selects for RandR events using XRRSelectInput - Plug monitor in - Nothing happens - Issue xrandr command to query available options (no change specified) - My program gets events - That xrandr command reports 1024x768 and 1280x1024 available If I've understood your question correctly, that's a "yes". Of course, some aspects of this are likely to be hardware-specific; I daresay not all hardware can notice monitor connect/disconnect. Heck, there's probably hardware out there that can't even fetch DDC info from the monitor /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: DDC info refresh?
On Tue, 21 Apr 2020, Mouse wrote: I've been investigating more, and it turns out all the infrastructure is there - there is already such an event defined by Xrandr. Do you mean "monitor connected" or "DDC info populated" as the event? In 8.0 it doesn't actually work - the event isn't sent upon monitor connect or disconnect, at least not in the case of my test machine, but is instead delayed until some (other) client queries state I've always wondered about this. In my case, I've got some superstition that having the VGA HD15 connector present when the machine powers on has been needed in some cases. I always felt like the DDC-getting mechanism was a bit of magic (which one of those pins carries that data? I thought VGA was pretty much all analog...). but there is no need to define a new event or a new event-carrying mechanism or any of that. So, in your experimentation are you able to connect the VGA HD15 to the monitor after the system starts up, issue some xrandr command to gather DDC, then reset your video mode with that updated timing? If so, good! That's something I've definitely had order-of-operation issues with in the past. -Swift
Re: DDC info refresh?
> If I was working on this, I would aim for something like this: > - Report an event to userland upon a monitor hotplug. I've been investigating more, and it turns out all the infrastructure is there - there is already such an event defined by Xrandr. In 8.0 it doesn't actually work - the event isn't sent upon monitor connect or disconnect, at least not in the case of my test machine, but is instead delayed until some (other) client queries state - but there is no need to define a new event or a new event-carrying mechanism or any of that. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
[PATCH] Detect monitor hotplug, used for DRM drivers (was: DDC info refresh?)
On Fri, Apr 17, 2020 at 06:21:18PM +, m...@netbsd.org wrote:
> On Wed, Apr 15, 2020 at 02:23:19PM -0400, Mouse wrote:
> > It would also be enough if I could force the X server to run 1280x1024
> > whether or not it has a monitor connected. Under 5.2, I added options
> > to the X server, one to capture DDC info to a file and one to provide a
> > file to be read to provide DDC info if none could be obtained from the
> > monitor. This addressed the problem there. But, under 8.0, the use of
> > 1024x768 even with a monitor connected indicates to me that it's
> > getting DDC, or moral eqvuialent, from the kernel instead of the
> > monitor, so I am inclined to doubt the same approach would work. (I
> > can try it, certainly, but, based on the information I have now, that
> > seems like an investment of my time with a low expected return.)
> >
> > Comments? Thoughts? If there is something else that this depends on
> > that I haven't mentioned, just let me know.
>
> This feels like it'd be really hard to use.
>
> If I was working on this, I would aim for something like this:
> - Report an event to userland upon a monitor hotplug.
> Perhaps just "monitors changed, suggesting to re-probe" is fine.
>
> Currently, powerd/pmf look like good candidates for transmitting such
> events to userland.
>
> - Have a small script that maps a monitor setup to a preferred
> resolution/layout.
>
> In your case it will be "run this one hard-coded xrandr command".
> But in the long run we could use this to have very comfortable handling
> for scenarios where people connect another monitor.
With the attached patch I can write this script (would be nice if powerd
was something X could listen to, but it only allows one listener).
cat /etc/powerd/scripts/monitor_hotplug
#!/bin/sh
su fly -c "env DISPLAY=:0 /usr/X11R7/bin/xrandr --output DVI-0 --mode 1280x800"
And it'll actually pick the new xrandr choice on monitor hotplug.
# HG changeset patch
# User Maya Rashish
# Date 1587216560 -10800
# Sat Apr 18 16:29:20 2020 +0300
# Branch trunk
# Node ID 18ec6488132fa5746888cc0a3de3e9ff40f315d2
# Parent 3a4ebac1a7ae7a742b0cedb6a942e3cbd85256b5
Add a powerd event for monitor hotplug.
Now if you have powerd running and have a script named
/etc/powerd/scripts/monitor_hotplug
It will be executed on monitor hotplug.
diff -r 3a4ebac1a7ae -r 18ec6488132f sys/dev/sysmon/sysmon_power.c
--- a/sys/dev/sysmon/sysmon_power.c Thu Apr 16 15:58:13 2020 +
+++ b/sys/dev/sysmon/sysmon_power.c Sat Apr 18 16:29:20 2020 +0300
@@ -130,6 +130,7 @@
{ PSWITCH_TYPE_ACADAPTER, "acadapter" },
{ PSWITCH_TYPE_HOTKEY, "hotkey_button" },
{ PSWITCH_TYPE_RADIO, "radio_button" },
+ { PSWITCH_TYPE_MONITOR_HOTPLUG, "monitor_hotplug" },
{ -1, NULL }
};
diff -r 3a4ebac1a7ae -r 18ec6488132f sys/sys/power.h
--- a/sys/sys/power.h Thu Apr 16 15:58:13 2020 +
+++ b/sys/sys/power.h Sat Apr 18 16:29:20 2020 +0300
@@ -115,7 +115,8 @@
#definePSWITCH_HK_VOLUME_DOWN "volume-down"
#definePSWITCH_HK_VOLUME_MUTE "volume-mute"
#endif /* THINKPAD_NORMAL_HOTKEYS */
-#definePSWITCH_TYPE_RADIO 6 /* radio switch */
+#definePSWITCH_TYPE_RADIO 6 /* radio switch */
+#definePSWITCH_TYPE_MONITOR_HOTPLUG7 /* monitor hotplug */
#definePSWITCH_EVENT_PRESSED 0 /* button pressed, lid closed,
AC off */
#definePSWITCH_EVENT_RELEASED 1 /* button released, lid open,
AC on */
# HG changeset patch
# User Maya Rashish
# Date 1587216606 -10800
# Sat Apr 18 16:30:06 2020 +0300
# Branch trunk
# Node ID 3b62224d38ada8c0396699aaffe605e10ebc97e2
# Parent 18ec6488132fa5746888cc0a3de3e9ff40f315d2
Add monitor hotplug reporting for drm drivers.
Currently invoked by i915 and radeon.
diff -r 18ec6488132f -r 3b62224d38ad sys/external/bsd/drm2/dist/drm/drm_drv.c
--- a/sys/external/bsd/drm2/dist/drm/drm_drv.c Sat Apr 18 16:29:20 2020 +0300
+++ b/sys/external/bsd/drm2/dist/drm/drm_drv.c Sat Apr 18 16:30:06 2020 +0300
@@ -660,6 +660,16 @@
kref_init(>ref);
dev->dev = parent;
dev->driver = driver;
+#ifdef __NetBSD__
+ dev->sc_monitor_hotplug.smpsw_name = device_xname(dev->dev);
+ dev->sc_monitor_hotplug.smpsw_type = PSWITCH_TYPE_MONITOR_HOTPLUG;
+
+ ret = sysmon_pswitch_register(>sc_monitor_hotplug);
+ if (ret) {
+ kfree(dev);
+ return NULL;
+ }
+#endif
INIT_LIST_HEAD(>filelist);
INIT_LIST_HEAD(>ctxlist);
@@ -727,6 +737,9 @@
mutex_destroy(>master_mutex);
mutex_destroy(>ctxlist_mutex);
mutex_destroy(>struct_mutex);
+#ifdef __NetBSD__
+ sysmon_pswitch_unregister(>sc_monitor_hotplug);
+#endif
kfree(dev);
return NULL;
}
@@ -739,6 +752,10 @@
if (drm_core_check_feature(dev, DRIVER_GEM))
Re: DDC info refresh?
On Wed, Apr 15, 2020 at 02:23:19PM -0400, Mouse wrote: > It would also be enough if I could force the X server to run 1280x1024 > whether or not it has a monitor connected. Under 5.2, I added options > to the X server, one to capture DDC info to a file and one to provide a > file to be read to provide DDC info if none could be obtained from the > monitor. This addressed the problem there. But, under 8.0, the use of > 1024x768 even with a monitor connected indicates to me that it's > getting DDC, or moral eqvuialent, from the kernel instead of the > monitor, so I am inclined to doubt the same approach would work. (I > can try it, certainly, but, based on the information I have now, that > seems like an investment of my time with a low expected return.) > > Comments? Thoughts? If there is something else that this depends on > that I haven't mentioned, just let me know. This feels like it'd be really hard to use. If I was working on this, I would aim for something like this: - Report an event to userland upon a monitor hotplug. Perhaps just "monitors changed, suggesting to re-probe" is fine. Currently, powerd/pmf look like good candidates for transmitting such events to userland. - Have a small script that maps a monitor setup to a preferred resolution/layout. In your case it will be "run this one hard-coded xrandr command". But in the long run we could use this to have very comfortable handling for scenarios where people connect another monitor.
Re: DDC info refresh?
> have you looked at xrandr? Doh! Thank you. Yes, that does the trick nicely. I really should not have needed to have been told that. While I could bring xrandr itself into the (*severely* stripped-down) installed filesystem, I'd prefer to UTSL and make the appropriate code use the relevant API calls to get the same effect. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: DDC info refresh?
On Wed, Apr 15, 2020 at 2:58 PM matthew green wrote: > > have you looked at xrandr? you may be able to just run > xrandr --auto after connecting the display, or you can > explicitly ask for a mode with it with --output > --mode . > > > .mrg. IIRC xvidtune can query and set modes too
re: DDC info refresh?
have you looked at xrandr? you may be able to just run xrandr --auto after connecting the display, or you can explicitly ask for a mode with it with --output --mode . .mrg.
DDC info refresh?
I have a turnkey product I'm working on moving from 5.2 to 8.0, and I've run into a behaviour difference. I'm wondering how hard it would be to fix. I'm not sure whether this is more correctly fixed in the kernel or on the X side of things, hence the cross-post. Under 5.2, if I start the X server with no monitor connected, I get (in my test environment) 800x600; if I start the X server with a monitor connected, I get 1280x1024 (that's the monitor's native resolution, and is what the product is designed for). This is presumably due to a lack of DDC info in the former case. Under 8.0 whether the monitor is connected when I start the X server does not seem to make any difference; it's whether the monitor is connected at boot that matters. (I also get 1024x768, not 800x600, with no monitor connected, but I don't much care about that; I mention it only in case it's significant.) I assume this is at least partially related to the switch from text console to text-via-graphics console during autoconfig. What I'm wondering is what I need to do to get 8.0 to reread the DDC info post-boot. I don't care (much) about the text-via-graphics console; that can continue to run in whatever resolution it cares to. I'd even be happy to go back to text-mode console if it fixes the X server issues. What I want is for X to start in 1280x1024 if it has a 1280x1024 monitor connected at X server startup time, regardless of what may have been connected, or not, at boot time. It would also be enough if I could force the X server to run 1280x1024 whether or not it has a monitor connected. Under 5.2, I added options to the X server, one to capture DDC info to a file and one to provide a file to be read to provide DDC info if none could be obtained from the monitor. This addressed the problem there. But, under 8.0, the use of 1024x768 even with a monitor connected indicates to me that it's getting DDC, or moral eqvuialent, from the kernel instead of the monitor, so I am inclined to doubt the same approach would work. (I can try it, certainly, but, based on the information I have now, that seems like an investment of my time with a low expected return.) Comments? Thoughts? If there is something else that this depends on that I haven't mentioned, just let me know. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
