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 07:33:22 -0400 Message-ID: <874k2zzqim.fsf@ditto.jhoto.spork.org> References: <164933858147.29834.15050766441005536059@vcs2.savannah.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> <87o8182o3i.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="30977"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.6.10; emacs 29.0.50 Cc: larsi@gnus.org, Eli Zaretskii , emacs-devel@gnu.org, rms@gnu.org, monnier@iro.umontreal.ca To: Po Lu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Apr 11 15:42:15 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 1nduJ4-0007pm-Tq for ged-emacs-devel@m.gmane-mx.org; Mon, 11 Apr 2022 15:42:15 +0200 Original-Received: from localhost ([::1]:32888 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nduJ4-0006qD-1M for ged-emacs-devel@m.gmane-mx.org; Mon, 11 Apr 2022 09:42:14 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49448) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nduIU-0006A3-SU for emacs-devel@gnu.org; Mon, 11 Apr 2022 09:41:38 -0400 Original-Received: from coleridge.kublai.com ([166.84.7.167]:55593 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 1nduIS-00033s-Vu; Mon, 11 Apr 2022 09:41:38 -0400 Original-Received: from ditto (unknown [IPv6:2001:470:1f07:1b9:8650:a942:ec5e:856b]) by mail.spork.org (Postfix) with ESMTPSA id 6A44D35FA; Mon, 11 Apr 2022 09:41:21 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=spork.org; s=dkim; t=1649684495; bh=legLXO+Bm3suJ89aSCNaVoW/ERu/Tz8DNTBoVnpQ3lY=; h=References:From:To:Cc:Subject:Date:In-reply-to; b=hw5Cc6cAyXvorRJuE9DaZrgxX/XszlwlI5YMLABipb9JWHiSQoGYtUP+97oRSEY7B OO/OU8p6SF/VuJMhOg2fN9+DZfr5dHh6XaVXA9VxC0fBe/rJ8kVfH6Aq3PVMMzkxaJ SdkptRKyPInNQcsrNxJEKG0ApzEsPXjNtUvg1rHA= In-reply-to: <87o8182o3i.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:288200 Archived-At: Po Lu writes: > "Input driver" is not at all related to the Linux kernel, evdev, or > libinput. It means a driver for the X server. In my context, and the context of many other people, =E2=80=9CInput driver=E2=80=9D is very related to the Linux kernel, evdev, and libinput. Because that is exactly the stack that is in use for delivering input information to X. I do not think it is useful, in this discussion, to discuss input drivers in the abstract, because no one actually uses an abstract input driver. If there are a substantial number of people with actual driver stacks that don=E2=80=99t match your expectations, then that cannot be handwaved with =E2=80=9Cbug=E2=80=9D, par= ticularly when there=E2=80=99s no evidence that the behavior exhibited is contrary to= any specifications. > 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. I can only speak to the behavior I am witnessing today, because it has only been the last few days since I started looking into the issue. Whether or not X had a particular behavior in the 90s does not, in-and-of itself, mean it will continue to have that behavior today. The computing landscape is immensely different, as you point out. One major difference is that most input devices in the mid 90s, and before, were not self-describing, but expected to be configured by users. In that context, especially because users were also responsible for *naming* devices, using a name makes more sense. But that context is long gone for most of us. Even embedded host devices query USB devices for their capabilities. > 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. libinput classifies devices based on these tables (by way of evdev, by way of the kernel). X uses them for simple classification. But X also doesn=E2=80=99t apparently expose joysticks, either (my Steam Contro= ller has a joystick interface that failed to show up in =E2=80=98xinput list=E2= =80=99). Does that mean Emacs shouldn=E2=80=99t use them? If Emacs is required to use onl= y the information delivered by way of X, then there are large swathes of devices it cannot use. I am aware of the joystick driver, but have not used it. From what I can tell it converts joystick movement into mouse movement, which explicitly defeats using it properly as a joystick by applications. That=E2=80=99s why it=E2=80=99s not included by default in mo= st Linux distributions. > 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. It does have the event device path, however, which can be used to query capabilities. > 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. I contend that my input driver stack, from the kernel, through evdev, through libinput, and into X is not buggy, but in fact, normative. Yet this stack will, trivially, produce identical device names for separate physical devices. Furthermore, I contend that this is completely acceptable. That nothing in this stack has any problem with this situation, and that nothing, even X itself, has any problem disambiguating events from any device, no matter how they are named. If there are applications that use device names under the expectation that they be unique, then I contend that is a bug in those applications, because there is nothing I have found, in spite of a great deal of searching, that appears to make this claim, and you have also provided none when directly asked. There is no code that I can find that would accommodate this feature. And, furthermore, there is no reason for this feature to exist in the modern era -- and I define modern pretty loosely here, X has had USB support longer than it hasn=E2=80=99t, at this point in time. Devices are designed to describe their abilities with enough clarity that they can be used, as expected, with no user intervention what-so-ever, with no care at all given to any possible identifiers, including, but not limited to: model, manufacturer, VID, PID, device ID, serial number, and name (barring, of course, vendor-specific extensions). This modern sensibility is reflected in the driver stack. A user is, of course, allowed to customize their device based on any feature of it they want; it=E2=80=99s their computer after all. They can even use the output of /dev/random if they so desire. But it is *not* a feature of X that they may expect the device name to be a unique identifier, and it should not be communicated to them as such. I have done all I can to show that X does not guarantee unique device names, from abstract rational argument to trawling the actual code in use, to creating custom devices, to finding duplicate, mass-manufactured devices. And while absence of evidence is not evidence of absence, I believe there is enough weight behind my research to show my claim to be correct. The onus is on you to prove the opposite, which is far easier, in that it is at least logically possible: that X has a guarantee of unique device names. Please show me where that claim is made in official documentation, and I will cede that the current behavior is a bug. -bjc