From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Brian Cully Newsgroups: gmane.emacs.devel Subject: Re: master 3b41141708: Expose the name of an event's input device to Lisp Date: Mon, 11 Apr 2022 12:26:53 -0400 Message-ID: <87zgkry2u5.fsf@ditto.jhoto.spork.org> References: <164933858147.29834.15050766441005536059@vcs2.savannah.gnu.org> <87tub1kbkf.fsf@yahoo.com> <831qy58ofh.fsf@gnu.org> <87sfqlfomt.fsf@yahoo.com> <83wnfx77s0.fsf@gnu.org> <87o819e80r.fsf@yahoo.com> <83sfql73di.fsf@gnu.org> <87ee25cosj.fsf@yahoo.com> <83mtgt712o.fsf@gnu.org> <87r1659jey.fsf@ditto.jhoto.spork.org> <87v8vh845k.fsf@yahoo.com> <87mtgsyeg0.fsf@ditto.jhoto.spork.org> <87v8vg77vx.fsf@yahoo.com> <87ee24xuv6.fsf@ditto.jhoto.spork.org> <87pmlo5qgr.fsf@yahoo.com> <87k0bwe45v.fsf@ditto.jhoto.spork.org> <87r16448k0.fsf@yahoo.com> <87ee24z0wv.fsf@ditto.jhoto.spork.org> <87o8182o3i.fsf@yahoo.com> <874k2zzqim.fsf@ditto.jhoto.spork.org> <87zgkryamt.fsf@yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17171"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.6.10; emacs 29.0.50 Cc: larsi@gnus.org, monnier@iro.umontreal.ca, Eli Zaretskii , rms@gnu.org, emacs-devel@gnu.org To: Po Lu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Apr 11 19:01:56 2022 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 1ndxQI-0004BS-M2 for ged-emacs-devel@m.gmane-mx.org; Mon, 11 Apr 2022 19:01:55 +0200 Original-Received: from localhost ([::1]:53090 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ndxQH-0003S4-8l for ged-emacs-devel@m.gmane-mx.org; Mon, 11 Apr 2022 13:01:53 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:45446) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ndxMx-0006s7-SB for emacs-devel@gnu.org; Mon, 11 Apr 2022 12:58:27 -0400 Original-Received: from coleridge.kublai.com ([166.84.7.167]:61308 helo=mail.spork.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ndxMw-0004bf-02; Mon, 11 Apr 2022 12:58:27 -0400 Original-Received: from ditto (unknown [IPv6:2001:470:1f07:1b9:8650:a942:ec5e:856b]) by mail.spork.org (Postfix) with ESMTPSA id 18A8A3710; Mon, 11 Apr 2022 12:58:10 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=spork.org; s=dkim; t=1649696304; bh=GfIDxIKkcVZALvx7MUPRAuShYPQDRntcELPUD2A8EEk=; h=References:From:To:Cc:Subject:Date:In-reply-to; b=iOctlc10T6oky31EYble6jFk7ILUGZ33s2UaZoVqGcLpVg68BU9VOENNet1aPzvIL khIAkAGA8xlqR47Z2YFXlwJPA567wEfAuLAIuiV2LZXty8SqD4SN+/J03WemsaCfWU xov7LT/O1gj1AghzmIh4XKmTXYjFWaYgmLVp4INY= In-reply-to: <87zgkryamt.fsf@yahoo.com> Received-SPF: pass client-ip=166.84.7.167; envelope-from=bjc@spork.org; helo=mail.spork.org X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action 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:288228 Archived-At: Po Lu writes: > But I am not interested in what the Linux kernel, evdev and libinput > expose. Emacs cannot use their information when running under X. It seems to me that part of our disagreement stems from having approached this problem from two different directions: you are looking at it from the perspective of an X client, and trying to use the information available to you in that context to design a feature. I have been looking at it from the perspective of someone who makes input devices, and looking at what is possible from that end. Unfortunately, in the middle we seem to have hit a snag in terms of expectations around device naming. > The device path is only exposed by the libinput (or evdev) drivers > through driver-specific device properties. Trying to use those > properties is IMNSHO suicidial: they change at random and are not > guaranteed to be present everywhere. And what if Emacs is connected to > a remote X server, or the device information cannot be queried due to a > lack of permissions to open that device file, or the device information > is simply incorrect? These are fair points. I do not have a way to resolve them within the scope of a pure X client. > Nonsense. I will not try to argue this with you further, since you > simply don't understand or have never worked with anything other than a > GNU/Linux system running the latest release of the X.Org server. Please do not resort to ad hominem. You do not know my history. I, too, remember a time of hand coding XF86Config in the 90s, and I am thankful to be long past that. And, frankly, recollections of how things worked a quarter century ago are not particularly relevant in the face of contradictory evidence of how things work now. > It is long-standing behavior of the X input extension. It may have been long-standing in the past, but it does not stand today. No one uses MIT X11 anymore. Almost no one uses XFree86. Sun Microsystems has been gone for over a decade, and ceased to be a particularly relevant X environment many years before that. XQuartz borrows heavily from X.Org. Like it or not, X.Org is the de facto standard. If you are using Emacs under X, the odds are very much in favor of that being on a Linux kernel, using evdev, libinput, and X.Org. I am, by no means, suggesting abandoning support for other platforms, I am stating that you cannot ignore the behavior of the platform that is most in use because of a perceived bug on your part. > Anyway, if you want to incorporate the serial number and USB identifiers > into the classifications and names of input devices in Emacs, show us > the code, and it working with every X server on at least the Unix-like > platforms we currently support. I have never claimed to have a solution. At previous points I have said that I don=E2=80=99t think this is a thing that Emacs can solve by itself, and that device names are acceptable to me as a =E2=80=9Cgood enoug= h=E2=80=9D solution, provided it is end-user configuration that determines their event mappings. My issues in this thread are two-fold: 1) Device names cannot be counted on to be unique, and any design in Emacs that uses device names must take that into account, and, 2) Users should be informed that if they have multiple devices of the same type, then workarounds for various platforms may be necessary, such as udev rules on Linux. -bjc