Re: DDC info refresh?

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>> It would also be enough if I could force the X server to run
>> 1280x1024 whether or not it has a monitor connected.  [...]
> This feels like it'd be really hard to use.

As a general-purpose facility, maybe so.  It would not be intended for
general-purpose use; it would be intended for this one turnkey
application's use.

> If I [were] 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.

That probably could be used for it, but it would be annoying to have to
pull powerd and friends into the installation root just to handle this,
especially when xrandr and relatives indicate the presence of
underlying APIs that can do what this application wants much more
directly.

I also strongly feel that abusing powerd to handle non-power-related
events is a very wrong tack to take.  (Even as far back as 5.2, I find
it appears to be handling a number of non-power events; I think it
really should be renamed to something more like sysmond.)  What I see
in powerd(8) are all self-monitoring events, at least; adding monitor
hotplug I really think does not belong there.  (Personally, I would
make it an X extension event, possibly driven off a wscons event for
servers running atop wscons.  Maybe even an Xrandr event.  Using powerd
just because it's there makes about as much sense to me as implementing
it as a fake tty device, generating input on the relevant events,
simply because you have a tty framework.)

I also think that adding it to powerd, even if it is renamed to eventd
or whatever, is loading too much into a single program.  That way lies
the likes of dbus and systemd.

I've already looked at using the APIs used by xrandr.  The
documentation is...well, I initially wrote "abysmal" but the truth is
more like "poor"; Xrandr(3) does exist and answers some of my initial
questions, though I have had to go under the hood and look at the
implementation to resolve a number of important questions Xrandr(3)
doesn't address at all.  Aside from that, though, it looks promising.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B