[haiku-development] Re: (USB MIDI) Device hierarchy
- From: Philippe Houdoin <philippe.houdoin@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Thu, 10 Feb 2011 14:21:01 +0100
Jerome replied this to Pete:
>> My question is: should the ports appear as (say) /dev/midi/usb/1
>> and /dev/midi/usb/2, or -- as they're actually a single device --
>> as /dev/midi/usb/1/0 and /dev/midi/usb/1/1 -- one extra level down?
>
> It's just a naming. One could also have sequential numbers, one for
> each device/port combination.
But this name, currently, is also exposed to end user as the MIDI port name.
So making this enough friendly *while* still unique is something that
we would want to achieve here.
> The bigger problem I see is the lack of information about the
> availability of such ports in the descriptors: it seems the driver
> could have to dynamically publish dev entries. Philippe maybe already
> thought about this.
IIRC there is a device descriptor giving the port(s) configuration.
It's not currently read.
> Moreover, the driver is at the moment clearly oriented for a one
> endpoint to one dev entry communication,
Which is expected: USB MIDI class requires only a pair of bulk
endpoints per device, whatever the input & output ports are behind
(max being 16 I/O ports, above a second device should be advertized
instead). The port multiplexing is done via the channel number ("cn"
field) in the usb_midi_event_packet.
> which might not fit very well
> with additional dev entries.
What the driver is not ready is to multiplex the received
usb_midi_event_packet on the matching dev entry according to the
channel number.
Sending with the good channel number won't be a big issue, it's only a
matter to affect a channel number to the dev entry and use it when
filling the packet to send.
> The midi server also assumes each dev
> entry to have one input port and one output port, which might not be
> the case hardware side.
It could be fixed easily, and I've just done that in r40419.
Of course, it needs usb_midi driver to check access mode in its open() hook...
Bye,
Philippe.
Other related posts:
