From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: master e37eb7f: Add support for pixel wheel deltas on NS Date: Fri, 26 Nov 2021 13:32:08 +0200 Message-ID: <83r1b32lvr.fsf@gnu.org> References: <20211125030922.2353.1129@vcs0.savannah.gnu.org> <20211125030924.7258E2094B@vcs0.savannah.gnu.org> <871r34h6pi.fsf@gmail.com> <87fsrkzfq1.fsf@yahoo.com> <83tug05whz.fsf@gnu.org> <87tufzycli.fsf@yahoo.com> <837dcv4e79.fsf@gnu.org> <87wnkvflk7.fsf@yahoo.com> <83zgpr2uvr.fsf@gnu.org> <87fsrjfeb1.fsf@yahoo.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25827"; mail-complaints-to="usenet@ciao.gmane.io" Cc: rpluim@gmail.com, emacs-devel@gnu.org To: Po Lu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Nov 26 12:33:01 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mqZTQ-0006UZ-SD for ged-emacs-devel@m.gmane-mx.org; Fri, 26 Nov 2021 12:33:00 +0100 Original-Received: from localhost ([::1]:50008 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mqZTP-0000Pi-9S for ged-emacs-devel@m.gmane-mx.org; Fri, 26 Nov 2021 06:32:59 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:53668) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mqZSX-0007WA-2J for emacs-devel@gnu.org; Fri, 26 Nov 2021 06:32:05 -0500 Original-Received: from [2001:470:142:3::e] (port=35510 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mqZSW-0004D9-P8; Fri, 26 Nov 2021 06:32:04 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=ewpB5Ry0nprTOAsmz5VXz1jLSoj219IMZ/tjaB3ThX8=; b=eGohEBkMHLZJ yf2KXiUfBTtiWRga7RxKQsNHJwMqYS4LWowIci4EkFuyWLo0XLAB4WjajihxGmWBK+7JfeAqGkozu YIQ0YhOvdsPiG68li5hjnKWt0w2Zi9s/PaAuNzNDkWRukco0B+CNPNC33S6Kr+xQwh9DOYCF4E9EE wv3rPzAafZ9jRdznGYsmZO/PIE81bmSgnqHBV/5dLXFdi5zsUlDt945dHYyUq/pyGbx+1bESmoMPW HxMh1U979ABVK73T9ry5jm8ERHdAXn+K1NWCyDgyldeg6im6eSLa4hlisw1yLXDwyOopp8jcaIZlc 2pNKfy877DqQxcfFLXFfIQ==; Original-Received: from [87.69.77.57] (port=1510 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mqZSW-0002rc-Ff; Fri, 26 Nov 2021 06:32:04 -0500 In-Reply-To: <87fsrjfeb1.fsf@yahoo.com> (message from Po Lu on Fri, 26 Nov 2021 17:37:22 +0800) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:280218 Archived-At: > From: Po Lu > Cc: rpluim@gmail.com, emacs-devel@gnu.org > Date: Fri, 26 Nov 2021 17:37:22 +0800 > > Eli Zaretskii writes: > > > How to compute the amount of pixels for a given amount of wheel delta? > > I don't know, but I will try to ask some people I know who know > something about this. Thanks. But if this conversion is arbitrary (see below), I think I know how to implement the MS-Windows version of "arbitrary". > > The wheel delta on MS-Windows is reported in abstract units, not > > directly related to any pixels, AFAICT. I don't see the logic of the > > conversion to pixels documented anywhere in the X or NS code, and the > > comments, such as they are, make no sense at all to someone who knows > > nothing about X mouse-wheel handling. In xterm.c, it seems like some > > kind of query of the device "valuators" (whatever that is) is being > > used? > > On X, the states of the mouse wheels in each axis are stored as absolute > values inside "valuators" attached to each mouse device. To obtain the > delta of the scroll wheel from a motion event (which is used to report > that some valuator has changed), it is necessary to iterate over every > valuator that changed, and compare its previous value to the current > value of the valuator. > > Each individual valuator also has an "interval", which is the amount you > must divide that delta by in order to obtain a delta in the terms of > scroll units. > > This delta however is still intermediate, to make driver implementations > easier. The XInput developers recommend the following algorithm to > convert from scroll unit deltas to pixel deltas: > > pixels_scrolled = pow (window_height, 2.0 / 3.0) * delta; All of this should be in comments in xterm.c. Btw, the code calculates pixels_scrolled when it is not yet clear that the value will be used, which is a waste of cycles, AFAICT. How about moving this closer to where the value is actually used? In any case, are you saying that the conversion to pixels is somewhat arbitrary? And that users of X based systems have no control on this conversion, i.e. users cannot determine the pixel equivalent of each "delta"? > > And on NS, it seems like the delta is already reported in pixels? > > Yes. The PGTK port can do something similar if it gains support for > this, as GTK also reports it in pixels directly. Same question here: do users have any system-wide control on the conversion to pixels under these environments?