Re: [dwm] snapping bugs with multiple screens

"Anselm R. Garbe" <arg_AT_suckless.org> wrote:

> On Sat, May 03, 2008 at 10:35:22PM -0400, John Li wrote:
> > I'm not sure if this qualifies as a bug, but I think it's
> > unexpected/non-optimal behavior.
> >
> > Example setup:
> > Laptop screen at 1024x768 with a separate LCD at 1280x1024 positioned on
> > the left of the laptop. Here's a geom for that:
> >
> > /* geometries, s{x,y,w,h} and bh are already initualized [sic] here */
> > /* name bx by bw wx wy ww wh mx my mw mh tx ty tw th mox moy mow moh */
> > DEFGEOM(desklap, 0, 0, 1280, 0, bh, sw, sh-bh, 0, bh, 1280, wh, 1280, 0, 1024, 768, 0, bh, mw, wh)
> >
> > I have the bar and master area confined to the first 1280 horizontal
> > pixels: the separate LCD. The master area is 1280x(1024-bh) while the
> > tile area is 1024x768. There are two unexpected behaviors related to
> > snapping in the tile area:
> >
> > 1) Snapping at the top doesn't snap to the top of the tile area, y=0; it
> > snaps to y=bh.
> > 2) Snapping at the bottom doesn't snap to y=768; it snaps to y=1024.
> >
> > Since I've defined ty=0 and th=768, this seems incorrect. I don't know C
> > very well, but it seems like dwm looks at only at the w? vars (and not
> > the m? or t? vars) to determine when to snap. Changing those would
> > result in wrong snapping behavior on either the master or tile areas,
> > though.
> >
> >
> > Another possible, vaguely related bug: there is no snapping on the
> > master/tile split (also the physical divide between the monitors).
> > Perhaps if mw is a constant, or doesn't include "mfact", there could
> > also be snapping here?
> >
> >
> > I know dwm isn't particularly concerned with heavy use of floating
> > windows, but I find them necessary at times (especially with higher
> > resolution, multiple monitor setups) so it'd be nice to see snapping
> > work in these situations.
>
> I can confirm your observation and it took quite a while that
> someone reported it. I expected it much earlier ;)
>
> The snap-algorithm uses wx, wy, ww, and wh as screen dimension
> boundaries. There is no support for multiple screens in the snap
> algorithm, so it is only intended to work correctly in a single
> screen setup or at least at wx and ww in multi screen setups.
>
> As a workaround I propose to disable snapping in multihead
> setups through setting it to 0.
>
> Proper snap-support would make dwm dependend from XrandR or
> Xinerama and I don't want to do that (or alternatively of yet
> another complex geometrie setup at compile time).

Is there a particular reason for this? I mean it would be the proper
naturally/intuitively expected behaviour, so adding a dependency (which
is of course bad from a suckless perspective) gives you a lot of
benefits (including simpler GEOM setups).
Let's do a poll!

> I see some potential to make SNAP a variable however, which
> could be set in DEFGEOMs for this reason.

Seems unreasonable. Why should you throw away information that is
provided by extensions which have to be present anyhow (in order to use
multiple monitors)?

Regards
Matthias-Christian
Received on Mon May 05 2008 - 14:12:40 UTC