linux-kernel - Re: Frontier USB Drivers (Was: Staging tree status for the .32 kernel merge)

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <4AAF5E6F.4030307@ladisch.de>
Date:	Tue, 15 Sep 2009 11:29:19 +0200
From:	Clemens Ladisch <clemens@...isch.de>
To:	Dave Taht <d@...libre.com>
CC:	linux-kernel@...r.kernel.org
Subject: Re: Frontier USB Drivers (Was: Staging tree status for the .32 kernel
 merge)

Dave Taht wrote:
> 	- fix userspace interface to be sane
> 
> This is the biggest open question I have. Right now the drivers just
> handle the interrupts, and queue up the data in a ringbuffer, sending the
> events in the exact same format as received from the device, and vice versa.
> 
> Coming up with an abstract means to handle a very specialized device - a
> control surface that simultaneously is a LCD screen, a bunch of LEDS, a
> scroll wheel, and 20+ buttons that can be pressed in various
> combinations, would kind of involve reinventing a char I/O based X11,
> and I don't really feel that much or any of that needs to happen in
> kernel space.
> 
> (the alphatrack is worse, it has a slider with feedback and buttons that
> have touch sensitivity, and a special key that remaps the sliders and
> buttons to another keymap entirely)
> 
> There are a lot of "surfaces" out there in the music world, with all
> kinds of combinations of buttons and knobs and gee-gaws, etc,

... and practically all of them send/receive MIDI messages, which ties
in with the fact that most applications you would want to control with
this allow to be controlled by MIDI.

The Frontier Windows drivers also have a MIDI mode, so I'd strongly
suggest that you implement that.

> Far better, I thought, to just handle the RT critical portions of the
> code in the kernel and hand off the rest of the chaos to userspace.

The ALSA framework already handles buffering and routing of MIDI events,
so you'd just have to map between the device's bits and sequencer events.


Best regards,
Clemens
--
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/