From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id ECFD9CDB483 for ; Fri, 13 Oct 2023 21:59:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231788AbjJMV7r (ORCPT ); Fri, 13 Oct 2023 17:59:47 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42428 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229632AbjJMV7q (ORCPT ); Fri, 13 Oct 2023 17:59:46 -0400 Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B2AB4B7; Fri, 13 Oct 2023 14:59:44 -0700 (PDT) Received: by mail-pl1-x632.google.com with SMTP id d9443c01a7336-1c735473d1aso19990255ad.1; Fri, 13 Oct 2023 14:59:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1697234384; x=1697839184; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=2E01oW9FArDha6b2WRAcTTSaAEu+o4wpih5oGTOjVp8=; b=FZzxN8EKy7ME8WncsBbp5KDNPiV6tNArijuyaWzLMiMnjIoJFoGSKKjtcOaOgzxuV4 91En0BfFtmV88ISMh04EajSHhCkmMOPb8J59gTN5L0TL+SUoO6M681aEji22HhW61XtX uN2DxhTEfjOUYT5H4wZhaBFFCNK90ip1Z3AOLXeSY7Z2zgLzguEzo5ss0hRbTMgLyLal /DoIuyFSBEUl+FswNEq1SfpdhJSwzoWb0u2A3OlffBABPs2EC/63mfdMovp0NYIaD/ih yPq23xpMTTSRJ0gp+r0OCMSOXAWyfFh9VFkQ494PDmAXuEYeWfHVydaV502TmSYuTv/H xPNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697234384; x=1697839184; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=2E01oW9FArDha6b2WRAcTTSaAEu+o4wpih5oGTOjVp8=; b=lQNCJ/lYMfpC5I4dk/6ZQWZP489+shD0qjUaZiAxUFBLYh9tKjJkqf11CA0EyH3ljF apUHUxJipRPwHNa1w5czf6baPXsS1zkewi3l4hzx1knVn6fmQ5IQClmucNkk6xY9BXYO wu+hnifwkhBHyu8E8huny6BJfsM6xgx3Yfb3u6WyP1tIiLqMr7OHYWwvx2y68rg+ay8M 7nbSqN7TtFakqjtd7yZc7wcnuE1vU05JNCqAn0hYzoKSHVaIw3KGpqPi6B2SEAJyHH37 3HePtGX+tDle6NCXxTh2jgnCkYd26nDmZvkXReLG/xILVlTMnHPNkz7RV3TUzyb65EU7 rc1Q== X-Gm-Message-State: AOJu0YyTtwBmtIhy/MOXcF52N31FHr2miB+hmekh+deKZwf19LbEvm66 tPLhRRxzNyAsngAr+ie/GJbUwi0NLuc= X-Google-Smtp-Source: AGHT+IHdd1fwx8ZoF6+US/sd1Hx80a8l9d6ZplVxf2Cs50Y1gb7N8WW19H5nI7NYiWJdjOx9Hnbv1A== X-Received: by 2002:a17:902:e5cc:b0:1ca:2a58:7ef9 with SMTP id u12-20020a170902e5cc00b001ca2a587ef9mr251184plf.67.1697234383942; Fri, 13 Oct 2023 14:59:43 -0700 (PDT) Received: from google.com ([2620:15c:9d:2:469c:3411:2771:1b7f]) by smtp.gmail.com with ESMTPSA id iw7-20020a170903044700b001b895336435sm4379605plb.21.2023.10.13.14.59.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 13 Oct 2023 14:59:43 -0700 (PDT) Date: Fri, 13 Oct 2023 14:59:41 -0700 From: Dmitry Torokhov To: John Salamon Cc: rydberg@bitmath.org, linux-input@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: uinput: waiting for UI_FF_UPLOAD events will not inform user when allocation is required Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi John, On Tue, Oct 10, 2023 at 05:38:27PM +1030, John Salamon wrote: > Currently the "fake" input events generated by uinput in response to > effect uploads will return an effect with an id that has already been > handled by input_ff_upload in ff-core.c, which can modify the effect > id. This causes a problem specifically when the effect originally > uploaded via the EVIOCSFF ioctl contained an effect with -1, as the > userspace code handling UI_FF_UPLOAD receives an effect with an id > other than -1, and therefore will not know an allocation was > requested. The kernel never changes ID of an existing effect, the only time ID is changed is when userspace indicates that a new effect should be created by setting effect ID to -1. The handler of force feedback effects should know what effects (with what IDs) have been uploaded to the device so far, so whenever it sees a request for an effect with previously unseen effect_id it should recognize this as a signal that a new effect/id has been allocated by the kernel. > > I notice that the "old" field on the ff_effect struct is set to NULL > when the -1 id is changed (in input_ff_upload), which can serve as a > flag that an allocation was requested. If it is the intention is that > uinput users check if old == NULL to know when allocations are needed > I think uinput documentation should describe this. No, not really, as explained above. > > I first noticed this using python-evdev, see my issue report here: > https://github.com/gvalkov/python-evdev/issues/199 Thanks. -- Dmitry