From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Po Lu Newsgroups: gmane.emacs.devel Subject: Re: master 3b41141708: Expose the name of an event's input device to Lisp Date: Mon, 11 Apr 2022 13:20:01 +0800 Message-ID: <87o8182o3i.fsf@yahoo.com> References: <164933858147.29834.15050766441005536059@vcs2.savannah.gnu.org> <83o81a8qnd.fsf@gnu.org> <87zgkulbuu.fsf@yahoo.com> <83ilri8iag.fsf@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> 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="12566"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.91 (gnu/linux) Cc: Eli Zaretskii , rms@gnu.org, larsi@gnus.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Brian Cully Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Apr 11 07:22:04 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 1ndmUz-0002yW-Pd for ged-emacs-devel@m.gmane-mx.org; Mon, 11 Apr 2022 07:22:01 +0200 Original-Received: from localhost ([::1]:50230 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ndmUy-0005xd-D9 for ged-emacs-devel@m.gmane-mx.org; Mon, 11 Apr 2022 01:22:00 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55878) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ndmTJ-00059a-0T for emacs-devel@gnu.org; Mon, 11 Apr 2022 01:20:17 -0400 Original-Received: from sonic301-30.consmr.mail.ne1.yahoo.com ([66.163.184.199]:45372) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ndmTF-0000wg-L0 for emacs-devel@gnu.org; Mon, 11 Apr 2022 01:20:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649654411; bh=QUgxbn88bBjRML2KilBvHBLGQwjz2FaBlkrC8QWW3KQ=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From:Subject:Reply-To; b=LfKh87FoQ9R1HEC3UqBtJ8Kmyt+WxtYw5I092m9K9ao3jqPQQCqjvjVyNhEQDmzL2CwyX/sYii/CEN4ScIM/LuU4H6fqg+QFQidepvZE2PyaoRnTWJ89Nga22mU7VmPYLsuhNxLjM9Cg3EBYGiyNX10Z8K6J7ntQfwr/ta13qbH5IvRE7CCx6bBhxvElOXG/i89cjYsD2CmKAHKUIwOrP2/caamylzBumExeaSKPNFvA0Amut9Ivk4hvsgzIJHFnCLlJ1HzbtNhmr2Xe5z2+/s6vb8FII3cQA8JjaVIeVw61FDTPAh/dfxElfxTxrE0yet0NIIUG+8bnj2IRS1oshQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649654411; bh=D7SaWCTZG012GafnJhleCNoPoFgKsQ2uH/nQsCs6w2x=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=I1J5MBqEOAiiWW+Cl3kztnNCeJUqTQA5k3Vu1FO4oha9Xg3b4i9UkT9gA60x4lV6K1fQQaMpqOP2rR3TwOKuAHHXqTqEMB4o2VKm2c1P1YZRm19g5n/tjWWG8aQYDJ8NZLOS40Dth3ch7y5nMyL94+WZE2LlZx6mbmz+O8RaHs5+SShFw4lfrc6VlgniB66m0M3NNAwmdK3ZrMB8BWTXpvhUpi2tnmzxmSXSgRtjy/mVORFYShZBwjeLrJwsouxC3AW3FLNA3/zKd81rAdgLtAca76RpjsSCfwi/icVrPSQFgeC2y46teBJAYARlSRc4ytMKz5KbpNOlv9iEt20hXQ== X-YMail-OSG: MEhAR_oVM1l8She7r6wOj91e8EZKhaquLTBfB6tvNuRS09aJdUfEuvu0fM4vMZ_ VCXq5.HVJzp0kvSVWLpwMm4_7bj2uD15K4BR6_EzJk9FqkmDlVbVlRZyVGRkpmXFPgvPrcywaCDl obsKIaKWHVgyjqM9zpp0gGe.uSKiLSExBYpBovaXRZDSe3AhEXE8mae_Rxhl8BI1YNgajad3JqdH RSyNAQs.E9l1BJahq6mSFOfuz.qVipmBR3jG2r.q49bOBRDSWaQGQ_ATulZw8xHf_ez007BYB._v P2ZwBdmIcsaY8.zyptCZhZuIaLkDH79sjNWjFC3mfeydZKTZE9w.Gg_4dkrQd_arHpxTIWZkT9yq 4cclavrPAUJ6vKZSpGvBmKEgzip6.eLPbNmhdcGf5gHyLHS7XWpxAxphJD8V.xBHPzWon18hOSdD _n3prBpxZZRX82y8MjIJE_BalDwB9x6CJMvHeSSEIQlDg1Ua0RrS002Dl08HcNrB7HKDVYUOX8AQ L.ZqdzlsTxRSeVzWB_mQMRkkbsoSK3DphVUEv18_gF2JnG0UxHo.wzwZezA4_DN9VOpulb.MstKn bOUSveQNfbnFl_0ccIT6fDpV4AMf2pqI_5gYpqMSsXhHyv8plDyfdCY0_kRB0l53wrsMRZ_Tueei 4uSnIgF5H.pUsWNthbZdLlL0IJu.N0qzEidjPL9jSzRvG3Bgb_YIEMeO4oPQsE.pHjxP0SpBlKro sg.K9z8KtKUnKr8Jh_hBYK9XyUs00BgIiKRUmGmbHiJW7Gl3xvmhL1vpi3h.x4TLnJ6qAkCmc7LW 7RHjS7aNvmK23sUbkrUKvrq7jvzAKNtrHZrQEylOI9 X-Sonic-MF: Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.ne1.yahoo.com with HTTP; Mon, 11 Apr 2022 05:20:11 +0000 Original-Received: by hermes--canary-production-sg3-65d7bd97b5-8hnzk (VZM Hermes SMTP Server) with ESMTPA ID 739220a38d8059f5d5a690a986336da6; Mon, 11 Apr 2022 05:20:06 +0000 (UTC) In-Reply-To: <87ee24z0wv.fsf@ditto.jhoto.spork.org> (Brian Cully's message of "Mon, 11 Apr 2022 00:11:48 -0400") X-Mailer: WebService/1.1.20048 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Received-SPF: pass client-ip=66.163.184.199; envelope-from=luangruo@yahoo.com; helo=sonic301-30.consmr.mail.ne1.yahoo.com 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=unavailable 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:288173 Archived-At: Brian Cully writes: > I do not understand why libinput would show one device name, yet > X shows another for you. From what I can tell, there is a direct chain > of unmodified names that goes all the way from the kernel, through > evdev, through libinput, and up to X. Well, no. > My input driver is bog standard. Why do you claim there is a > bug? Is it documented somewhere that the kernel, evdev, or libinput will > present unique names? I have not found such documentation, and I have > found a number of code paths that make no effort at all at making names > unique. "Input driver" is not at all related to the Linux kernel, evdev, or libinput. It means a driver for the X server. The X server must produce unique names for each device. That task is delegated to the device-dependent layer (in this case, xf86-input-libinput.) The input extension has provided unique names for each device since its adoption by most X vendors in the early 1990s, before Linux, evdev, HID devices, Bluetooth and Steam controllers even existed. It has also never provided any more information such as serial numbers and "bluetooth IDs", since they are not reasonably portable, and did not even exist when the input extension was first designed. There was once a separately specified "input class", but that died alongside the X Consortium, and is no longer present in version 2 of the input extension. Hotplugging is also a new feature on X. Before that, people configured input devices manually, and the X server did not allow you to have multiple devices with the same name. Also, X to this day runs on many kernels other than Linux. Each with their own supported devices, each with their own mechanisms for retrieving information from devices. This is why it does not expose any Linux, or Solaris, or MS Windows, or VMS specific concepts related to "input device" anywhere. > We may have different definitions of =E2=80=9Cself describing=E2=80=9D h= appening > here. Joysticks and Gamepads have explicit usage IDs in the Generic > Desktop Page of the HID Usage Tables. While they present relative motion > like other devices, they are tagged by the USB in order to differentiate > them. Please tell me how Emacs can obtain the "explicit usage ID" from the "Generic Desktop Page" of the "HID Usage Tables" from the X server, which does not expose any USB or other low-level device information to Emacs and other clients. > Most of the commonly used devices have usage table definitions > which adequately describe how they function. But of course there is a > limit to what is even possible to describe automatically without user > intervention. Foot pedals are a good example; they tend to have unique > uses based on their users, and as a result their users are expected to > configure them. It is reasonable for Emacs to do this. > > However, what happens when you plug in two pedals of the same > make and model and they have the same name? You say this is a bug, and > that I lose, but I need to see *why* that=E2=80=99s a bug. In the mean ti= me, > there are other identifiers I might be able to use other than the name, > like the serial number, or Bluetooth device ID, why should those be off > limits to my ability to configure them in Emacs? Because the X server does not provide the serial number, Bluetooth device ID, it only provides the name, which has always been unique to each device. > I would suggest, if we go this route, that the device comes with > more information than a name, or can at least be probed, so that I can > determine which information to use, such as the serial number. The X server does not provide any of that information. > My point is that it is not just okay to have a device named the > same thing with multiple functions (indeed, that is how a tremendous > number of devices work), but that it is also okay for them to have the > same name with the same functions, because the name is meant for human > consumption and not computer algorithms. The name is meant for the consumption of any program which needs a way to permanently refer to a device. It always has, it always will be, and if there is a buggy input driver, X clients and users lose.