Re: EVIOCSFF macro inconsistency
From: Elias Vanderstuyft <hidden>
Date: 2014-09-08 20:42:39
On Mon, Sep 8, 2014 at 10:24 PM, Dmitry Torokhov [off-list ref] wrote:
On Monday, September 08, 2014 09:03:11 PM Elias Vanderstuyft wrote:quoted
On Mon, Sep 8, 2014 at 8:31 PM, Dmitry Torokhov [off-list ref] wrote:quoted
Hi Elias, On Mon, Sep 08, 2014 at 08:14:13PM +0200, Elias Vanderstuyft wrote:quoted
Hi everyone, After inspecting the <linux/input.h> header file, I found that there is one single ioctl value macro that is inconsistent w.r.t. the other macros that do an IOC_WRITE : EVIOCSFF _IOC(_IOC_WRITE, 'E', 0x80, sizeof(struct ff_effect)) Why not define it as follows? : EVIOCSFF _IOW('E', 0x80, struct ff_effect) Apart from having a more readable definition, it also explicitly reveals type info ("struct ff_effect").I think it is just historical.quoted
Is it worth to create a patch to fix it?Sure, why not.Cool, thanks! So probably the same applies to the IOC_READ counter parts? : EVIOCGBIT(ev,len) _IOC(_IOC_READ, 'E', 0x20 + (ev), len) EVIOCGKEY(len) _IOC(_IOC_READ, 'E', 0x18, len) EVIOCGLED(len) _IOC(_IOC_READ, 'E', 0x19, len) EVIOCGMTSLOTS(len) _IOC(_IOC_READ, 'E', 0x0a, len) EVIOCGNAME(len) _IOC(_IOC_READ, 'E', 0x06, len) EVIOCGPHYS(len) _IOC(_IOC_READ, 'E', 0x07, len) EVIOCGPROP(len) _IOC(_IOC_READ, 'E', 0x09, len) EVIOCGSND(len) _IOC(_IOC_READ, 'E', 0x1a, len) EVIOCGSW(len) _IOC(_IOC_READ, 'E', 0x1b, len) EVIOCGUNIQ(len) _IOC(_IOC_READ, 'E', 0x08, len) to be converted to: EVIOCGBIT(ev,len) _IOR('E', 0x20 + (ev), len) EVIOCGKEY(len) _IOR('E', 0x18, len) EVIOCGLED(len) _IOR('E', 0x19, len) EVIOCGMTSLOTS(len) _IOR('E', 0x0a, len) EVIOCGNAME(len) _IOR('E', 0x06, len) EVIOCGPHYS(len) _IOR('E', 0x07, len) EVIOCGPROP(len) _IOR('E', 0x09, len) EVIOCGSND(len) _IOR('E', 0x1a, len) EVIOCGSW(len) _IOR('E', 0x1b, len) EVIOCGUNIQ(len) _IOR('E', 0x08, len)No, because 'len' is not a type.
Indeed, just found out by myself, thank you for the confirmation. Elias