libprint had a very conservative size limitation (4MB) for the bitmap it
allocates. This leads to splitting a page to print in several "bands"
(about 5 in my testing). However, these may still be too large for the
printer driver to handle, which means the driver may be further slicing
things up, or other drivers may need the full page anyway and recompose
it in some way.
Instead of an hardcoded limit, now try to allocate a bitmap for the
whole page, and if that doesn't work, progressively increase the number
of bands until we manage to allocate a bitmap. Stop when we have split
the page in 256 bands, as it seems rather pointless to be that far. Call
debugger when this happens, as there doesn't seem to be a way to do
better error handling here (the code used to raise std::bad_alloc if
BBitmap allocation failed, or just return an invalid bitmap and view).
Change-Id: Iba690f68c748d20828709244a23e82a08185390e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1922
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
There is a section of the spec that dictates how TRBs need to be
sized within a TD, and we were not following that. This should
bring us into compliance.
See inline comments for more details.
This is useful for example on the eeePC 701, where the EDID/DDC lines
from the LCD display are not wired to the video card as expected (I
confirmed this by downloading the eeePC schematics, the LCD is somehow
wired to what would normally be a PS/2 port on the embedded controller).
In this case, there is no way we can get the EDID data from the usual
means, however, we still know the panel resolution by looking it up in
the VESA BIOS, and if we found it there, there has to be an LVDS panel,
so we can configure it.
Should fix#14066.
6c67c7d63 was attempting to fix a leak caught by a static analysis
tool, but it actually just introduced a double-free bug. Running
`UnitTester BString` will result in a crash.
The original code was correct because, in the event that realloc()
fails in BString::_Resize(), the value of fPrivateData is still
retained. It will be freed by the destructor of BString only if
fPrivateData is not shared by another BString instance, since BStrings
are copy-on-write.
Note that while the change in 6c67c7d63 caused tests to fail, that
doesn't mean those tests are ideal. They only trigger
BString::_Resize() to fail because they depend on implementation
details of hoard2 which limits allocations via malloc() to
1GB. Most malloc() implementations will allow allocations of arbitrary
sizes using anonymous mappings (mmap on Linux, or create_area() in
Haiku). This is a much bigger change, so for now I'm just adding some
comments so that we can revisit these tests if we make a change to the
allocator.
Change-Id: I208c1c7a76b6b4409d237b911c62bb3198e49dab
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2060
Reviewed-by: Stephan Aßmus <superstippi@gmx.de>
In hrev53618 I swapped both the LVDS and SVDO limits for i9xx to be in
the same order (always use "min" for the smallest value and "max" for
the largest, both for dividers and multipliers). But I missed the fact
that P2 is not searched for values in the range as are the other
parameters.
So, the code that picks the appropriate P2 value needs to be adjusted
accordingly. Now that this is clear, put the values always in the same
order (smallest value in "min", largest value in "max") and adjust the
code to comute P2.
Fixes#15573.
Even if we are still not so sure about the veracity of other
filesystem drivers, the BFS driver has had no reported corruption
bugs for quite some time (almost 2 years I think). In fact the
only real corruption issues heard of recently are from KDLs,
which are also a vanishing issue.
So, disabling the warning entirely for BFS partitions probably makes
sense at this point.
Change-Id: I5470c956d57b90ea00b647bf15299ba606ba01c4
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1822
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Declare loop variables before the for loops to be compatible with C89.
Fixes#15583.
Change-Id: If2a3b4447a88bb2e65c5ff4166f32df1b26fd859
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2058
Reviewed-by: Alexander G. M. Smith <agmsmith@ncf.ca>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
They have generic names and are likely to conflict with other things. In
particular, there is another BPrivate::TitleView in BColumnListView,
which results in weird behavior (and me wasting days debugging things
and scratching my head) when one links libmedia before libcolumnlistview
and the wrong one ends up being called.
The PCI enumeration functions are not implemented in the compat layer,
so we need a glue function that performs the Haiku equivalent here.
This code existed in the old Haiku-native driver, so it's just
copied from there.
The within-an-attempt timeout did not successfully break up
deadlocks that occur on a system with a lot of USB transfers
going, as we may never hit 2 seconds in between wake-ups,
but the size requested may be un-fulfillable regardless.
So, now we have a 2-second overall timeout. This fixes
the system freeze in #15569, but now attached USB disk
drives enter a Stall state, making the system unusable
anyway.
In hrev53370, leavengood refactored this function out of
PackageVolumeInfo::SetTo(). Inside that function, there
is a "state" variable which is initialized to the first,
default state, which is always the head state.
Refactoring it out of there and changing this to NULL meant
that GetNext would always return a NULL state, so the
states would never be initialized, and booting from an
old state would thus not be possible.
Fixes#15380.
The labels were never actually translated, only marked for use in
catalogs. Moreover, all the keys were sent as a single string, which is
unconvenient for translation and requires useless parsing in the code.
Use an array of strings instead, which is simpler.
There is a change to the archiving format, instead of storing the whole
keymap, only its name is stored. For backwards compatibility, if we
detect "ln" at the start of the string we use scientific mode.
Change-Id: I566d8d51e8ac6e780fc25207aad1dfa7ff737988
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2049
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* Drop gnu-efi
Change-Id: Ib601fc8ced49b18281b6b98cf861a5aef1b9c065
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2026
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
enable to check whether a shutdown process is in progress.
Change-Id: I8efdddb3caa80e9fd188f202b6e92a888a7608e5
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2042
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The base problem was, that every time I opened KeyMap while a Terminal
was opened too, it eventually crashed. I followed along the trace and
found that the code first frees the keymap and keymapchars in the
_UpdateKeymap() and then calls SetKeymap for every tab opened which
also tries to free the old keymap and keymapchars.
TermWindow's _UpdateKeymap() method first frees the old keymap and keymapchars:
delete fKeymap;
delete[] fKeymapChars;
and then calls SetKeyMap for every tab which tries to free the old keymap and keymapchars again:
for (int32 i = 0; i < fTabView->CountTabs(); i++) {
TermView* view = _TermViewAt(i);
view->SetKeymap(fKeymap, fKeymapChars);
}
So TermView simply is not responsible for the memory, it merily has a pointer.
Fixes#15502.
Change-Id: Id08c863d811fbb72cce9be4c8fff2d3eb5f0064f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2037
Reviewed-by: Stephan Aßmus <superstippi@gmx.de>
The context buffer needs to be freed manually. This was already done
correctly in the destructor, but was missing from the error case.
This lead to a leak of at least 32K for the initial allocation or
potentially a lot more, depending on how much avformat_open_input
extended it for probing.
Change-Id: Ib4c751c7de9430926ae82b397803ac93ecfffe5d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2038
Reviewed-by: Stephan Aßmus <superstippi@gmx.de>
Change-Id: I19b5b2c4609da8474b26588ae8d7d4caf72a826b
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2018
Reviewed-by: Fredrik Holmqvist <fredrik.holmqvist@gmail.com>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
On Turkish F layout Shift+2 produces single quote, although it
should return double quotation mark. Probably this is a result
of an error whilst copying from Turkish Q layout.
Turkish Lira Symbol has been added to the both layouts,
produceable with ALT GR+T, as this is the standard combination
on Turkish layouts.
I've also noticed that most of the keys produce a whitespace with
the ALT+GR modifier, fixed that one as well.
This commit also adds non-breaking space to ALT GR+Space modifier
Change-Id: I9eb47ae70449c75b15b551f081f8767b1ab03cc5
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2004
Reviewed-by: John Scipione <jscipione@gmail.com>
