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 00:11:48 -0400 Message-ID: <87ee24z0wv.fsf@ditto.jhoto.spork.org> References: <164933858147.29834.15050766441005536059@vcs2.savannah.gnu.org> <871qy6o9p3.fsf@yahoo.com> <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> 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="2394"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.6.10; emacs 29.0.50 Cc: Eli Zaretskii , rms@gnu.org, larsi@gnus.org, monnier@iro.umontreal.ca, 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 06:44:23 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 1ndluY-0000Qi-C2 for ged-emacs-devel@m.gmane-mx.org; Mon, 11 Apr 2022 06:44:22 +0200 Original-Received: from localhost ([::1]:44512 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ndluW-000068-Sk for ged-emacs-devel@m.gmane-mx.org; Mon, 11 Apr 2022 00:44:20 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50056) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ndltD-0007qN-V5 for emacs-devel@gnu.org; Mon, 11 Apr 2022 00:42:59 -0400 Original-Received: from coleridge.kublai.com ([166.84.7.167]:55189 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 1ndltC-00045J-31; Mon, 11 Apr 2022 00:42:59 -0400 Original-Received: from ditto (unknown [IPv6:2001:470:1f07:1b9:8650:a942:ec5e:856b]) by mail.spork.org (Postfix) with ESMTPSA id E6B7235BB; Mon, 11 Apr 2022 00:42:08 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=spork.org; s=dkim; t=1649652146; bh=FqQ9PFYHxcA46s/trSmTWVTZOaftUIjG67YHHrqpFFQ=; h=References:From:To:Cc:Subject:Date:In-reply-to; b=O4QgEk9A+/mwszMcho4CTFlUXRiTzkpX3Ud/6YmV8CTyOFISAC7/34/fcoVEfx2Om RL5UD8qicT7axFv9UExLKWNgjKPFP4kGUb+2C05Q8dMK1LOkmLb2ljD2OWf/xq8Q+L Rj1gfQqhqFhLwSNsFY/pxRuu6mRnEUINU10Eh6gk= In-reply-to: <87r16448k0.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:288172 Archived-At: Po Lu writes: > libinput in most cases gets its information from evdev. What the kernel > driver exposing the evdev device does is outside its scope. From what I can tell it seems like in all cases it gets its information from evdev, which in turn gets its information from an ioctl call. >> I am at a loss, then. I do not know why libinput would choose to >> give your devices unique names but not mine. Does the =E2=80=9CDevice=E2= =80=9D line of >> =E2=80=98libinput list-devices=E2=80=99 also show unique names? > > It does not. 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. > That's a bug in the input driver. If the input driver works correctly, > then that will be possible. If not (like in your case), you lose, > sorry, but there is no way to fix that problem. IOW, the devices are > uniquely named, but from the point of view of Emacs the input driver is > reporting two devices as a single device. 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. > And as I already explained, devices are nowhere close to self-describing > in their capabilities. Joysticks send motion events, foot pedals send > keyboard events, and so on and so forth. We may have different definitions of =E2=80=9Cself describing=E2=80=9D hap= pening 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. 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 time, 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? I think names can be useful, but names are not, by themselves, an adequate solution. I can, seemingly without effort, create name collisions on a standard Manjaro install. At this point I=E2=80=99m pretty certain I could do it on any popular Linux distribution. > It's the only reliable way to do that. What else would you suggest? 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. >> prefix the device name with 'pointer:' or 'keyboard:' as appropriate. > > This message sort of demonstrates my point. It is OK for there to be a > pointer and a keyboard extension device with the same name, because they > are the same device sending both motion and keyboard events. But it is > not correct for there to be more than one physical device with the same > name. 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. -bjc