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
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
