* 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
so should be reusable for bluethooth HID as well (which is the same). The only
missing part so far is the logical collections that would allow nicer
enumeration of the report structure but is otherwise not useful. It should
support all of the HID specs except for usage aliases (even long items that
aren't actually defined should just work if they ever are). Not integrated into
the USB specific device framework and there are no actual drivers making use
of provided functionallity. The parsing was tested and works for all of the 3
devices I had available, but actual interpretation of data is not tested as the
driver side is missing. Will close that gap as a next step and then port the
mouse and keyboard drivers to that framework. Eventually a generic driver that
makes unknown fields available to userland apps in some way should be fairly
easy to implement with that.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30664 a95241bf-73f2-0310-859d-f6bbb57e9c96
- Cleanup and smaller issues in the preferences app.
- Add driver and preferences to the image.
The driver supports some Pentium M and VIA Centaur CPUs (1000 to 2100 Mhz) and need acpi to detect the cpu device, so you have to enable acpi in the kernel setting file to test it.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30234 a95241bf-73f2-0310-859d-f6bbb57e9c96
- Use the fetching function to get snetbuffers => reduced memory leaks& usage, used only 4 buffers per device
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29629 a95241bf-73f2-0310-859d-f6bbb57e9c96
IORequest.{h,cpp}.
* Introduced public <io_requests.h> header. Currently it only declares the
single function BFS uses.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29446 a95241bf-73f2-0310-859d-f6bbb57e9c96
to Haiku for them, I finally got around taking a look at their FreeBSD
drivers, and imported them into our repository.
* They don't compile yet -- looks like our FreeBSD compatibility layer needs
some further improvements.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29445 a95241bf-73f2-0310-859d-f6bbb57e9c96
of the audio group. This is supposed to keep the latency about the same
regardless of sample rate and lessen the requirements on the system
performance when using higher sample rates. Currently the multi-audio
addon uses the highest available rate.
* Added TODO about the highest sample rate seemingly being forgotten in one
place.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29421 a95241bf-73f2-0310-859d-f6bbb57e9c96
we adjust buffer descriptors to take this into account. It defaults to one sample, but it should depend also on the sample rate or the chip vendor.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29322 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Added debugger commands to resolve usb_ids to pipes.
* Adjusted the physical memory allocator to be usable in a slimmed down mode
when running inside the kernel debugger.
* Implemented USB keyboard support for KDL through a kernel debugger add-on.
* Added kgetc() and made use of it where previously individual methods were used
to ensure that reading characters always goes through the kernel debugger
add-ons and the other methods.
This has some preconditions to meet though:
1) The keyboard must be in the boot protocol (currently the case but needs to
be revisited once we have a full usb_hid).
2) The keyboard must be attached to a UHCI root port (i.e. not use EHCI or OHCI,
also not through hubs unless those are USB 1.1).
3) the usb_hid driver has to be opened for this to work. This means that for the
time between initializing USB and when usb_hid is opened by the input_server
there is no keyboard support.
Also note that this has no way of detecting hot-plug, meaning that you can't
re-attach your USB keyboard from the hub to the root port once in KDL.
On the bright side of things, since this is a non-destructive mechanism it is
possible to enter and leave KDL without loosing the USB state.
Tested OK in QEMU, not tested on real hardware yet, will see in a few minutes.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29291 a95241bf-73f2-0310-859d-f6bbb57e9c96
* get e1000 to compile
* remove dev/em from the build (might be removed later on)
* tested on VirtualBox (gcc2,gcc4), VMware(gcc4) and natively on
ThinkPad T500 (gcc4)
* courtesy of Michael Weirauch (emwe)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29247 a95241bf-73f2-0310-859d-f6bbb57e9c96
information and we must not overwrite the last valid buffer. Otherwise we
generate spurious key ups when entering and spurious key downs when leaving
the phantom state.
* Implement getting/setting of keyboard repeat delay and rate so they become
settable by the keyboard preferences.
* Rework repeat handling a bit. With a large enough repeat delay (i.e. bigger
than the report interval of the device) we would never get the timeout case
and therefore never start repeating.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29154 a95241bf-73f2-0310-859d-f6bbb57e9c96
sight. The comparison operator takes precedence over the binary ones.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29121 a95241bf-73f2-0310-859d-f6bbb57e9c96
be keyboards that leave gaps. It's not really specified in the docs, they only
say that the ordering of keys is indetermined. So I guess intermixing empty
slots is equally valid.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29106 a95241bf-73f2-0310-859d-f6bbb57e9c96
won't be implemented, the second currently isn't and the third is. This gets
rid of the frequent "unhandled ioctl" messages when using USB drives and also
adds the nice pendrive icon to the mount list when using USB storage devices.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28948 a95241bf-73f2-0310-859d-f6bbb57e9c96
unlocking the device again, causing deadlocks after unmounting a USB mass
storage device.
* Synchronize on close again, but this time with proper locking of the device.
* Restructured usb_disk_synchronize() a bit and updated comments.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28934 a95241bf-73f2-0310-859d-f6bbb57e9c96
could have messed up the state of other transfers currently running on that
device. Since devices are regularly opened/closed for enumeration/scanning
from different threads, this could've easily lead to bad situations. I've
removed the sync completely as it's not our task to issue it and because
a close doesn't always correspond with an unmount at all.
* Retry receiving the command status wrapper also when another error than a
stall is returned. The specs aren't too specific, but the graphic suggests
this is a general recovery path.
* Do a reset in case there is an error during data transfer to start the next
command from a clean state.
* Make sure we never acknowledge more data than we actually transfered. This
is to make sure devices that return broken residue values do not mess up our
transfers.
* Detect a few more cases of invalid and non-meaningful command status wrappers.
* If the device explicitly tells us that the sync command isn't supported don't
try it a few more times. Only retry at most five times if an unspecific error
is returned that could also come from another (temporary) error case.
* Add a bit more trace output.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28930 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Took the opportunity and cleaned up coding style problems in that file.
Clemens, I hope you're reading :-)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28905 a95241bf-73f2-0310-859d-f6bbb57e9c96
This is a very welcome addition.
* There are a few issues, and maybe questionable decisions (like the dependence
on ACPI), but I see no reason why it shouldn't be added in its current form
already.
* Unfortunately, I could not test it yet, though, as the CPU of my laptop is
not supported; will see if I can find a supported hardware, though.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28903 a95241bf-73f2-0310-859d-f6bbb57e9c96
* use user_memcpy for Haiku in buffer exchange, with interrupts enabled
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28860 a95241bf-73f2-0310-859d-f6bbb57e9c96
* added a pin capabilities attribute instead of input and output pin attributes
* added ATI and nVidia vendor ids definitions
* uses "mic in" and "line in" when pin colors are undefined
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28839 a95241bf-73f2-0310-859d-f6bbb57e9c96
- Fix type field for reporting devices id
- Snooze before panic for non contiguous buffers
- Debug output buffers
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28737 a95241bf-73f2-0310-859d-f6bbb57e9c96
listeners immediately if there was already something in the queue. Factored
out a tty_readable() out of tty_notify_if_available() that tty_select()
now uses.
* This fixes bug #3148.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28687 a95241bf-73f2-0310-859d-f6bbb57e9c96
* check specific node ids for nodes declared as inputs which are really beepers
* when unmuting/setting amp on the input amplifier, iterate on each input instead of only the first one
* also unmute/set amp on the output and input amplifiers for the input and output paths, respectively
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28683 a95241bf-73f2-0310-859d-f6bbb57e9c96
be used.
* Added tty::ref_count. Each cookie keeps a reference. Only when a
cookie is freed the reference is surrendered. A tty is considered used
as long as it is still referenced. This allows to access a tty through
the cookie, even if it already has been closed.
* Fixed tty_deselect(). It was keeping registered select events when
called after the cookie has been closed. The referenced select_sync
structure would become invalid and later attempts to send select
notifications for the tty could crash. Fixes#3126.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28651 a95241bf-73f2-0310-859d-f6bbb57e9c96
I just added a check in bmtphy_probe() as ENXIO is negative on Haiku.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28597 a95241bf-73f2-0310-859d-f6bbb57e9c96
acquire_sem_etc(), but treat it as an error instead. This allows
to kill device polling threads in the input_server and prevents
a busy loop in the kernel then. Before the input_server was shutting
down devices upon quit (happens only when restarting it), this
busy loop could also be observed, since then polling threads would
be quit on exit of the team.
* Supply B_INFINITE_TIMEOUT for the MouseDevice instead of 0. Does not
change anything, but was probably not intended.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28407 a95241bf-73f2-0310-859d-f6bbb57e9c96
* The first problem was introduced by myself, when I added deleting the
transfer semaphore in HIDDevice::Close(). Obviously, I should (re)create it
in Open() then, or it won't work another time. (Open() is now the only place
where it's created.)
* The second problem was when transfers have already been scheduled the
last time the device was open, but never triggered yet. We need to reset the
fTransferUnprocessed flag, or we won't schedule another transfer but
wait on the transfer semaphore anyways in Control(). I also added
canceling the usb transfers with the stack in Close().
* The remaining problems were specific to the KeyboardDevice, the repeat
key stuff needs to be reset in Open(). I also added unsetting the repeat
key when the key release is detected, but this should have already worked,
because the semaphore timeout was reset to B_INFINITE_TIMEOUT.
One can now "/system/servers/input_server -q" and everything will be back
in working order. There may be some remaining problems in the Wacom driver
which I have not yet looked at.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28368 a95241bf-73f2-0310-859d-f6bbb57e9c96
on it are unblocked and get an error.
* Make fOpen volatile to prevent unwanted caching effects when checking it from
different threads. (?)
* Check IsOpen() in the KeyboardDevice class in more acquire_sem_etc() return
cases, analogous to the MouseDevice class.
I am still getting a problem when relaunching input_server with the input_server
add-on thread that ioctl()s on a USB keyboard fd, which should have never fired
because it's a fake device from a KVM. After the first input_server instance is
gone, this thread keeps on busy looping in acquire_sem_etc()->switch_sem() from
within the ioctl() of the KeyboardDevice usb_hid driver. Still on it.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28350 a95241bf-73f2-0310-859d-f6bbb57e9c96
a panic when ejecting a disc, since updating DMAResource isn't implemented
yet...).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28348 a95241bf-73f2-0310-859d-f6bbb57e9c96
parts of the init sequence if that's not the case anyways. This correctly
initializes the engine lock and a few other things, fixing the deadlock in
ticket #2893. This also seems to result in somewhat improved graphics
performance, at least on my X800.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28295 a95241bf-73f2-0310-859d-f6bbb57e9c96
changes on auich.settings are now taken into account when restarting media_server
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27972 a95241bf-73f2-0310-859d-f6bbb57e9c96
* The hardware cursor is now disabled at 640x480 with a Virge VX (before it
was just invisible).
* EDID info can now be read for all S3 chips.
* For the Savage IX, Savage MX, and SuperSavage chips the display is no
longer expanded to fill a laptop LCD display when the mode resolution is
less than the size of LCD display.
* Savage IX, Savage MX, and SuperSavage chips will now display mode
1400x1050 on a 1400x1050 laptop LCD display. Previously the display was
blank at that resolution.
* Previously about half the Savage chips would not draw properly at
1400x1050. That is, the image was badly skewed and unusable. All of
them now draw properly at 1400x1050.
* Some code was reorganized to remove unnecessary and redundant code.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27863 a95241bf-73f2-0310-859d-f6bbb57e9c96
supports many Realtek based NIC which our own driver doesn't support
(for example the RTL8101E). Thanks! Not added to the image yet, since it
causes some problems on my laptop (but could well be caused by the
freebsd compat layer, or by the scheduler)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27843 a95241bf-73f2-0310-859d-f6bbb57e9c96
case the cd_driver_info::io_scheduler field is not initialized and we
shouldn't try to access it. No idea why, but this only crashed with
the gcc4 build.
* Fixed warning with tracing enabled.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27762 a95241bf-73f2-0310-859d-f6bbb57e9c96
This should enable internal MII PHY detection again, thanks to Siarzhuk for
finding this!
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27702 a95241bf-73f2-0310-859d-f6bbb57e9c96
interfaces, endpoints and generic descriptors.
* Add getter for active interface index and simplify the count operation as
it isn't misused to also get interface descriptors anymore.
* Refactor out some common code into helper functions.
* Adapt the USBKit to the changed/new interface.
* Change how alternate interfaces are exposed by USBKit by providing normal
BUSBInterface objects for alternate interfaces that can easily be examined
and used.
* Make BUSBInterface class aware of its alternate index and use the alternate
aware usb_raw functionallity to build the endpoint and descriptor lists.
* Add ActiveAlternateIndex() to find out what alternate is currently active.
* Style cleanup of the USBKit classes, use std::nothrow everywhere and check
all allocations. Simplify some code by removing optimization where the benefit
is questionable.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27409 a95241bf-73f2-0310-859d-f6bbb57e9c96
32 bits data
* Echo audio driver doesn't support 24 bits in a 32 bits container as proposed by the media kit. We just manage 24 bits as 32 bits samples.
* The main benefit of this change is that the hda driver is now working with 24 bits samples (and 192khz).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27362 a95241bf-73f2-0310-859d-f6bbb57e9c96
* check if the device is still opened when waiting for data
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27310 a95241bf-73f2-0310-859d-f6bbb57e9c96
http://www.SpringDaemons.com/stas/if_ae-1214569185.tar.bz2
(This is the wired NIC on the Asus EEE PC!)
NOTE: It is not in the image because it currently still crashes, will look into that soon.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27290 a95241bf-73f2-0310-859d-f6bbb57e9c96
dynamically assign one when needed. Under the assumption that in most
cases a bounce buffer isn't needed, we can thus prepare a lot more
operations.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27185 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Removed B_GET_ICON support from scsi_disk, and scsi_cd. This won't be
necessary anymore soon.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27029 a95241bf-73f2-0310-859d-f6bbb57e9c96
- B_GET_ICON_NAME: returns the name of an icon. This will then be read from
a predefined location on disk (not yet implemented). This would also allow
to add specifiers like "-boot", or "-fat|bfs|ntfs|...", and have special
icons for those.
- B_GET_VECTOR_ICON: retrieves the vector icon of a device, if any.
* get_device_icon(BBitmap*, ...) now supports other color spaces than B_CMAP8.
* Added get_device_icon(), BPartition::GetIcon(), and BVolume::GetIcon()
variants that can also retrieve the icon data directly (like
BNodeInfo::GetIcon()).
* Reenabled the previous BPartition::GetIcon(), based on a patch by
Justin O'Dell - this fixes#1391.
* Tracker's MountMenu class now uses B_RGBA32 icons, instead of B_CMAP8.
* Added vector icon to scsi_disk, and scsi_cd. The former doesn't have any
special removable icon, though.
* Header cleanup, added/updated license, whitespace cleanup.
* Marked deprecated/obsolete driver ioctls in Drivers.h.
* Removed OpenBeOS namespace in the headers I touched that still had them.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27001 a95241bf-73f2-0310-859d-f6bbb57e9c96
our dma_restrictions structure (but we're using blocks instead of bytes,
since unlike the block size, the restrictions attributes are constant).
* We might want to use blocks for the dma_restrictions structure as well in
the future...
* Fixed another bug in the device_node variant of DMAResource::Init(): the max
segment size was specified in blocks as well.
* Removed the "hardcode" block_io module and header.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26973 a95241bf-73f2-0310-859d-f6bbb57e9c96
* added a record stream, assigned it to input widgets: no recorded sound yet, though buffer cycling is ok
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26953 a95241bf-73f2-0310-859d-f6bbb57e9c96
third range, not the first.
* This finally closes#1853 again.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26904 a95241bf-73f2-0310-859d-f6bbb57e9c96
chipset. This should now finally fix bug #1853.
* Instead of reading values directly from the PCI config space, we now just use
the pci_info structure to retrieve them (interrupt, and base address).
* Renamed alloc_mem() to alloc_contiguous() to make clearer what it does.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26886 a95241bf-73f2-0310-859d-f6bbb57e9c96
patch applied, the card didn't work at all anymore.
* Minor 80-column/white space cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26879 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Tracked down the problem[1] to the wrong offset being read from the pci config.
Now matches Realtek's Linux driver. I couldn't find why it worked before as
the value hasn't changed since the original version added to the repository.
This is only verified with my own 8168 but I found no special logic in other
drivers for 8167 or 8169.
[1] See #1853, "RTL8168 recognized but not working"
I don't have the hardware myself to test.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26873 a95241bf-73f2-0310-859d-f6bbb57e9c96
* avoid using read/write and block flags for mapping register memory
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26867 a95241bf-73f2-0310-859d-f6bbb57e9c96
* The use of B_{READ|WRITE}_AREA throughout the drivers is surely alarming.
Defining these flags means that *every user* application can access these
buffers read/write, it becomes visible in userspace like any other memory
(just shared among all apps). I would like to ask each driver maintainer
to see if that is really wished here. If you only need one app to be able
to access it, cloning the area would be more appropriate.
* I came across the use of B_ANY_KERNEL_BLOCK_ADDRESS a number of times. This
is almost completely useless for most usages, as it tries to align the
virtual to a multiple of the size of the area. It just makes the allocation
more likely to fail. Please only use where appropriate, and please review
your code.
* Minor cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26858 a95241bf-73f2-0310-859d-f6bbb57e9c96
* use HDAC_STREAM_POSITION register value to check the current buffer cycle in interrupt handler
* added B_FULL_LOCK flags for area allocation, not sure it's handled but at least more correct
* buffer descriptors now use a low and high address fields
* applied a byte mask on format
* enabled PCI bus mastering if not yet done
* the PCI space register TCSEL (Traffic Class Select Register, which sets PCI express QOS) is now reset to TC0 (clear 0-2 bits) as needed on some boards like mine to
ensure good playback
Playback is finally working correctly here on ICH8 HDA!
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26847 a95241bf-73f2-0310-859d-f6bbb57e9c96
* This should have been part of r26828, although it did not break the build :-)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26829 a95241bf-73f2-0310-859d-f6bbb57e9c96
architecture: for now, we do this on the lowest layer only, therefore all
requests are handled synchronously (ie. in the scheduler's thread).
* Instead of using the block_io module, scsi_disk (and scsi_cd) are now
exporting a device on their own, and use an I/O scheduler with an appropriate
DMA resource.
* There are still lots of TODOs, and it can easily panic - don't update if
you intend to demo Haiku.
* scsi_periph now only has an io() function that get an io_operation, instead
of the previous read/write functions, moved preferred CCB size from those
functions into the device registration.
* Changed all scsi_periph files to C++.
* scsi_cd ported, too, but untested.
* Removed block_io from image - it will be removed completely soon.
* Temporarily commented an ASSERT() in the ATA bus manager (in case you use
it); it's sometimes triggered by the code now, and I haven't yet looked into
the issue -- doesn't seem to harm, at least.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26828 a95241bf-73f2-0310-859d-f6bbb57e9c96
- Enabling all net_buffers code & ACL
- Asume contiguusness for outgoing packets
- Fix incorrect cleaning of btDevices
- Posting ACL data to the net_device Kernel module.
Sumarizing this enables ACL tranmision mode in the driver which starts to be "real network data" of the bt protocols not configuration as we had before
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26638 a95241bf-73f2-0310-859d-f6bbb57e9c96
Hide USB errors better from the upper layers: Only try the "clear feature"
command if the error is B_DEV_STALLED. On other errors, the clear feature
was likely to fail, as it should only be used on stalled devices. Errors
intended to be ignored were thus not ignored because of the "clear feature"
failure.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26555 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Don't spam the syslog when the device was not a Wacom.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26553 a95241bf-73f2-0310-859d-f6bbb57e9c96
* we need to initialize c_ospeed and c_ispeed, as a value of 0 means
'hangup' - which is not a good default, I suppose
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26426 a95241bf-73f2-0310-859d-f6bbb57e9c96
runtime did not work and gave a "General System Error".
Jan Kloetzke provided a temporary work around, the area
which the BIOS can access is enlarged, although according to
specs, this should not be needed.
* After switching modes in the VESA driver, turn on write
combining for the frame buffer area. This gives a huge speed
boost for all graphics drawing. Only people for which mode
changes did not work were using the full speed since the
VESA mode switching support was added.
* Cleanup in the Jamfile, some header directories were included
multiple times.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26395 a95241bf-73f2-0310-859d-f6bbb57e9c96
- Fix some null pointer bugs
- Mark the removed device to avoid killing it twice in the uninit hook (Mika Lindqvist)
* More things might be still missing in the uninit context
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26382 a95241bf-73f2-0310-859d-f6bbb57e9c96
* use HDAC_BIDIR_STREAM_OFFSET and HDAC_OUTPUT_STREAM_OFFSET when applicable
* use a PAGE_ALIGN macro
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26330 a95241bf-73f2-0310-859d-f6bbb57e9c96
the cancel, it wasn't actually done. This could bring a device out of sync in
the case timeouts actually happened (which shouldn't be a commen case).
Fixed that and increased the timeout to 2 seconds in favor of slower devices.
Might need some fine tuning later still.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26197 a95241bf-73f2-0310-859d-f6bbb57e9c96
* With output processing enabled, replace the VERASE char by
BS SPACE BS instead of VERASE SPACE VERASE.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26135 a95241bf-73f2-0310-859d-f6bbb57e9c96
hanging systems on boot, but probably just hides a problem somewhere else, as
the transfers should timeout on their own if the device doesn't respond.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26082 a95241bf-73f2-0310-859d-f6bbb57e9c96
unit attention telling us that the device or media status changed, which is
expected.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26081 a95241bf-73f2-0310-859d-f6bbb57e9c96
the select/deselect/readv/writev hooks. Not that it would matter as the static
memory there is cleared to 0 anyway.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26080 a95241bf-73f2-0310-859d-f6bbb57e9c96
- As more cleaning still needs to be done regarding this subject the ticket is not yet closed
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25944 a95241bf-73f2-0310-859d-f6bbb57e9c96
- do not count usb headers as part of count returned by write(), else we might end up writing more than the passed amount :)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25939 a95241bf-73f2-0310-859d-f6bbb57e9c96
