| 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
| ||
|
Message-ID: <20100616083903.GU17833@buzzloop.caiaq.de> Date: Wed, 16 Jun 2010 10:39:03 +0200 From: Daniel Mack <daniel@...aq.de> To: Dmitry Torokhov <dmitry.torokhov@...il.com> Cc: linux-kernel@...r.kernel.org, linux-input@...r.kernel.org Subject: Re: [PATCH 4/4] input: dynamically allocate ABS information Hi Dmitry, On Mon, May 24, 2010 at 09:15:28AM -0700, Dmitry Torokhov wrote: > On Mon, May 24, 2010 at 06:08:05PM +0200, Daniel Mack wrote: > > any feelings about this approach? > > > > Still pondering...I applied the very first patch though... Any news about this? I have no problem throwing away the whole patch set and use a different approach, if there is any :) And I need one, because I have a patch pending for a MIDI/Controller device which is something like a drum computer control device, and this one has more ABS information channels than currently supported by the input stack. OTOH, the current plan is to use *axis* information for the transport to the user space, but in fact, their hardware representation is a pressure-sesitive button. Same counts for potentiometers etc, which aren't axis either. So maybe I should use some different layer for such devices? MIDI legacy after all? I'm open to any suggestions :) Thanks, Daniel -- 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/
Powered by blists - more mailing lists