[RFC/PATCH v1 1/3] fix decoder of ioctl EVIOCGBIT
haoyouab at gmail.com
Mon Aug 13 19:00:12 UTC 2018
On Tue, Aug 14, 2018 at 1:59 AM Dmitry V. Levin <ldv at altlinux.org> wrote:
> On Fri, Aug 10, 2018 at 07:12:42PM +0800, Zhibin Li wrote:
> > EV_SYN in EVIOCGBIT should be decoded to get other event types EV_*, not
> > the precise event codes SYN_*.
> Sorry but I don't follow. Could you elaborate, please?
Actually I refer to linux source code and there's a comment in
drivers/input/evdev.c which says:
/* EV_SYN==0 is EV_CNT, _not_ SYN_CNT, see EVIOCGBIT */
so when using the decoder of EVIOCGBIT to decode all those set bits,
EVIOCGBIT(EV_SYN, n) should get something like [EV_ABS, EV_MSC] instead of
[SYN_REPORT, SYN_MT_REPORT]. This is not like others, for example:
* EVIOCGBIT(EV_LED, n) should get something like [LED_NUML, LED_CAPSL]. In
other words, EV_LED should get LED_*, EV_KEY should get KEY_* but EV_SYN
should get EV_* (EV_SYN is 0 and it's a special case).
As for the terms "event types" and "event codes", I got these from 
and briefly speaking "event types" are EV_* while "event codes" are SYN_*,
LED_* and KEY_*, etc.
> > * evdev.c: Include "xlat/evdev_ev.h" and remove "xlat/evdev_sync.h".
> This removes the last user of evdev_sync. Should xlat/evdev_sync.in be
> removed, too?
It seems so for now but I'm not sure whether there will be any further use
of SYN_* flags.
> > (decode_bitset_): Fix the incorrect comparison between tcp->u_rval and
> > max_nr.
> Could you explain, please, why the comparison is incorrect?
It seems the return value of ioctl here is counted in bytes but max_nr here
(possible values are EV_MAX, LED_MAX and ABS_MAX, etc) is counted in bits if
I'm not misunderstanding.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Strace-devel