keyboards due to buttons being padded by non-data arrays. The keys wouldn't
actually be used later, but a (useless) keyboard device would still be
published.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35797 a95241bf-73f2-0310-859d-f6bbb57e9c96
handlers may be added to a single device if it provides more than one report
for a kind of device. Should fix#5549 where two mouse reports are present
and only the first one was picked up and made available as device.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35796 a95241bf-73f2-0310-859d-f6bbb57e9c96
isn't set. I'd tend to say that's a rather odd interpretation of the specified
protocol if a BIOS goes mad if the sem is written to while it doesn't actually
own the controller (it should just be a no-op in that case and directly set the
sem state). But it seems this is what others do as well (FreeBSD, Linux) so we
follow. Thanks to vegardw in #2083 for researching into this and proposing this
fix. Minor other cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35780 a95241bf-73f2-0310-859d-f6bbb57e9c96
magic code. This would lead to them not being detected on systems where the
BIOS (rightfully) returns an error in this case. Since the CHS fallback can't
work it would then fail with "Missing Operating System".
* Fixed a typo, an 80 char limit violation.
* Automatic whitespace cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35718 a95241bf-73f2-0310-859d-f6bbb57e9c96
valid CHS addresses due to not knowing the geometry of the target device
beforehand. So it's mostly just for completeness...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35717 a95241bf-73f2-0310-859d-f6bbb57e9c96
the haiku-anyboot-image pseudo target. As I'm not too much at home with Jam I'd
appreciate any input. Especially for the TODO where removing the MBR using
RmTemps seems to cause a failure to get it built again every other time.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35668 a95241bf-73f2-0310-859d-f6bbb57e9c96
and a Haiku image and fuses everything to a hybrid MBR/ISO image. Since it
contains a valid MBR, partition table and el-torito CD boot record such an image
should be pretty universally bootable. It can be written to disks, USB sticks or
CDs/DVDs. Since it has a partition table in place it is also possible that it
helps with the non-booting USB sticks where the BIOS (wrongly) assumes a
partition table.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35667 a95241bf-73f2-0310-859d-f6bbb57e9c96
certain conditions indicate that we might deal with a fixed 512 bytes MBR on
a non 512 byte block size medium. One condition is that at least one partition
had to be shrunk to fit the available size (which usually happens with larger
block sizes). We retry with a fixed 512 block size once and compare the result
if it didn't improve the situation it is reverted again. This is mostly a
preparation for the upcoming "anyboot" hybrid MBR/ISO images.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35664 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Add file map and cache and do reads through the file_cache for file ICBs.
* Move the private _Read() backend from the header to the implementation file.
* Read() is now only used for directory iteration.
* Turned off the verbose debug output.
* Minor cleanup.
This fixes the abuse of the block_cache, should allow executables on UDF and
won't panic on protected content.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35652 a95241bf-73f2-0310-859d-f6bbb57e9c96
multiple blocks at a time which it doesn't do as it always only returns one
block (and actually completely ignores the provided offset and length).
It only didn't crash after that because it would in the end always only memcpy
length >> block shift bytes which ends up being pretty small in most cases.
Since it does block wise mapping it can't do multiple blocks anyway, and really
using the block cache for this is all wrong because this should really use a
file map to resolve the block mapping and then use the file cache instead.
Still this at least gets it working. Beware though that protected DVD content
will make the block cache panic, as reading these blocks without prior setting
the drive up correctly will fail (the drive will stall the reads).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35651 a95241bf-73f2-0310-859d-f6bbb57e9c96
remove the block from an unlocked cache and the cache->lock would be unlocked
twice when the calling function unlocked. It panics in that case anyway, but
this should make it continuable and is more correct.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35648 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Set the _type as well, this gets file listings work.
* Some cleanup and debug output moves/fixes/additions.
Yet crashes when accessing files though.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35647 a95241bf-73f2-0310-859d-f6bbb57e9c96
to make the guard page inaccessible. Thanks Ingo for the pointer!
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35488 a95241bf-73f2-0310-859d-f6bbb57e9c96
the heap debug panics. Instead syslog output is generated if turned off.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35481 a95241bf-73f2-0310-859d-f6bbb57e9c96
well as the thread allocating it. Can for example be used to verify that an
object or buffer is as large as expected.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35480 a95241bf-73f2-0310-859d-f6bbb57e9c96
keeping all returned heap memory in the 0xdeadbeef state (including the
first sizeof(void *) bytes otherwise for the free list). While wasting a lot
of memory it allows you to rely on 0xdeadbeef being always present as no
future allocation will reuse the freed memory block.
* Also added heap_debug_malloc_with_guard_page() which is intended to allocate
a memory block so it is aligned that the start of invalid memory past the
allocation is in an unmapped guard page. However the kernel backend that would
guarantee this is not yet implemented, so right now this works only by chance
if no other area happens to be allocated exactly past the created one. With a
very specifc suspicion you can put that one allocation you get to good use
though. It causes a crash when accessing memory past the allocation size so
you actually get a backtrace from where the access happened instead of only
after freeing/wall checking.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35478 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Moving some functions around, removing and adding others for the public API.
I've written a blog post at haiku-os.org to go as documentation for this
introducing the API and the other helpful bits.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35431 a95241bf-73f2-0310-859d-f6bbb57e9c96
in r23974, but seeing that it was added to the runtime_loader default paths as
well I take it this was an oversight.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35427 a95241bf-73f2-0310-859d-f6bbb57e9c96
allocated buffers to validate that the full allocated size is actually usable.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35425 a95241bf-73f2-0310-859d-f6bbb57e9c96
the contiguous page allocation function and unlocks a bin locker a bit earlier.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35424 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Make the contiguous page allocation capable of aligning the allocation
and make it more clever by checking up front if there's a chance of getting
enough pages at all, by giving up earlier if the page count can't be fit
anymore, and in the alignment case by only checking the pages which have a
valid alignment.
* If the alignment requirement is > B_PAGE_SIZE we now use page allocation
directly, because the bins aren't necesarily aligned on their size past
B_PAGE_SIZE anymore.
* When doing aligned bin allocation, calculate the aligned size up front and
choose the right heap for the allocation.
* Also when doing aligned bin allocations we not only need to round up the size
but also ensure that the bin we choose is aligned at all.
* Moved adding leak check info into it's own function.
Fixes various misalignment problems when working with alignments > B_PAGE_SIZE
or when using alignments < allocation size. Also the directly aligned page
allocations now only use up as many pages as actually required instead of
allocating based on the rounded up to align size.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35422 a95241bf-73f2-0310-859d-f6bbb57e9c96
pose list and replaced the rather ugly "fFiltering ? ..." everywhere with it.
* Automatic whitespace cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35389 a95241bf-73f2-0310-859d-f6bbb57e9c96
anymore. Also make that test string a bit more complicated.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35386 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Remove no longer necessary support functions.
* The new version uses a single BString as input/output parameter and only
modifies that one by removing non-fitting chars and inserting the ellipsis
where appropriate, so avoids copying around bytes/chars/strings in a few
places. It uses the new Chars functions of BString so also no need for manual
multibyte handling.
* Adjusted the BFont and ServerFont usage of truncate_string() which are both
simplified by using the single BString. It avoids a lot of temprary
allocations and string copying. The char * version of BFont
GetTruncatedStrings() now uses the BString version and not the other way
around anymore which requires us to allocate temporary BString objects, it's
not worse than before though.
* This fixes a bunch of problems with the previous functions like always
prepending the ellipsis for B_TRUNCATE_BEGINNING, crashing on short enough
widths, violating the width in the B_TRUNCATE_END case when the width was
short enough, non-optimal truncation in a few cases and sometimes truncation
where none would've been needed. Also fixes#4128 which was a symptom of the
broken B_TRUNCATE_BEGINNING.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35381 a95241bf-73f2-0310-859d-f6bbb57e9c96
Worse yet for a small enough length it actually crashes.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35379 a95241bf-73f2-0310-859d-f6bbb57e9c96
that special characters can be used as well (umlauts for example).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35375 a95241bf-73f2-0310-859d-f6bbb57e9c96
the corresponding normal functions but have a "Chars" in the name like
"MoveCharsInto" or "AppendChars". Also added CountBytes() and CharAt().
This should make everyday string handling with multibyte strings a bit easier.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35371 a95241bf-73f2-0310-859d-f6bbb57e9c96
pose on a non-visible pose list which would cause poses to get lost from the
unfiltered list.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35354 a95241bf-73f2-0310-859d-f6bbb57e9c96
B_REFS_RECEIVED within a short amount of time (0.5 seconds right now) and
send them to the last window to be appended to the playlist. This allows to
select multiple media files in Tracker and get them inside a playlist of a
single window instead of spawning many individual ones (like when filtering
for an album, selecting all tracks and opening them by hitting enter).
* Introduce special append index values APPEND_INDEX_REPLACE_PLAYLIST (-1, does
the same as before) and APPEND_INDEX_APPEND_LAST. The latter is used when
appending through a RefsReceived() call and ensures that the index is
evaluated at the actual insertion time (in ImportPLItemsCommand::Perform())
as by the time this function is called the playlist count may have changed
already due to multiple RefsReceived() invokations, which would then mess up
the order. This makes the above item work as expected.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35352 a95241bf-73f2-0310-859d-f6bbb57e9c96
functions provided with the given arguments.
* Make use of that looper to replace spawning a thread for each launch task.
On the one side this reduces the amount of used threads (and should fix#698)
and on the other side it makes the order in which refs are sent a bit more
predictable.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35351 a95241bf-73f2-0310-859d-f6bbb57e9c96
changes (which may also happen on creation of new files).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35346 a95241bf-73f2-0310-859d-f6bbb57e9c96
fall out of the selection. The same is later done when removing them from the
matching subset, so moved that to a common EnsurePoseUnselected().
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35345 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Add UpdateAfterFilterChange() with the update part of FilterModified().
* Add StopFiltering() that clears the filter and updates.
* Make use of these functions where appropriate to fix missing scroll ranges
after canceling a filter.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35344 a95241bf-73f2-0310-859d-f6bbb57e9c96
vertically sorted pose list). When enabled typing will filter based on the
currently visible attribute columns. Using shift-space as a delimiter
independent filtering strings can be typed, so you can filter based on multiple
attributes at once to refine results while you type. Filtering stays active
until you cancel it using the escape key. While the filtered result is displayed
all normal file operations can be used. Using the return key while filtering
auto-selects and opens the first filter result, allowing for fast traversal
through directories and directly opening the topmost result.
* Introduces fFilteredPoseList which stores the active filter result. The list
is only used when filtering is currently active, so no syncing is required
otherwise.
* Some minor adjustments to leave out invalidations where non-visible poses are
updated.
* Account for the now possible multiple lists throughout BPoseView.
* Add filter string output to the CountView and made that one a bit wider.
* Added all the settings-cruft for type ahead filtering (defaults to off).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35339 a95241bf-73f2-0310-859d-f6bbb57e9c96
The size instead of the data would be printed. The fixed/non-fixed handling is
generic though, so no need to special case the always non fixed elements.
Since adding of basic types through their Add*() function always generates fixed
size fields, this would only be visible if the data was added through AddData()
with isFixedSize == false. This is the case in compiled resources for example,
hence you would see it when printing the returned messages of BMimeType::Get*()
functions for pre-installed types.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35336 a95241bf-73f2-0310-859d-f6bbb57e9c96
That usually indicates keyboard-like usage and one of my keyboards uses this
type for multimedia keys.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35311 a95241bf-73f2-0310-859d-f6bbb57e9c96
(which is conveniently stored by usb_hid to /tmp for each device you plug in).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35306 a95241bf-73f2-0310-859d-f6bbb57e9c96
Example usage to skip one track forward: hey MediaPlayer Do Next of Window 0
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35294 a95241bf-73f2-0310-859d-f6bbb57e9c96
Keymap as an on-screen keyboard by dropping the sample clipboard content and the
actual keys onto it (including control ones).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35293 a95241bf-73f2-0310-859d-f6bbb57e9c96
layer(s) and logs a timestamp, the thread id, the super volume or super vnode
and interesting bits about call arguments/results to a file (in /var/log). This
can be used for example to debug filesystems without having to manually add
debug output to all the calls, or to analyze access patterns. To add the logging
layer just mount the layer with whatever actual filesystem you have:
mount -t "bfs:log_overlay" /dev/disk/usb/0/0/0 /mountpoint
This would then create the logfile /var/log/log_overlay_dev_disk_usb_0_0_0.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35194 a95241bf-73f2-0310-859d-f6bbb57e9c96
accept() is supposed to return B_WOULD_BLOCK when SO_NONBLOCK is set.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35154 a95241bf-73f2-0310-859d-f6bbb57e9c96
old userlandfs and the BReferenceable now in use by netfs. So better explicitly
set that to avoid nasty surprises (like crashes left and right).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35152 a95241bf-73f2-0310-859d-f6bbb57e9c96
got as a result from read_vnode. The joys of void pointers.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35149 a95241bf-73f2-0310-859d-f6bbb57e9c96
interrupt could be triggered early in the boot process where the ATA channel
might not yet be fully set up leading to KDLs accessing uninitialized memory.
* Automatic whitespace cleanup
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35087 a95241bf-73f2-0310-859d-f6bbb57e9c96
to be read/acknowledged (new) and the status to be read (like before in that
case) which helps discarding spurious interrupts on one controller I have that
would otherwise cause an interrupt storm as the bus master interrupt would never
be acknowledged. The ATA stack will discard the interrupt if it's not expecting
a transfer, so no real harm done.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35083 a95241bf-73f2-0310-859d-f6bbb57e9c96
the enabled interrupts to check if there's anything of interest. This obviously
couldn't really work when clearing the enabled interrupts in the glue code.
This gets broadcom43xx working for me, tested with a Linksys WMP54GS-EU (PCI).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35060 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Fix missing parenthesis in r35040 that caused node monitoring not to work.
* Minor automatic whitespace cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35053 a95241bf-73f2-0310-859d-f6bbb57e9c96
device path + child partition name. When a "raw" device is unpublished the node
removal notification triggers the partition and child partitions to be
unpublished/removed. Since in that case the "raw" node is already unpublished
trying to resolve it in devfs_unpublish_partition() again to unpublish the child
partitions would fail, leaving the child partition nodes behind. When a new raw
device would then become available publishing its partitions would fail because
of these left behind nodes, causing bug #4587. Seeing that this code is more
compact and straight forward anyway I don't quite see why it was changed in the
first place.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34967 a95241bf-73f2-0310-859d-f6bbb57e9c96
canceled status, so we need to collect the corresponding sem release. Otherwise
we would run directly into the old cancel status the next time we schedule.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34932 a95241bf-73f2-0310-859d-f6bbb57e9c96
a timeout leaks these transfers. In the end this would at least lead to a flood
of canceled transfers on device unplug or, worse yet, exhaust the USB memory
pool stalling all further transfers as seen in #4604. Probably fixes both
issues, can't test though as I don't have the hardware.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34915 a95241bf-73f2-0310-859d-f6bbb57e9c96
parent interface. It calls if_addmulti() on it but temporarily sets the ioctl
hook to NULL. We need to account for that so we don't crash on multicast setup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34699 a95241bf-73f2-0310-859d-f6bbb57e9c96
also handles the M_PKTHDR flag. Before, the uninitialized fields could be left over
from earlier freed mbufs and on m_freem previous m_next fields could be returned
resulting in random mbufs being freed. This makes the iprowifi4965 work and fixes
#5089.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34691 a95241bf-73f2-0310-859d-f6bbb57e9c96
accesses the scheduler data inside the thread structure, freeing it first lead
to a crash when a thread couldn't be created.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33940 a95241bf-73f2-0310-859d-f6bbb57e9c96
returns valid data. Since the data is still valid in the copy, we don't need
to clear the corresponding flag when copying a message. This is most probably
the same behaviour as in R5 as Tracker seems to expect that in the case where
a drop is done after a menu was displayed as in #4757. Thanks to aldeck for
tracking that one down inside Tracker, should fix#4757.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33746 a95241bf-73f2-0310-859d-f6bbb57e9c96
the bin sizes ensure that when hitting this case it always allocates multiple
pages. This makes it more flexible for other use cases though.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33726 a95241bf-73f2-0310-859d-f6bbb57e9c96
fit into the existing area. In that case further reallocs could then assume the
wrong previous size and then not copy enough from the original buffer, leading
to lost bytes at the end of the new buffer.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33724 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Allow an allocator to be created on the heap to allow for non-locked
allocators to be created.
* Some cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33721 a95241bf-73f2-0310-859d-f6bbb57e9c96
read out in the ConditionVariableEntry::WaitStatus(). That way you can notify
with a specific status that can be read out on the other end.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33718 a95241bf-73f2-0310-859d-f6bbb57e9c96
wait status and therefore would return directly without actually blocking.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33681 a95241bf-73f2-0310-859d-f6bbb57e9c96
Restore ignoring the BIOS provided width and height in case the timings
suggest a bigger dimension. Also re-add the corresponding comment. Should
fix#4810 and might affect #4807 as well.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33652 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Check for overflows in memory allocation. If someone happened to (erroneously)
try to allocate a negative amount of memory we could overflow and crash
because of the sizes getting messed up.
* Review and update the alignment logic which was a bit broken for the huge
allocation case (reaching the area threshold). Also assert the results so
next time this will be easier to spot.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33638 a95241bf-73f2-0310-859d-f6bbb57e9c96
actual digits. Therefore the buffer was always too small leading to memory
corruption. Use the version that allocates the string for us instead, then trim
it and assign it to the result.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33566 a95241bf-73f2-0310-859d-f6bbb57e9c96
Michael Lotz