| Age | Commit message (Collapse) | Author |
|---|
|
It is OK to return 0 in that case, but it is not OK to print a
diagnostic.
|
|
functions
ok kettenis
|
|
|
|
which reports Fn as a regular key.
|
|
|
|
ok deraadt@ henning@ claudio@
|
|
|
|
PWR_{SUSPEND,RESUME} so that they match the values of DAVCT_{SUSPEND,RESUME}
so that we can eventually (many more steps...) kill the powerhook garbage
and use the activate mechanism.
no objections
|
|
|
|
|
|
|
|
|
|
|
|
It makes even the smallest run(4) devices look ridiculously huge.
|
|
* use the correct variable in a DPRINTF
|
|
complete outstanding requests, so use uaudio_drain in uaudio_detach.
* the channel alt index can still be -1 at detach. check for this.
|
|
|
|
|
|
Bogus chunks pointed out by matthew@ and miod@. No cookies for
marco@ and jasper@.
ok deraadt@ miod@ matthew@ jasper@ macro@
|
|
USB_SET_REPORT ioctls in ukbd and ums.
This allows usbhidctl to be used on these devices e.g. to dump the report
descriptor of troublesome models.
ok deraadt@
|
|
required; PR 6436
ok deraadt@
|
|
- parts of the report descriptor not in a format we expect are now ignored,
instead of preventing attachment (e.g. hypothetical multi-bit modifiers).
- modifiers beyond MAXMOD are ignored.
- keycode arrays larger than MAXKEYCODE are clamped to MAXKEYCODE instead
of being rejected.
- multiple keycode arrays are ignored.
This should allow rogue keyboards to attach and be usable up to a certain
extent.
Adapted from a diff sent by Loganaden Velvindron (first name at gmail), who
has a keyboard which keycode array is larger than MAXKEYCODE (but, like most
if not all USB keyboards out there, can only report up to three simultaneous
keypresses anyway).
|
|
|
|
|
|
duplication and divergence.
Thanks to mlarkin@ for bluetooth devices tests.
|
|
function is not.
This change #if 0's urndis_watchdog() and some functions that are only
called from here.
At some point we probably want to use the watchdog functionality but the
current code is completely untested so disable it entirely rather than
enabling it this close to release.
|
|
|
|
device configuration descriptor in the match() function. stops
midi devices from attaching as uaudio then bailing out, leaving
a phantom uaudio.
|
|
|
|
|
|
|
|
ok mglocker
|
|
|
|
|
|
|
|
UVIDEO_FLAG_FIX_MAX_VIDEO_FRAME_SIZE quirk list and b) cranking the
manually calculated frame size by pixels * 4 bytes (discussed with
jakemsr@).
|
|
so that the process-level stuff is to/from struct process and not
struct proc. This fixes a bunch of problem cases in rthreads.
Based on earlier work by blambert and myself, but mostly written
at c2k10.
Tested by many: deraadt, sthen, krw, ray, and in snapshots
|
|
|
|
UVIDEO_FLAG_FIX_MAX_VIDEO_FRAME_SIZE quirk.
|
|
uaudioreg.h. sorry about that.
sync endpoints allow for the sample clock on USB audio devices to not
be synchronized to the USB clock. the sync endpoint gives information
on how much data to send to the data endpoint. although devices that
require sync endpoints will "work" when the sync endpoint inormation
is ignored, there is a possibility of static, echoing, or any other
type of clock desync error.
requires some small changes to existing code:
* tighten up checks for whether a setting needs/supplies a sync
endpoint. ignore settings that need a sync endpoint but don't
supply one. previously all settings that require a sync endpoint
were ignored.
* if a sync endpoint is being used, use the same denominator for
fractional samples as the sync endpoint uses (2**16).
this only implements playback sync endpoints. recording sync
endpoints are an odd concept: the driver would control the clock
rate of the device. there may be such devices, but I can't even
imagine how that could be reliably implemented. I guess you would
sync to the USB clock or the system clock ... but then, what's the
point?
|
|
presumably from a missing commit to a header file. go ahead kettenis@ todd@
|
|
sync endpoints allow for the sample clock on USB audio devices to not
be synchronized to the USB clock. the sync endpoint gives information
on how much data to send to the data endpoint. although devices that
require sync endpoints will "work" when the sync endpoint inormation
is ignored, there is a possibility of static, echoing, or any other
type of clock desync error.
requires some small changes to existing code:
* tighten up checks for whether a setting needs/supplies a sync
endpoint. ignore settings that need a sync endpoint but don't
supply one. previously all settings that require a sync endpoint
were ignored.
* if a sync endpoint is being used, use the same denominator for
fractional samples as the sync endpoint uses (2**16).
this only implements playback sync endpoints. recording sync
endpoints are an odd concept: the driver would control the clock
rate of the device. there may be such devices, but I can't even
imagine how that could be reliably implemented. I guess you would
sync to the USB clock or the system clock ... but then, what's the
point?
|
|
* the clock rate is configured through the audio interface, instead
of on the endpoint.
* since the clock rate is set on the interface, both play and
record must use the same sample rate. this means the playback
and recording parameters are not independent, which is what uaudio
assumes.
|
|
ridiculous value.
* encoding expansion factor is always 1.
|
|
only function that was using it.
|
|
scaling the frame rate to the polling interval, but it works on
the E-MU 0202 and it generally makes a lot of sense, especially
considering that this often brings the frames rate back to 1 kHz,
which is the frame rate of USB 1.x, which was the most current
USB spec when USB audio 1.0 spec was written.
|
|
and for playback, we use a packet size that is at least one audio
frame smaller.
in most usb audio devices, the sample clock is synced to the usb
clock. this means that for sample rates that aren't multiples of
1000, we'll occasionally need to add a frame to adjust the overall
rate. that's why we use the smaller packet size.
also, the usb audio spec defines a way for devices to request
to always use the maximum packet size.
so,
* add a max_bytes_per_frame, which is the largest packet size
the channel will use. use that instead of calculating what
the maximum we will use is in a couple places. generally makes
things easier to understand.
* respect a device's request to always use maximum packet size.
|
|
handled by storing an array of supported encodings.
NOTE: this also removes all conversions from this driver. in
particular, uaudio no longer supports 16-bit big endian encodings,
because the USB audio specification only supports little endian
encodings.
ok ratchov
|
|
|
|
sample size or number of channels is not a power of 2.
* use 'param->bps' instead of 'param->precision / NBBY' for the number
of bytes per sample.
ok ratchov
|
