On Tue, Feb 25, 2025 at 04:54:11PM -0600 I heard the voice of
Quentin Barnes, and lo! it spake thus:
>
> That's what I gathered from the discussion of my implementation. I
> just didn't know about the bigger picture of its concept overall.
>
> I also didn't know if I had any errors of omission on my part where
> others' use cases might need additional variables.
'k, so what I'm seeing as the use is basically
* XRR_MONITOR_COUNT lets you see how many there are
* Looping over XRR_MONITOR_<num> for 0..COUNT and the
..._<num>_{WIDTH,HEIGHT,etc} pieces let you do whatever you're
wanting to do in the config.
* XRR_MONITOR_<name> lets you find the appropriate <num> if you want
to get something with a particular name. Assumption being that this
is an uncommon special case; mostly you'd just be looping over the
<num>'s or something.
If we were expecting that users would mostly be doing in
<name>-centric, we'd presumably want the WIDTH/HEIGHT/X/Y's to be over
there under the name. Instead of, or in addition to, under the
number.
It does feel a _little_ dirty having the <name>'s right there. Feels
a little cleaner to me if it were more XRR_MONITOR_NAME_<name> or
_NAME2IDX_<name> or something? (to be clear, that's very much "is
this worth considering", not "plz do this"; I have reflex inclinations
here, not strongly-held opinions)
Implementation-wise, seems reasonable. I'll think a bit on minor
wordsmithing in the doc, maybe add a bit of an example.
Remainder is more peripheral chattery.
> On Fri, Feb 21, 2025 at 08:19:28PM -0600, Matthew D. Fuller wrote:
> > [...] I guess we should check that it works right when you link it
> > into sshd.
>
> I'm not sure what you mean by linking it into sshd.
Oh, it was just an allusion to the xz backdoor; I hadn't looked at the
code, so who knows how sneaking it might be ;)
> > IWBNI we could do something smarter with MonitorLayout, [...]
>
> What I understand is MonitorLayout creates an abstraction of one or
> more aliases for new virtual "monitors" on top of slicing up what's
> a physical or virtual monitor.
More basically, it's just an "I'm the user, I'll _tell_ you what's
going on, and you don't get to decide something else is real". Maybe
something in your X stack leads to XRR giving you bad (or no) info,
and you just have to go ahead and supply it manually. Or even if it
"works", your sense of what a monitor should be for your setup differs
from what the X server thinkss. To pick a few random cases,
* You have an ultra-wide monitor (32:9 say) that works by presenting
two inputs and acts like 2 side-by-side monitors to the computer (so
XRR sees two 16:9's side by side), but you just want to consider it
one big monitor.
* Conversely, an ultra-wide monitor that _is_ a single input and a
single monitor, but you want to treat it like two 16:9's side by
side.
* You have 4 big bezel-less monitors in a grid on the wall, and you
want to treat them as a single monitor that's just twice as big
square.
* You're fiddling with Xnest or Xephyr and want to experiment with or
hack on multi-monitor stuff, so you want to slice up the window into
multiple "monitors".
Generally, just any time XrandR gives an answer other than the way you
want things. You're the user, you should get the final say. Of
course, for most practical day-to-day desktop situations, XRR _is_
giving the results you probably want, so you don't need to mess with
it.
> I couldn't come up with an modification of its approach that would
> allow reuse for my purposes.
But more to the point, it's just tricky because of the level
inversion. m4 defs are what's used to generate the config that gets
parsed, MonitorLayout is a thing you get from parsing the config. So
the only way to use what you've set there in the m4 is to parse the
config, then re-parse it with the override info. But if you're doing
that, you might need to be able to run it an arbitrary number of
times, not just twice, for things to converge. I guess we'd have to
just reparse it until we get the same resulting config twice in a row,
right? But then it might be unbounded, and you don't have a config,
you have an asymtotically-approaching-config, and somebody gets to
write up a really weird CVE...
> As you'll notice, I had to use a "pass:[​]" trick to get
> adoc to correctly parse "`n`" so it matched formatting of similar
> variables in the doc with a flexible component. If there's a better
> way, please let me know.
It's kinda weird. It sure seems like you _should_ be able to use the
unconstrained form with double ``'s, but that doesn't work either.
Must be a weird and annoying edge case in asciidoctor's parser, though
I couldn't find anything that looked like a smoking gun in their bug
reports. But there is a "normal parsing" form of the passthru macro,
so I've adjusted it a bit in my local branch. i.e., a construct like
XRR_MONITOR_pass:n[`n`]_WIDTH::
> So it sounds like `Makefile` is just a bootstrapping facade.
I think of it more as a wrapper script. Make (the program) may not be
what manages the build anymore, but make (the command you run) is
hardwired into all our fingers already anyway, and it's easy to just
make it go ahead and run the thing that actually does the build.
--
Matthew Fuller (MF4839) | [email protected]
Systems/Network Administrator | http://www.over-yonder.net/~fullermd/
On the Internet, nobody can hear you scream.
