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 11:12:47 +0800 Message-ID: <87r16448k0.fsf@yahoo.com> References: <164933858147.29834.15050766441005536059@vcs2.savannah.gnu.org> <83v8vi8uyu.fsf@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> 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="28346"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.91 (gnu/linux) Cc: Eli Zaretskii , emacs-devel@gnu.org, larsi@gnus.org, monnier@iro.umontreal.ca, rms@gnu.org To: Brian Cully Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Apr 11 05:14:13 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 1ndkVJ-0007C9-K6 for ged-emacs-devel@m.gmane-mx.org; Mon, 11 Apr 2022 05:14:13 +0200 Original-Received: from localhost ([::1]:60136 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ndkVH-0003Xe-Uh for ged-emacs-devel@m.gmane-mx.org; Sun, 10 Apr 2022 23:14:11 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36880) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ndkU8-0002qd-9o for emacs-devel@gnu.org; Sun, 10 Apr 2022 23:13:00 -0400 Original-Received: from sonic307-10.consmr.mail.ne1.yahoo.com ([66.163.190.33]:35440) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ndkU5-0007G0-3j for emacs-devel@gnu.org; Sun, 10 Apr 2022 23:12:59 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649646775; bh=BwRUlPCn6yIle8d6ZYlSoj2ACZX8JaBsuERl/pfQx3c=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From:Subject:Reply-To; b=sOkPs1JCENvDgUn8vukmfT9DnVJZ0JdGjWptJW1blfDe53RxG7xHBKvso+KpoX9yHtcmJi+T1VAlk7O9Ul+oZnMnqF6u5f9wEDTaSJ/pl5KKALosBjsBk/eYPnNl9l00qiezHCl2QRk8qjyU2gABm7Pq6FbGYrUSuhf6NsWlLGS7SXoQl7dhrM1PMBHGQKVFhYIgeSIDsclm2mG/LU+YR/xnlkddL4M4IweBd7MLelnDBaJ1vl0dJKkLB9bRbUwdWiwTDTrCI5GwjULW8L7Asfs5c6Vk6+km4Ca8DghlCcBIh4qNx73vtkcxxcuIU4gyu8Sd/fM7TqXnlSN/ifngTg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649646775; bh=h++GzuKZJ0FFYcxO9XTu4fveaejwYPqSUCl6bGtFdkW=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=tL8QFeX9FFlUyRQ2w91yfiRSq8Cm37B6DyloWa5NUquaPgk6srAYw6JgaDX+rIaRaBseGDLdHdaP5LAqhoOhA4Wav8OkNukq7Jh6q915EbLofMLVhDSyFBZQCKEXz8YjdU5uj9XfVEgzTr8ft1Fs53LhjzmM7pHHwZwxuxV+KikSWYeh8j2LOqbcv/wXP+4lk+lICE4DIvudkEo83boGl9KH76BrJSdijTdcJcBo5YCUhFmXOTtAN+Dfp3r10/F9bKLiPJhH9jbr+eN6GLqNJtznqRe5XVgSA2TDvhD1f1DNRcq4WQ7drSOtBG1vYCDwwbWf2eOV1w3wNY79giBdGw== X-YMail-OSG: VNzBn3kVM1ktzkYjRCmEob_oPJmHBSfXbA.jioVNnxz0gsBdA3nzZs210QbsVeX A3rx0mSuy9YZA1670FhVLJ4N01wPT9R8dbUL2rVbV.SgCm7TCUKzHbuuxwuqpwQxvPeFpCDnQS76 g0c49SrJloNypYX7klELdd.sX.h6rc5xxxyPCCChCrhRs3YwlwsjE9UIyOKzXtHlKs5pMDiGwswv aYOzYWiCQ.XfjR3pYFBt8X9jaAp8oFesfkro_EAuz0DnfmHxrN1USbOo2WisoI.TogyyZgZ67BiL Qy_pPUr8xIjbbJMYC6SB8e_bMmCikoSEYa6UNRfG5bKMYlTx_1vn5vYUqGaT1mMk4rS0uqLYq8FH LmY7wR3YcPrLVfAIOk7gw17beGH9OYqSaDoqAv0A1RHK_GxbTHvSoM1axk2FFXDnJZNdPTirh07h ACEAysO2FgbShkFGj_xsQ1_9iZ9h5phbMQrFvORJ.hqBecj8HGqTKBuY2CA9bSNZ8hRXNwG3W2ft JB.FTq_YHwdi23xmzM7_V8uAiEjWSG9J092k0FHQojZKpF9mxCo_9NaQ4XKj1EFWILMRaU2d0oSO 3.dbOH2dvt6IRaKMneAumqrB4XyHXO6iM3wXg9znltWpZuG.Q3HoH1rH.AWsPcWYE3RJwMwd.8Cc zhY18DiuygCSmop9B0s4IwJzffaVN2LfbKFP7glz.Hqgv7jKNH_ZrjrWRcO8x6qW9W42H5O60rBc l0ZYQO4u3jwhqgC2N3_ZDyKMcWzgkUKtMXguVbEw_vHDpWmTu9nPvNEXa_uofMi1p1QExi7keNc0 G0fMeppPvoEfHfV_O2NUEFsPt9GlNt0y1QLJKolomt X-Sonic-MF: Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.ne1.yahoo.com with HTTP; Mon, 11 Apr 2022 03:12:55 +0000 Original-Received: by hermes--canary-production-sg3-65d7bd97b5-8hnzk (VZM Hermes SMTP Server) with ESMTPA ID ff80e4751c5764dab50287fbdf019f77; Mon, 11 Apr 2022 03:12:51 +0000 (UTC) In-Reply-To: <87k0bwe45v.fsf@ditto.jhoto.spork.org> (Brian Cully's message of "Sun, 10 Apr 2022 22:21:49 -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.190.33; envelope-from=luangruo@yahoo.com; helo=sonic307-10.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:288168 Archived-At: Brian Cully writes: > I think I must be misunderstanding something, because I have > devices that are identically named within X and also operate > correctly. That seems to me to run counter to =E2=80=9Ccan only operate > correctly if each name uniquely identifies a device=E2=80=9D. That means it's not operating correctly because of a problem in the input driver. It might work, but it's not correct behavior. > I bring up USB because libinput has to get its information from > somewhere, and in the cases of the devices I have that libinput > publishes, that is USB. I could potentially dig out some bluetooth ones, > but that seems uneccesary. libinput in most cases gets its information from evdev. What the kernel driver exposing the evdev device does is outside its scope. > 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. > This thread began with a claim that devices were uniquely named, > and thus could be disambiguated within Emacs to provide different > functionality based on their names. If I wanted to treat the pointer on > one Steam Controller as a vertical scroll, and on the other a horizontal > scroll, I do not currently see how I could do that. 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. > What this shows to me is that precious little in the X stack > actually cares about device names. For the most part, they are > irrelevant, as devices are self-describing in terms of capabilities. They are not. If you want to configure a program to behave differently based on the individual steam controllers, that will not work, because to them the X server is reporting those two controllers as the same device. 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. > That it is useful for a user to modify the way a device behaves > in the context of Emacs I take at face value, and I also grant that the > name is one possible, though hopefully as is clear by now, not > fool-proof way to do that. It's the only reliable way to do that. What else would you suggest? (Reliable doesn't have to mean it has to work when the input driver is buggy. It just happens to be the only way to single out an input device, and because of that, it's what programs use.) > I do not actually believe this to be a huge problem. Outside of > hardware hackers I don=E2=80=99t think I know anyone who attaches two ide= ntical > devices. Maybe musicians? I=E2=80=99m sure they exist, but it=E2=80=99s n= ot a lot of > people. But I also don=E2=80=99t believe this is a problem Emacs can solv= e using > only the device name, for reasons already stated. If the input driver's naming is broken, they can configure the devices statically in their X server configuration files. "Only the device name" is enough with a correctly functioning input driver, and if xf86-input-libinput is not, then too bad, the users lose. (Or have to mess with their xorg.conf.d.) > 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. > $ xinput list-props 24 > Device 'Valve Software Steam Controller': > Device Enabled (154): 1 > Coordinate Transformation Matrix (156): 1.000000, 0.000000, 0.000000, 0.= 000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000 > libinput Send Events Modes Available (275): 1, 0 > libinput Send Events Mode Enabled (276): 0, 0 > libinput Send Events Mode Enabled Default (277): 0, 0 > Device Node (278): "/dev/input/event30" > Device Product ID (279): 10462, 4418 > $ xinput list-props 9 > Device 'Valve Software Steam Controller': > Device Enabled (154): 1 > Coordinate Transformation Matrix (156): 1.000000, 0.000000, 0.000000, 0.= 000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000 > libinput Natural Scrolling Enabled (290): 0 > libinput Natural Scrolling Enabled Default (291): 0 > libinput Scroll Methods Available (292): 0, 0, 1 > libinput Scroll Method Enabled (293): 0, 0, 0 > libinput Scroll Method Enabled Default (294): 0, 0, 0 > libinput Button Scrolling Button (295): 2 > libinput Button Scrolling Button Default (296): 2 > libinput Button Scrolling Button Lock Enabled (297): 0 > libinput Button Scrolling Button Lock Enabled Default (298): 0 > libinput Middle Emulation Enabled (299): 0 > libinput Middle Emulation Enabled Default (300): 0 > libinput Accel Speed (301): -0.200000 > libinput Accel Speed Default (302): 0.000000 > libinput Accel Profiles Available (303): 1, 1 > libinput Accel Profile Enabled (304): 0, 1 > libinput Accel Profile Enabled Default (305): 1, 0 > libinput Left Handed Enabled (306): 0 > libinput Left Handed Enabled Default (307): 0 > libinput Send Events Modes Available (275): 1, 0 > libinput Send Events Mode Enabled (276): 0, 0 > libinput Send Events Mode Enabled Default (277): 0, 0 > Device Node (278): "/dev/input/event30" > Device Product ID (279): 10462, 4418 > libinput Drag Lock Buttons (308): > libinput Horizontal Scroll Enabled (309): 1 > libinput Scrolling Pixel Distance (310): 15 > libinput Scrolling Pixel Distance Default (311): 15 > libinput High Resolution Wheel Scroll Enabled (312): 1 One of those is a keyboard, the other is a pointer. They are not ambiguous, since they are extension devices corresponding to the same "real" device. The other pair (25, 10) is a bug, and from the POV of programs is the same controller as the the first pair.