Received: by 2002:a25:e7d8:0:0:0:0:0 with SMTP id e207csp850833ybh; Wed, 18 Mar 2020 10:15:59 -0700 (PDT) X-Google-Smtp-Source: ADFU+vuxpQPTj6bXabmYnx3Lv0Gg40bUICMHKDA6/V+RzpfGcDaszXT+WbiR2muRz7aWYuu74uU0 X-Received: by 2002:a9d:1d67:: with SMTP id m94mr4887895otm.140.1584551759150; Wed, 18 Mar 2020 10:15:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1584551759; cv=none; d=google.com; s=arc-20160816; b=pJT0lhvJXiFXiE8p4HoAZL4ZTIb/5XpkA+nBLTi5rOABGVHu5STYrdYy6jmnC6ttsa shLxWtlN+juLjcJQw2V+5ct7iPgQRO7bWG5QrPwP+itIXperMEcxigMfmXduR1pHwzIc N+U3OJ2XZa+/uYKRCphb1xOAGBQeiIe4EuLEzWvysLKquhX1Gw6mplvC24CwN6/Yrwq/ 6xMj2ttmBZ3USLFOqwhIYpIWGFSgZUQNmqZoM4f9HHeFRI7KLZWVHc5YxLFNL45Nc0ff qn3VzbeNCpJQCH22oPXvCVBjmz6j6WwNTW67Gr3rkp8YfkYf+urfHdcShxD1iP0fh63E PKyw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=XxUwJet0pq87ma5H9uRR4f/E0DxPaM/eAomJtt++Wdw=; b=HhuJE3Fo6IVIehErlcTBwbUPNR6NmB5GBvNue4Yuo2qtT5DLBpErn6azrT8Y5q9jUu poGRThMfWJ3BATpSatKYnnWScAD6c+U95Rb/tnpMsyAdudbbqpKvTltGNFk9n0HMmLBn b0NmwGIAELuoyv6WC/KYPyMoojvbl71h7ePtkvT5fuPfcbVB5fJX3NbCXlA7lZPBGRpu eZdUh7bVXSjBnI4tnf9NPwg6JTJ1YgrRv2xDhH9G9JRk1Uxx8jlbXq7AlyNogDPNR0SO BSTZnhwS3BAnjtgHdWMyuaq8TIanpw9atorL8AuzeDAmFUwlmOj13pZn8x6Ytioomv/k qvkg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=DjBEsemG; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h81si3850110oif.20.2020.03.18.10.15.47; Wed, 18 Mar 2020 10:15:59 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=DjBEsemG; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726834AbgCRRP1 (ORCPT + 99 others); Wed, 18 Mar 2020 13:15:27 -0400 Received: from mail-qt1-f195.google.com ([209.85.160.195]:43953 "EHLO mail-qt1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726623AbgCRRP1 (ORCPT ); Wed, 18 Mar 2020 13:15:27 -0400 Received: by mail-qt1-f195.google.com with SMTP id l13so21329372qtv.10; Wed, 18 Mar 2020 10:15:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=XxUwJet0pq87ma5H9uRR4f/E0DxPaM/eAomJtt++Wdw=; b=DjBEsemG/jKOqxSvxcsYq29zun7ypTmpLQlvI1ddnFGNppkBPa5778wjuKJKsZDGlu 3Zm27jDFWKiXsSrxlqDpU0nCfpXFq2gC5OZ5+clXqP2yVzZqFyURbzLOQ93CI51pWG5r Di+n5FOGn5h7LsdwPHcDObhKKDPaj3lRBf7PkJ39kkAmlfG1JSSZxddsxreA8dI77JZ7 aag2l+kVpPGquTTPvRAa9cAOgvquAR4UEyW8KQIo6igUQKOsQdLGggldAUrMRvfFkkCj bjMNzxka5ko2dwdp4jpNCfKcvPnYk2bOGYJwVhDEzwIKwazryU1nhaiFpECKnPKdBXWU J0HQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=XxUwJet0pq87ma5H9uRR4f/E0DxPaM/eAomJtt++Wdw=; b=fg89ukY5udxVRVRkaWkyz+YVgtKPB92h0fit/BjVUvtNAvwUwQ2GYLTP+lMiey+K1f WNnFpd9EK3yJ5eLdoGoUz7i6ZaI06yl2bOP5CfFWVFz5qoIcp4D/R3drKKWdSblMa8LZ ekFDQnZ8OaOacytE+AZEmVTSWR1kEg5l1J9zbMrP9YWWFhHnZzpy8mNz932Qplf/938Q 5o+gidkHkJl30b/4/dLqRUsNUrxe2Ff88cROr2u/pxV3DRw5+cwHDsvXT0vBInz5ZrkA ZDi0yHTlNjrr5RwFcY8OGVLPCvkCIVr/1qYRNuEBGLEvimz9bZiYoK6XEfcTaX/i4VC0 b7Vg== X-Gm-Message-State: ANhLgQ3H2YbXJVgyvEBN2PaFIGJUsb12ZTzhw3o60OaIr0C1P3baaqvy yndEq7OBQgtEslq7tgKbaQW9OlYxGswWJwbz6BU= X-Received: by 2002:aed:200f:: with SMTP id 15mr5587101qta.152.1584551724821; Wed, 18 Mar 2020 10:15:24 -0700 (PDT) MIME-Version: 1.0 References: <20200318161906.3340959-1-lains@archlinux.org> In-Reply-To: <20200318161906.3340959-1-lains@archlinux.org> From: Mario Limonciello Date: Wed, 18 Mar 2020 12:15:13 -0500 Message-ID: Subject: Re: [PATCH] HID: logitech-dj: issue udev change event on device connection To: =?UTF-8?Q?Filipe_La=C3=ADns?= Cc: Jiri Kosina , Benjamin Tissoires , linux-input@vger.kernel.org, linux-kernel@vger.kernel.org, Peter Hutterer , Hans de Goede , Richard Hughes Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Mar 18, 2020 at 11:19 AM Filipe La=C3=ADns wr= ote: > > As discussed in the mailing list: > > > Right now the hid-logitech-dj driver will export one node for each > > connected device, even when the device is not connected. That causes > > some trouble because in userspace we don't have have any way to know if > > the device is connected or not, so when we try to communicate, if the > > device is disconnected it will fail. > > The solution reached to solve this issue is to trigger an udev change > event when the device connects, this way userspace can just wait on > those connections instead of trying to ping the device. > > Signed-off-by: Filipe La=C3=ADns > --- > drivers/hid/hid-logitech-dj.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/hid/hid-logitech-dj.c b/drivers/hid/hid-logitech-dj.= c > index 48dff5d6b605..fcd481a0be1f 100644 > --- a/drivers/hid/hid-logitech-dj.c > +++ b/drivers/hid/hid-logitech-dj.c > @@ -1464,6 +1464,8 @@ static int logi_dj_dj_event(struct hid_device *hdev= , > if (dj_report->report_params[CONNECTION_STATUS_PARAM_STAT= US] =3D=3D > STATUS_LINKLOSS) { > logi_dj_recv_forward_null_report(djrcv_dev, dj_re= port); > + } else { > + kobject_uevent(&hdev->dev.kobj, KOBJ_CHANGE); > } > break; > default: > -- > 2.25.1 The problem that will remain here is the transition period for userspace to start to rely upon this. It will have no idea whether the kernel is expected to send events or not. What do you think about adding a syfs attribute to indicate that events are being sent? Or something similar?