linux-kernel - Re: [PATCH] Input: add flags bitfield

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200803232102.07268.dtor@insightbb.com>
Date:	Sun, 23 Mar 2008 21:02:07 -0400
From:	Dmitry Torokhov <dtor@...ightbb.com>
To:	Henrique de Moraes Holschuh <hmh@....eng.br>
Cc:	linux-kernel@...r.kernel.org, Richard Purdie <rpurdie@...ys.net>
Subject: Re: [PATCH] Input: add flags bitfield

On Saturday 22 March 2008, Henrique de Moraes Holschuh wrote:
> On Fri, 21 Mar 2008, Henrique de Moraes Holschuh wrote:
> > On Fri, 21 Mar 2008 16:07:01 -0400, "Dmitry Torokhov"
> > <dmitry.torokhov@...il.com> said:
> > > On Sun, Mar 16, 2008 at 05:14:11PM -0300, Henrique de Moraes Holschuh wrote:
> > > > Add a flags bitfield to the input_dev structure, which can be used for
> > > > internal coordination among kernel input devices and input handlers without
> > > > the need to use ever-expanding blacklists on the input handlers.
> > > > 
> > > > Add initial flag bits which allows an input driver to request that joystick
> > > > emulation (joydev) or mouse emulation (mousedev) not be attached to an
> > > > input device.
> > > > 
> > > > This will be used by accelerometer drivers exporting a raw interface which
> > > > is not to be used as a joystick device (not to confuse this with the usual
> > > > fuzzed joystick interface these drivers export for enhanced Neverball
> > > > productivity), for example.
> > > 
> > > I'd rather not apply this patch because it pushes kowledge of existing
> > > input interfaces into device drivers. What we could do instead is add
> > > a 'type' field to the input device structure and then input interfaces
> > > (evdev/mousedev, etc) could have an option of matching either by device
> > > type or by device capabilities or both. Your raw devices could have type
> > > of accelerometer and joydev would bind to devices with type "joystick"
> > > or "unknown" + certain capabilities. Will this work?
> > 
> > It would solve my problem, yes.
> > 
> > But I'd prefer if joydev and mousedev did not bind to
> > unknown+capabilities, just in case.  Looks like bad form to me, and
> > might bite us back later on.  We can properly fix all drivers in-tree
> > to have suitable types for joydev and/or mousedev binds, rfkill binds,
> > and so on after all.

Ohne word - HID.

> 
> Drat, removing unknown+capabilities means I'd have to hunt down every
> frigging input device in the tree to annotate its type... otherwise, it
> would cause regressions re. the handlers.  It is a work that needs to be
> done anyway, only adding type metadata to new devices and leaving the
> rest to report "unknown" is just icky.
> 
> Come to think of it, what about uinput?  It would need to be able to set
> the device type as well, otherwise mousedev and joydev, for example,
> would not attach to uinput-created input devices.
> 

That's why I thinkg unmarked should really be default and only few selected
devices should set their type.

-- 
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/