Re: ff-core effect id handling in case of a failed effect upload
I sent a patch, see: http://www.mail-archive.com/linux-input@vger.kernel.org/msg08572.html ([PATCH 1/1] Input: don't modify the id of ioctl-provided ff effect on upload failure) Elias On Sun, Feb 23, 2014 at 7:30 AM, Dmitry Torokhov dmitry.torok...@gmail.com wrote: On Wed, Feb 19, 2014 at 11:14:18PM +0100, Elias Vanderstuyft wrote: On Wed, Feb 19, 2014 at 10:05 PM, Dmitry Torokhov dmitry.torok...@gmail.com wrote: On Wed, Feb 19, 2014 at 06:49:36PM +0200, Anssi Hannula wrote: (added Dmitry to CC) 19.02.2014 13:42, Elias Vanderstuyft kirjoitti: Hi, Hi, In the process of reviewing the Wine DInput translation layer, I noticed an inconvenience (in the ff-core implementation?) that can possibly lead to confusing problems to application developers (not only for Wine), in short: If a new (id==-1) effect was uploaded (look at ff-core.c::input_ff_upload(...)) that failed (e.g. returning EINVAL), ff-core will have assigned a positive number to the effect id. This can be confusing because the dev-ff-effects[] array will not contain an element at the index of that new effect id. I agree that this is a bit confusing, and the kernel code should probably be modified to not clobber the ioctl-provided effect on failure (effect-id is set to an undefined value, i.e. next free effect slot). Dmitry, WDYT? Yeah, it looks like we need to change evdev.c to read: error = input_ff_upload(dev, effect, file); if (error) return error; if (put_user(effect.id, (((struct ff_effect __user *)p)-id))) return -EFAULT; return 0; Alright, who will create the patch? Do I may / have to do it? If you could create the patch that would be appreciated. Thanks. -- Dmitry -- To unsubscribe from this list: send the line unsubscribe linux-input in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ff-core effect id handling in case of a failed effect upload
On Wed, Feb 19, 2014 at 11:14:18PM +0100, Elias Vanderstuyft wrote: On Wed, Feb 19, 2014 at 10:05 PM, Dmitry Torokhov dmitry.torok...@gmail.com wrote: On Wed, Feb 19, 2014 at 06:49:36PM +0200, Anssi Hannula wrote: (added Dmitry to CC) 19.02.2014 13:42, Elias Vanderstuyft kirjoitti: Hi, Hi, In the process of reviewing the Wine DInput translation layer, I noticed an inconvenience (in the ff-core implementation?) that can possibly lead to confusing problems to application developers (not only for Wine), in short: If a new (id==-1) effect was uploaded (look at ff-core.c::input_ff_upload(...)) that failed (e.g. returning EINVAL), ff-core will have assigned a positive number to the effect id. This can be confusing because the dev-ff-effects[] array will not contain an element at the index of that new effect id. I agree that this is a bit confusing, and the kernel code should probably be modified to not clobber the ioctl-provided effect on failure (effect-id is set to an undefined value, i.e. next free effect slot). Dmitry, WDYT? Yeah, it looks like we need to change evdev.c to read: error = input_ff_upload(dev, effect, file); if (error) return error; if (put_user(effect.id, (((struct ff_effect __user *)p)-id))) return -EFAULT; return 0; Alright, who will create the patch? Do I may / have to do it? If you could create the patch that would be appreciated. Thanks. -- Dmitry -- To unsubscribe from this list: send the line unsubscribe linux-input in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ff-core effect id handling in case of a failed effect upload
On Wed, Feb 19, 2014 at 06:32:54PM +0100, Elias Vanderstuyft wrote: I'll include the code (with effectId_old variable) and this discussion when I submit my whole patchset for Wine's DInput libs to Wine-devel mailing list. Right now, I don't know who I should personally mail to. Patches ready to be included in Wine should go to wine-patc...@winehq.org. I've done a bit of work in dinput myself, so you can feel free to send them to me and/or wine-devel first if you'd like a review. Andrew -- To unsubscribe from this list: send the line unsubscribe linux-input in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
