From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 12002 invoked from network); 21 Dec 2021 03:16:50 -0000 Received: from 4ess.inri.net (216.126.196.42) by inbox.vuxu.org with ESMTPUTF8; 21 Dec 2021 03:16:50 -0000 Received: from mimir.eigenstate.org ([206.124.132.107]) by 4ess; Mon Dec 20 15:35:18 -0500 2021 Received: from abbatoir.myfiosgateway.com (pool-74-108-56-225.nycmny.fios.verizon.net [74.108.56.225]) by mimir.eigenstate.org (OpenSMTPD) with ESMTPSA id 4e71a312 (TLSv1.2:ECDHE-RSA-AES256-SHA:256:NO) for <9front@9front.org>; Mon, 20 Dec 2021 11:34:40 -0800 (PST) Message-ID: <9A97E4DBF184349630D38FE6DDD4A21B@eigenstate.org> To: 9front@9front.org Date: Mon, 20 Dec 2021 14:34:38 -0500 From: ori@eigenstate.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: webscale open-source out-scaling-based realtime-java-aware shader software Subject: Re: [9front] Re: hidpi Reply-To: 9front@9front.org Precedence: bulk Quoth Noam Preil : > > >> are you sure though that we need to do this on devdraw level? > > > > Not really sure to be honest, I only have a rough idea about libdraw or > > how to exchange configuration options. At least in plan9port there is > > also the new q(1d) command to query DPIs and 9fans.net/go/draw uses it > > as well. I wonder whether this could be realized by just using > > environment variables instead of configuring this through plan9.ini/the > > result of q1d in drawterm. > > I think env variables are the wrong approach, at least in terms of ideal > future behavior. With (hypothetical future) multimonitor support (or a > short-term hack binding in a second machine's /dev/draw) you'd want > per-monitor DPI configuration---i.e. if you start a program on one > monitor, then move it to the other (with a /dev/draw shim which can be > attached and detached from specific backends, and multiplexed, etc), DPI > should change. > > I think devdraw is thus *exactly* where this information belongs, as DPI > is dependent on the monitor, and that information is in devdraw's domain. > > - Noam Preil > Yes, but not in the draw device itself: /dev/draw/geom which presents a sequence of numbers, 6 to a line, representing the screen rectangle in size and pixels; each line represents one monitor. libdraw and other programs that care can read this.