The following reply was made to PR kern/32567; it has been noted by GNATS.

From: Chapman Flack <nbgnats@anastigmatix.net>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: kern/32567 umidi(4) cable numbers
Date: Sat, 21 Jan 2006 13:00:03 -0500

 Updated the patch at the URL above. Now adds a UMQ_TYPE_CN_FIXED
 quirk for devices that require any peculiar assignment of cable
 numbers different from CN_SEQ_GLOBAL or CN_SEQ_PER_EP. But such
 peculiar cable numbering could lead to a weird correspondence
 between the auto-assigned rmidi unit numbers and the device's
 physical ports or blinkenlights, so also adds a UMQ_TYPE_MD_FIXED
 quirk to allow that mapping to be specified explicitly as well.
 
 Interesting how I discovered the original CN assignments for
 Midisport 2x4 were wrong: it has two endpoints (id 2 and 4)
 and four actual ports (CN 0, 1, 2, and 3) and was originally
 quirk'd to put CNs 0,1 on ep 2 and 2,3 on ep 4. It /worked/,
 only it was possible on CNs 1 and 2 to achieve (apparent) data
 rates much higher than the MIDI spec.  Turns out the device
 will accept data for any of the 4 CNs on either of the 2 eps,
 but flow control only works on ep 2 for CN 0 and 2, and only
 on ep 4 for 1 and 3, so that's what the assignment has to be.
 
 There was no way to notice the problem without the patch for
 kern/32588 because there was no way to achieve, much less
 exceed, the actual MIDI data rate.
 
 The moral is, in adding support for a new USB MIDI device, after
 everything seems to be working, it should probably be standard
 practice to do a data rate test (as shown in kern/32588) and
 follow up any suspiciously high results - it may be that some
 reshuffling of CN/ep assignments is necessary for flow control
 to work and avoid dropped data.