* the last valid index should be written in HDAC_STREAM_LAST_VALID instead of the fragment count.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34730 a95241bf-73f2-0310-859d-f6bbb57e9c96
is not tested, though, as I don't own the hardware.
* Note: This wifi driver is special, as it doesn't require the FBSD_WLAN flag
set in the glue.c. This is due to the driver making little use of the
wlan stack. Thus no initialization of wlan stuff is needed.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34710 a95241bf-73f2-0310-859d-f6bbb57e9c96
weren't terminated orderly.
* IOScheduler now stores its name and gets a unique ID.
* Added IOSchedulerRoster singleton which registers all IOSchedulers. It also
provides a notification service. We generate interesting events for
IOSchedulers, IORequests, and IOOperations.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34702 a95241bf-73f2-0310-859d-f6bbb57e9c96
- Round the DMA position for the buffer cycle computation. Apparently some
chipsets trigger the interrupt before the position has been updated.
- Don't just assume that stream->buffer_length frames have been processed
at that time. Use the exact stream position at that time. This makes the
performance time computation more precise and immune to the interrupt
being delayed.
* Init hda_stream::frames_count.
Audio skips on I/O seem to be gone for me, now. Not obviously motivated skips
still happen.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34671 a95241bf-73f2-0310-859d-f6bbb57e9c96
This probably fixes#2801 and is what the FreeBSD driver does.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34667 a95241bf-73f2-0310-859d-f6bbb57e9c96
descriptor n link position in buffer) registers. They contain "the number
of bytes that have been received off the link", which is not to be confused
with the number of bytes that have been transferred by the DMA engine.
The interrupt is triggered when the last byte of the buffer has been fetched
by the DMA engine, at which point the stream's LPIB is still somewhere in
the last buffer. So the interrupt handler could compute the wrong buffer
index, which would lead to the multi audio add-on filling the wrong
(currently being transferred) buffer, resulting in noisy sound. Now we use
the DMA position. Should fix#4072.
* Also removed the not (always) working hack-around for the "wrong" buffer
positions in the interrupt handler.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34664 a95241bf-73f2-0310-859d-f6bbb57e9c96
* There is firmware needed, which can be distributed with Haiku:
a) Get the firmware from www.ralinktech.com -> Software -> Linux
-> Firmware RT2501(RT2561/RT2661)
b) Extract the three binaries to /system/data/firmware/ralinkwifi/
c) Rename them by removing the '.bin' ending and append fw instead
(e.g.: rt2561.bin -> rt2561fw)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34663 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Also note: the firmware needs to be installed in /system/data/firmware/marvell88w8335
and not malo8335 as I stated in commit r34661.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34662 a95241bf-73f2-0310-859d-f6bbb57e9c96
* This driver requires a firmware, which is not publicly available, and
therefor cannot distributed with Haiku. To retrieve and install the firmware
nonetheless following steps are required:
a) Download the firmware from http://www.nazgul.ch/malo/malo-firmware-1.4.tgz
b) Copy the included firmware files malo8335-h and malo8335-m to /system/data/firmware/malo8335/
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34661 a95241bf-73f2-0310-859d-f6bbb57e9c96
returning B_INVOKE_SCHEDULER from the interrupt handler, causing
latencies up to a full quantum for the multi audio output thread. This
change improves audio clicks quite a bit on my machine. Though they still
happen from time to time and particulary on FS activity.
* Automatic whitespace cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34633 a95241bf-73f2-0310-859d-f6bbb57e9c96
FreeBSD 8 (r199625) and thus adding the FreeBSD license header.
* Implementing the glue code to make the wavelanwifi driver linking.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34626 a95241bf-73f2-0310-859d-f6bbb57e9c96
Both are compiling, but not linking yet. Only for compilation of pci support
has been taken care of, as neither ISA nor PCMCIA are usable within Haiku
anyway.
* Enhancing the FreeBSD compat layer so that the above drivers are compiling.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34621 a95241bf-73f2-0310-859d-f6bbb57e9c96
sys/condvar.h and as such the kernel_c++_structs.h file in their souces.
As Ingo pointed out when introducing the "C++ structs in C only code" feature,
this dependency needs to be put on every target that includes
kernel_c++_structs.h directly and indirectly.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34586 a95241bf-73f2-0310-859d-f6bbb57e9c96
outside of Haiku's repository, only.
* Also this fixes the build break that arose when the Haiku repo was checked
out with something different than svn (git for example:), due to a hardcoded
reference to the svn entries file.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34529 a95241bf-73f2-0310-859d-f6bbb57e9c96
because there is another FreeBSD driver used for 88w8335 chipsets. So the old
name would be misleading.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34470 a95241bf-73f2-0310-859d-f6bbb57e9c96
* playback, tested with 16bit format, with sample rate range from 8 to 48kHz
* recording, fixed at 48kHz 16 bit (read below)
* controlling some mixers, input selector, etc.
I placed the driver in the ac97 directory as it fits better.
Also a few coding style fixes by me.
This driver collides at least with one pci id of the sis7018 driver.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34452 a95241bf-73f2-0310-859d-f6bbb57e9c96
required hardware (many current Macbooks).
This driver needs a firmware. The retrieval of this firmware requires
following steps:
a) Download the linux firmware from http://downloads.openwrt.org/sources/wl_apsta-3.130.20.0.o
b) Download and compile b43-fwcutter from http://bu3sch.de/b43/fwcutter/b43-fwcutter-011.tar.bz2
c) Use b43-fwcutter to cut the linux firmware in pieces.
d) Copy those pieces into /system/data/firmware/broadcom43xx/
e) Prepend them with bwi_v3_ and remove the .fw ending.
f) You also need to create an empty file called bwi_v3_ucode in this directory.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34435 a95241bf-73f2-0310-859d-f6bbb57e9c96
* untested unsolicited response support
* added quirk support for vref and gpio
* vref are now enabled for all inputs, and gpio for some Apple Macs
* replaced dprintf with TRACE and ERROR macros
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34352 a95241bf-73f2-0310-859d-f6bbb57e9c96
The source is based on the FreeBSD RELEASE_8_0_0 code, found in Haiku's
freebsd vendor branch.
This driver enables the network card in my EeePC 1005HA-M, for example.
To compile it issue "jam atheros813x".
* Introducing the new build target.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34348 a95241bf-73f2-0310-859d-f6bbb57e9c96
The driver sources are based upon the FreeBSD RELEASE_8_0_0 source as found in
Haiku's freebsd vendor branch.
* Currently only the atheros driver is working and can be compiled with
jam atheros.
* Every driver contains a Jamfile already, so that the compilation process
can be started with jam <driver_name>. Also note, that linking of every
driver besides atheros and iprowifi2200 will fail at the moment.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34345 a95241bf-73f2-0310-859d-f6bbb57e9c96
checking the physical frame buffer location.
* This allows us to map the whole frame buffer at once, which means there is no
need anymore to remap the memory on mode change.
* Also, this will ease the burden of the MTRRs, as the memory size will be
properly aligned.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34206 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Added support for Radeon X1050, which is essentially an RV370.
I cannot confirm this works, but I assume the creator of the patch can. :-)
Thanks a lot, fixes#3435.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34182 a95241bf-73f2-0310-859d-f6bbb57e9c96
- add generic device descriptions for the various incarnations of the PC UART,
- just use pc_serial as devfs basename regardless.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33858 a95241bf-73f2-0310-859d-f6bbb57e9c96
Closing usb_midi now wake up midi_server port reader, as expected.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33782 a95241bf-73f2-0310-859d-f6bbb57e9c96
* added header for dealing with binary numbers and bitmasks (C++ templates)
these "macro's" might not work well for long words, though
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33749 a95241bf-73f2-0310-859d-f6bbb57e9c96
the network drivers needed to be adjusted to the header reordering, too
sorry
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33740 a95241bf-73f2-0310-859d-f6bbb57e9c96
that. But I didn't think of any better solution either... Hopefully these are
all, but I will find out once I built a complete image.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33641 a95241bf-73f2-0310-859d-f6bbb57e9c96
This solves the "1200-seconds paradox" sorced by ignoring the
"arp who-has" requests send as broadcasts.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33603 a95241bf-73f2-0310-859d-f6bbb57e9c96
- Fixed issues sending data over USB bus (actually write data when
requested to; increased timeout when writing data).
- Added usb_printer to build and Haiku image.
- Sending data to printer over USB bus works now in Haiku (cat ... >
/dev/priner/usb/0). Not sure if it works when printing from an
application as I don't have a driver that supports my printer yet.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33501 a95241bf-73f2-0310-859d-f6bbb57e9c96
hw rev B1, as some early versions use D-Link System vendor ID (0x07d1),
others use D-Link Corp. vendor ID (0x2001)...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33342 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Use the correct interface index for the control transfer that sets a Wacom
tablet into tablet mode.
* Check if the mode is indeed setup correctly.
* Retry switching the mode up to five times, as done in the Linux driver.
Thanks a bunch! As Michael has proposed in ticket #3744, the whole Wacom
driver should be merged into the existing HID driver framework (eventually).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33301 a95241bf-73f2-0310-859d-f6bbb57e9c96
the original BeOS input_server will fail to detect the error and never close
the device.
* Remove the empty kernel_cpp header and use the one from kernel util instead.
* Add some missing headers for completeness.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33242 a95241bf-73f2-0310-859d-f6bbb57e9c96
return an error.
* Properly use the name length instead of a hardcoded buffer size when composing
the name of the raw device and ensure proper termination.
* Case new ioctls for Haiku as the target platform. Indeed this driver works
fine on BeOS even though it was written natively for Haiku.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33240 a95241bf-73f2-0310-859d-f6bbb57e9c96
* add output support
* fix variable lenght input: all usb_midi_event_packet bytes were
always returned before.
Missing features are:
* multiport support (input from any ports are read and merged currently,
so beware to connect only one port!)
* non-standard USB midi adapters, like my Roland UM-2 which don't advertize
themselves as Audio / Midi stream class/subclass.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33126 a95241bf-73f2-0310-859d-f6bbb57e9c96
* increased responses count
* only unmute active inputs on mixer widgets
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33120 a95241bf-73f2-0310-859d-f6bbb57e9c96
such a case as that would try to read info about a non-present medium.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32862 a95241bf-73f2-0310-859d-f6bbb57e9c96
media present they will always fail with the no media or media changed errors.
+alphabranch
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32732 a95241bf-73f2-0310-859d-f6bbb57e9c96
don't try to use it for media status polling. In those cases we'll assume a
fixed device with no exchangable medias and therefore always return B_OK.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32731 a95241bf-73f2-0310-859d-f6bbb57e9c96
of load, when using large enough block sizes or when simply having a slow device
this is by far not enough. It is now at 15 seconds, which should reduce timeout
problems to those cases where the device actually get's stuck (because of us
doing something wrong).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32615 a95241bf-73f2-0310-859d-f6bbb57e9c96
Please report such warnings, they can help to investigate timing issues with some hda codecs.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32589 a95241bf-73f2-0310-859d-f6bbb57e9c96
Also add some paranoid checks: ACPI BIOSes implementation can be... wild.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32584 a95241bf-73f2-0310-859d-f6bbb57e9c96
because all reports schedule transfers on the same endpoint and therefore need
to possibly reschedule. Previously if we got a report that we didn't listen on
all further reports would stop, because noone would schedule a new transfer.
This fixes extra keys not working on my natural keyboard.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32580 a95241bf-73f2-0310-859d-f6bbb57e9c96
device is not compatible, after all.
* No longer accept color changes if the mode is not an 8 bit one. I think that
BWindowScreen does that after changing the mode, so that is messes up the
colors, at least that's the theory, will test on real iron now.
* Use VGA as a fallback if setting the palette via VBE failed. This brings back
the colors for ParticlesII in Qemu (but not in VirtualBox, which seems to be
completely broken in this regard).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32359 a95241bf-73f2-0310-859d-f6bbb57e9c96
* The vesa driver no longer uses VGA programming if the chip does not support
VGA compatibility.
* The VESA driver now tries to set the DAC to 8 bits per color gun.
* In VESA modes, the driver no longer tries to use VGA programming; introduced
the new vesa_set_indexed_colors() that is now used for palette programming.
This should fix wrong colors of 8 bit BWindowScreen users with VESA on real
hardware (emulators usually didn't mind either way).
* Note that the app_server needs to maintain a palette per 8 bit screen, as
right now, the colors are garbled after a workspace switch. Stefano, are you
looking into that already?
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32347 a95241bf-73f2-0310-859d-f6bbb57e9c96
a good idea; it didn't have any consequences in there, but actually broke
the app_server's support for the VGA mode.
* Cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32181 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Reverted r31809 as it introduced a race condition; if the I/O request had been
notified, it could already been deleted at that point.
* Instead, we need to notify the request in each file system/driver that uses
it. Added new notify_io_request() function that does that exactly.
* Added a TODO comment to the userlandfs where the request notification needs
a bit more thought.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31903 a95241bf-73f2-0310-859d-f6bbb57e9c96
* checked what offsets my hardware my hardware really had: it affected only playback, and was 192 for 16 bits and 256 for 20/24 bits. With these values, playback and record are crystal clear.
As I can't find any references for such offset values anywhere, sorry it's not supposed to work out of the box on all hardware. Maybe we could adjust the offset at runtime.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31875 a95241bf-73f2-0310-859d-f6bbb57e9c96
Damn my hardware only supports 20bits input, though this explains why it doesn't work with 24bits input..
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31867 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Make the key arrays take the full range of possible index values (32-bits).
* Forward all unmapped keys with their HID usage as keycode.
* Remove some superflous debug output.
With this many of the extra keys on keyboards should be forwarded as unmapped
keys. An application could now watch for them (B_UNMAPPED_KEY{UP|DOWN} messages)
and interpret them based on their keycode which matches the HID usage.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31838 a95241bf-73f2-0310-859d-f6bbb57e9c96
introduced earlier.
* Reworked the previous device classes to make them ProtocolHandlers handling
their respective input_server <-> driver protocol.
* Implement setting report item data and building/sending reports based on that.
* Remove the old HID parsing code.
This enables us to use all HID devices as we now parse and use the HID
descriptors/reports. Non-boot-porotocol devices should therefore work.
The next step will be to implement a generic input/output framework in userland
that can communicate with a generic protocol handler in usb_hid. This will then
enable applications to make use of all the non-mapped HID stuff directly.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31790 a95241bf-73f2-0310-859d-f6bbb57e9c96
that we lost a few keystrokes, and would make keys (like SysReq) stick.
Thanks to Rene for the note!
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31688 a95241bf-73f2-0310-859d-f6bbb57e9c96
turn Print-Screen into SysReq. Now, getting into the debugger works via USB
keyboards as well.
* I switched the break/pause key detection to Alt, too, although I could not
find any such mechanism on PS/2 keyboards. Someone knows better how to deal
with this one? (the key actually produces two scancodes, 0x1d + 0x45 on PS/2
keyboards)
* Minor cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31670 a95241bf-73f2-0310-859d-f6bbb57e9c96
probably meant to be. The call as it was made no sense at all, as it hardcoded
the endpoint number and tried to supply data to a non-data request. It also
wasn't using a synchronous call, possibly triggering the callback function with
an incompletely set-up device structure, depending on how quickly the request
would return. This caused bug #4107.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31666 a95241bf-73f2-0310-859d-f6bbb57e9c96
TODO:
- Move watching stuff from driver to device cookie so it can be used by multiple instances.
- Find out why we only get notified about AC / battery changes.
- Fetch _BMD info.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31483 a95241bf-73f2-0310-859d-f6bbb57e9c96
- The timeout in Wait was ignored because B_RELATIVE_TIMEOUT was missing.
- Some cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31482 a95241bf-73f2-0310-859d-f6bbb57e9c96
- Free device in correct hook
This allows closing and reopening the bluetooth_server keeping bluetooth functionality
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31053 a95241bf-73f2-0310-859d-f6bbb57e9c96
- Add debug more information in H2 driver and Command Status event
- Change name of port for posting events(former was too long)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31036 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Reorganize how items are added to collections.
* Make collections useful for enumeration through that.
* Added printing out of collections, reports and report items for easier
verification of report parsing.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30821 a95241bf-73f2-0310-859d-f6bbb57e9c96
Fixes using the HDA driver with frame rates based on 44100Hz.
* Automatic white space cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30704 a95241bf-73f2-0310-859d-f6bbb57e9c96
