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