it causes assertions to fail in the PCI bounce buffer code. On
other platforms, it causes the address of the next packet to
be mis-calculated, leading to packet loss.
driver by Tohru Nisimura (a very good framework for a FB driver,
BTW!), using bits of Marcus's original driver for the hardware
access.
The main advantage of this version is that is uses rasops (which
is faster than the rcons stuff) and wsfont, so you can select the
console font in the kernel config file. Using the BOLD8x16 font,
you get an 80x30 console (vast improvement compared to the Gallant12x22
font).
we probe, defaulting to Japanese if we don't know what
kind of keyboard we have.
XXX This should be done differently, if we ever want to
support multiple keyboards.
- I tested only ROLAND UM-1 and YAMAHA UX256.
These are not conforming to USB-MIDI spec, however these are
similar to USB-MIDI.
- Since I've not yet seen the "genuine" USB-MIDI device,
I cannot test such devices although I wrote the codes for it.
TODO:
- clean up the codes.
- umidi(4) manpage.
- /dev/rmidi? is working well, but /dev/music seems not working correctly.
- protect the buffer even though ointr occur until exiting
from hw_if->output().
- allow this function to send multiple bytes to hw_if->output()
at the same time. it's necessary for umidi.
This change makes PCMCIA cards work again on my machine.
Unfortunately, some of the DELAY_MS() are called when the current
process is not the cardbus thread, that is, on interrupt contexts.
I confirmed these are actually used in interrupt context and replaced
them with delay()s. However, I haven't confirmed other DELAY_MS()s
are always on the cardbus thread.
This shall be a temporary fix. The driver needs being rewritten
not to use such delay()s, of course.
problem reported by msaitoh@netbsd.org. NOTE: These are marked XXXUBC
since the code that allocates the bufs is new with UBC, but it may be
the case that bp->b_proc needs to be intialized to curproc (it's used
in a call to nfs_sigintr()).
