[dev] [dwm] dwm breaks on synchronized screens

[Thomas Oltmann]

Hi everybody,

I've been contently using dwm for years without problems. But now that
I have to do regular beamer presentations, dwm just sort of falls
apart.

Since I need to be able to see my own presentation as I talk I've
configured XRandR to 'mirror' the screen (which means to always
display the same picture on both screens).

As soon as I do that, dwm starts to break.
Open windows don't show up in the tags at the top, some windows just
go missing entirely, or get shoved beneath other windows (in tiling
mode), etc.

I suspect that sort of behaviour isn't intended
(Though it might be and I'm just using it wrong).
Of course, dwm works perfectly fine when I
tell XRandR to manage the screens independently. I just can't work that way.

(Simply using presentation software that naturally outputs to both
screens is also out of the question since I often need to show
text editors, pdf viewers, terminals etc.)

What do I do about this?
Is it even a bug or just me using dwm for stuff it's not intended to do?
One way or another, how can I do my presentations without fighting the
WM all the time?

Cheers,
  Thomas Oltmann

Re: [dev] [st] wide characters getting cropped

[NRK]

On Thu, Nov 11, 2021 at 05:31:15PM +0100, Страхиња Радић wrote:
> (for example, if a simple "cat /some/file" for a multi-line text file
> has a delay anywhere from 500 ms to a second or two between the output
> of individual lines, when not dependant on factors such as reading
> from a network of a faulty hard disk; that would just be annoying, but
> still usable).

You're correct, cating some file is not something that needs critical
speed. But that's not what I'm talking about when I say "latency".

I'm reffering specifically to "input latency" or "end-to-end latency",
which is the delay between a physical input (in this case key-press on
the keyboard) and it's output (in this case the key-press being
rendered).

- NRK

Re: [dev] [st] wide characters getting cropped

[Страхиња Радић]

On 21/11/10 08:55, NRK wrote:
> I wouldn't say it's "critical need". And if we judge from that pov then
> one could ask, "What's the critical need for a dynamic window manger or
> minimal softwares in general?".

Terminal emulator's job is to allow terminal input/output. Latency is simply not
relevant, unless it is noticeable by a human (for example, if a simple "cat
/some/file" for a multi-line text file has a delay anywhere from 500 ms to a
second or two between the output of individual lines, when not dependant on
factors such as reading from a network of a faulty hard disk; that would just be
annoying, but still usable). st doesn't have such issues, so anyone experiencing
them should look for the cause elsewhere (Xft/fontconfig?).

Also, the need for "minimal software" is not comparable to the "need" for "low
latency" in a terminal emulator. The former is a fundamental concept, while the
latter is superficial.

> XTerm has many (visible) problems. Maybe I've misconfiuged it, but I
> cannot get it to fallback to other fonts reliably, and thus some glyphs
> don't render. It also chokes badly when it tries to render some unicode
> glyphs for the first time.

If you refer to color emoji or Nerd Font symbols, they are poorly supported in
X, and I'd even say they are bloat by themselves. But it is to be expected of
XTerm to have problems. To quote https://st.suckless.org,
> xterm is bloated and unmaintainable. Here's an excerpt from the README:
> 
> Abandon All Hope, Ye Who Enter Here
> 
> This is undoubtedly the most ugly program in the distribution. It was one
> of the first "serious" programs ported, and still has a lot of historical
> baggage.  Ideally, there would be a general tty widget and then vt102 and
> tek4014 subwidgets so that they could be used in other programs. We are
> trying to clean things up as we go, but there is still a lot of work to
> do.
> 
> Needless to say things have not changed, it's still ugly. It has over 65K
> lines of code and emulates obscure and obsolete terminals you will never need.
> 
> The popular alternative, rxvt has only 32K lines of code. This is just too
> much for something as simple as a terminal emulator; it's yet another example
> of code complexity.
> 
> Terminal emulation doesn't need to be so complex.


signature.asc
Description: PGP signature