This safes a HasGlyphs() call which would convert the whole string to glyph
codes and look each of the glyphs up in the cache entry, just to do the same
again during the loop where they are actually used. Instead we now simply switch
to the write lock and look up the fallback entry when hitting the first uncached
glyph. This benefits the normal case of having all glyphs cached without any
drawbacks.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@40186 a95241bf-73f2-0310-859d-f6bbb57e9c96
1. If the glyph is cached, return it, as before.
2. Try to find a glyph in the fallback font, as before.
3. Check for ignorable characters as per Unicode and cache and return a zero
width glyph (rendering as completely invisible).
4. Reset to the original font.
5. Check for whitespace as per Unicode and cache and return the normal space
glyph.
6. If there still is no valid glyphIndex, continue with index 0 which caches
and returns the usual "missing glyph box".
This implements the Unicode suggestions on how to handle missing glyphs and
closes#7077.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@40174 a95241bf-73f2-0310-859d-f6bbb57e9c96
* The code used continue to restart the loop when encountering a missing glyph,
but in that case the index wouldn't be incremented, meaning the consumers
would received the same index for ConsumeEmptyGlphy() and ConsumeGlyph() and
at the end there was not necessarily a call for every index, resulting in
uninitialized array elements for GetHasGlyphs, GetEdges, GetEscapements and
GetBoundingBoxes.
* Since the advance values were not reset in case of a missing glyph but still
added for the next char, the coordinates the consumers would get were advanced
by the advance values of the glyph preceeding the missing glyph(s). This made
StringWidth return wrong widths.
* The loop end condition was skipped by the continue as well, which would have
resulted in overruns when there were problematic chars at the end of a string.
Fixes#7075 where the uninitialized array elements caused random truncation
errors. The problematic character in this case is a tab, that has no glyph as
it is a dynamic spacer. Previously this was resolved to the "missing glyph"
(the box) which had a width.
I find it highly problematic not to fall back to such a glyph, because there is
no real way to see that you're using a font that has missing glyphs. Instead
those are simply collapsed to nothing with this change (instead of being
random). This whole problem is only brought up by not guaranteeing that there
always is a glyph as was the case before where a missing glyph was replaced by
the box.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@40172 a95241bf-73f2-0310-859d-f6bbb57e9c96
back scrollbar icons and menu markers for example after they got broken when
the offset was introduced.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@40019 a95241bf-73f2-0310-859d-f6bbb57e9c96
relevant parts (i.e. removes clipped or out of bounds parts) and does local
scaling in case the view rect is smaller than the bitmap rect. This avoids
sending the full blown bitmaps across when they are in the end scaled to a much
smaller representation. It's nowhere near perfect yet, but it's useable and
improves the network traffic heaviness quite a bit depending on the application.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@40014 a95241bf-73f2-0310-859d-f6bbb57e9c96
support some 7 years ago...
CID 10246, 10245, 10244, 9471, 9454 and 9453 all concerning that (in the
different constructors / assignements).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@39983 a95241bf-73f2-0310-859d-f6bbb57e9c96
though it's used only in the special case of running as BApplication.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@39977 a95241bf-73f2-0310-859d-f6bbb57e9c96
variable names, added TODO, variable declaration on first use, simplify some
code, add missing sanity checks...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@39972 a95241bf-73f2-0310-859d-f6bbb57e9c96
* CID 2500 and 2501: Check the BMessage::FindData() returns.
* Defensive programming: Take the bitmap/cursor BitsLength() into account when
copying the data back.
* Some style cleanup, automatic whitespace cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@39971 a95241bf-73f2-0310-859d-f6bbb57e9c96
the address variable is incremented in the loop above and at the end will be
equal to sNextVirtualAddress if the address space can be reused. Fixes early
boot resets due to wrongly reused virtual addresses (and them being freed while
still in use by the original user). Fixes#7026, thanks to Urias for testing.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@39961 a95241bf-73f2-0310-859d-f6bbb57e9c96
Taking the size of a pointer instead of the actual extended registers struct.
Not sure this is used, but if it is it made the whole fpu/sse state in the
debugger useless.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@39960 a95241bf-73f2-0310-859d-f6bbb57e9c96
the trace output against header being NULL (i.e. failed to map).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@39958 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Use strlcpy() instead of memcpy() to ensure that the dirent is properly
terminated.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@39954 a95241bf-73f2-0310-859d-f6bbb57e9c96
bytes were initialized to 0 due to wrong use of sizeof().
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@39953 a95241bf-73f2-0310-859d-f6bbb57e9c96
on a set view bitmap and are set when setting one.
* We can safe that resize_frame() call in case no view bitmap is set.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@39931 a95241bf-73f2-0310-859d-f6bbb57e9c96
the data was never correctly attached.
* CID 5886 and 5887: escapements and offsets were not freed in the error case.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@39930 a95241bf-73f2-0310-859d-f6bbb57e9c96
"empty glyph index" as per freetype (which is eventually called) actually is 0,
so a != 0 comparison should be correct. Untested though.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@39929 a95241bf-73f2-0310-859d-f6bbb57e9c96
actually hit this limit.
* Use snprintf() instead of sprintf() as suggested by CID 6447 (even though the
USB module isn't supposed to return such a malformed string).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@39908 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Check the length of the incoming buffer before accessing it through the union.
It's necessary to do this dependent on the operation at hand, since the caller
doesn't need to provide the full union size and the size may differ between
(still compatible) protocol versions.
* Replace memcpy() by user_memcpy() where data is exchanged with userland.
* Small style cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@39907 a95241bf-73f2-0310-859d-f6bbb57e9c96
variable. Didn't matter, as the parameter is only accessed through the
usb_raw_command variable that it is casted to early in the function. CID 5219.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@39906 a95241bf-73f2-0310-859d-f6bbb57e9c96
crash trying to delete the not created allocator. CID 9562.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@39905 a95241bf-73f2-0310-859d-f6bbb57e9c96
Coverity was intentional (as explained by the comment). That the fInterval
member was somehow totally forgotten though, wasn't. This should only affect
EHCI and OHCI as they take the interval into account. Might fix some strange
behaviour, but most likely won't, as the interval range is rather narrow and
shouldn't be too noticeable if set incorrectly. CID 9558.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@39904 a95241bf-73f2-0310-859d-f6bbb57e9c96
rules and support files that don't really apply anymore.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@39763 a95241bf-73f2-0310-859d-f6bbb57e9c96
well this was working, but since it was non-functional on Haiku anyway this
shouldn't hurt.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@39762 a95241bf-73f2-0310-859d-f6bbb57e9c96
and doesn't come with BeOS backwards compatibility. It also has the BeOS
compatibility ioctl ops removed and such. I've actually made this back in april,
so I don't really remember any more details.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@39760 a95241bf-73f2-0310-859d-f6bbb57e9c96
but this one should go into alpha2 to make the card work as before.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36746 a95241bf-73f2-0310-859d-f6bbb57e9c96
it makes use of gPCI which is initialized during pci module init. Might help
with #5936.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36745 a95241bf-73f2-0310-859d-f6bbb57e9c96
need to convert the looked up label position to a char code. Also actually make
sure that the trigger is lower case by doing an explicit tolower() instead of
assuming that it already is.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36316 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Ensure that there is still buffer left when 0-terminating the buffer in
RealText().
* Remove the fExtraCount member and instead make it into a constant as that's
how it's used and more obvious.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36306 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Large cleanup in _FindLineBreak(), be a bit more clever by storing the found
offsets instead of calculating them multiple times, use
_TabExpandedStyledWidth() instead of _StyledWidth() and manual tab calculation
which was also broken (it assumed tabs were consequtive which was possibly not
the case).
* Modified CanEndLine() to also return true when going from non-whitespace to
whitespace and the other way around which is more logical (so we'd break after
the word and not after word + whitespace, even though we actually do that
in the end by eating whitespace after words in _FindLineBreak()).
* The TextGapBuffer is not necessarily 0 terminated, so RealCharAt() needs to
check if the index is at the end of the string and return 0 in that case.
Before it would access the buffer "out by one" which could've lead to a crash.
* Simplified the gap moving calculations by removing some no-op calculations.
* Added debugger calls in TextGapBuffer in case of invalid use.
* Some minor cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36304 a95241bf-73f2-0310-859d-f6bbb57e9c96
double/deadlock when we delete heap areas because of other area deletions.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36284 a95241bf-73f2-0310-859d-f6bbb57e9c96
The O_CLOEXEC open mode wasn't actually set in the close-on-exec bitmap causing
all files opened with O_CLOEXEC (like done in the storage kit classes) to still
be inherited. This caused for example to be unable to unmount volumes when
opening apps while Tracker touched some files (i.e. copying some large files)
since these apps would inherit the file descriptor and therefore keep the
volume busy.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36273 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Add file descriptor and IO context tracing.
* Some minor cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36272 a95241bf-73f2-0310-859d-f6bbb57e9c96
devices it's uninteresting, but for EHCI it may be implemented some day.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36246 a95241bf-73f2-0310-859d-f6bbb57e9c96
transfers was created with wrong permissions leading to a read-protected area.
Since we actually support read-protection in Haiku this caused a crash for all
fragmented transfers (transfers > 384K) leading to #5538.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36245 a95241bf-73f2-0310-859d-f6bbb57e9c96
the device again. Makes Axel's USB stick work and might also help with other
(broken) devices.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36234 a95241bf-73f2-0310-859d-f6bbb57e9c96
compatibility layer. This should make some network and wireless hardware use
MSIs and therefore solve issues related to interrupt sharing and wrongly
advertised interrupt lines.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36225 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Implement such a module for x86 which currently exports only an MSI API.
* Implement the PCI part for configuring and enabling MSIs.
* Some automatic whitespace cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36223 a95241bf-73f2-0310-859d-f6bbb57e9c96
interrupts (MSI).
* Add the remaining IDT entries and redirection functions in the interrupt code.
* Make the PIC end_of_interrupt() return a result to indicate whether the vector
was handled by this PIC. If it isn't we now issue a apic_end_of_interrupt()
in the assumption of apic local interrupt, MSI or IPI. This also removes
the need for the gUsingIOAPIC global and doing manual apic_end_of_interrupt()
calls in the SMP and timer code.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36221 a95241bf-73f2-0310-859d-f6bbb57e9c96
other places where previously the same functionality was duplicated. Also
seperated the header which was originally arch_smp.h into apic.h and arch_smp.h
again as some of it is MP and not actually APIC.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36182 a95241bf-73f2-0310-859d-f6bbb57e9c96
and easy to implement since ATAPI basically is SCSI anyway and we don't use many
problematic commands. Only tested for the 0x05 subclass, but 0x02 should work
the same.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36162 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Unlocking a removable drive was done in the wrong error label which would've
resulted in accessing deadbeef due to the volume being freed just before its
use or using the not initialized volume variable.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36103 a95241bf-73f2-0310-859d-f6bbb57e9c96
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
Michael Lotz