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>
There is no reason to not allow this, and it makes it possible to load
data from eg. a BResource instead of a file, which is very useful.
Remove some unused members in the class and dead code, and fix style
issues.
Change-Id: I94cbd0c13c469ea80f55028cf33dfde2de4365ef
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2001
Reviewed-by: Stephan Aßmus <superstippi@gmx.de>
A user has reported having some problems around
initial use of HaikuDepot and this seems to be
related to setup of the directories etc... at
start time. This change should improve the
logging so that it is easier to identify the
cause. Also some additional locking has been
introduced as there might be a problem where two
threads are creating the same directory at the
same time.
Relates to #15493
Change-Id: I4cbfda7c2ce87b8509ceb78788b7995ee3185050
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1980
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
The "versions" table is populated from two sources: the elf
"needed_version" and "version_definitions" tables. Both populate
specific index in the version table. Each index has an hash, and one or
two strings.
The algorithm to find data in this table is to compare by hash, and then
do an strcmp on the strings when the hash matches.
However, nothing guarantees that all the indices in the version array
will be used. Indeed, libavutil does not use the first two. These were
left uninitialized.
It could happen that one of these would accidentally have its hash equal
to one of the actual hashes we need to lookup, and invalid string
pointers. This would of course lead to a crash. This was reproductible
easily with WebKit when loading the fmpeg add-on. I guess that hit just
the right allocation/deallocation pattern to make the runtime_loader
reuse memory from a block where it had previously stored the same hash.
Anyway, just clear the whole version table after allocating, so that
unused entries have an hash of 0 and NULL string pointers, this way they
can't accidentally trigger a hash collision and crash everything.
Like moveList and copyList, duplicateList could be deleted here.
Pointed out by Clang static analyzer.
Change-Id: Ic80181af960bc8eb759449ea5719e9a439a877a0
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1996
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
This would lead to no valid PLL combination being found, and
uninitialized stack memory eventually used to set the PLL. Add a memset
and a debugger() call to make this easier to notice.
Should fix#14368
Change-Id: Iff307439dc82a8b81bb46c1b73b63c21ee1c8279
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1898
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
- Remove duplicate and otherwise unused lendian_bitfield.h
- Adjust listusb jamfile to use lendian_bitfield.h
- Fix various typos in usb_video.h and restore some fields to make
listusb happy
- Factor in types changes (introduction of intptr_t)
- Align JamFiles syntax with in progress architectures (arm/sparc)
- Xorriso doesn't support much of the mkisofs options (anymore ?)
- (After a correct bootstrap) one should be able to build @minimum-raw and haiku-boot-cd again
Change-Id: I4f779ad8f2210389fa9b7f7c0a98c3652a64c257
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1983
Reviewed-by: François Revol <revol@free.fr>
It seems some drivers do not create dmamaps for all their bustags,
so we can't allocate the segments there. And of course, some also
do not go through dmamem_alloc, so the only option then is to revert
to where FreeBSD allocates them, inside dmamap_load.
Using the geonames.org API, so we will need an API key for it (similar
to the one used for MLS, deployed by the buildbot)
The unit tests uses the "demo" user, which is restricted to 20000 API
call credits and often expired. But we cannot use our secret key here as
it would need to be available to anyone running the test. If we ever get
to automate running the tests on a buildserver we could probably make it
use the secret username known by our buildbot instead.
Change-Id: Ia16880db82555ce85505ad28e1c623f692f46be0
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1873
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
It seems that some drivers (e.g. broadcom43xx) create a parent DMA tag
with nsegments set to BUS_SPACE_UNRESTRICTED, i.e. MAX_INT, which of
course fails allocation, expecting to never allocate memory for this
tag, only for child tags. So in order to handle this, we have to
delay allocating the segment array until we are certain that the nsegments
value is the "real deal".
Doing it in dmamap_load would be fine, but as there is more than one
entry point to that, we would have to allocate this in multiple places.
dmamap_create() must be called and there is only one way through it,
so put the allocation there.
Fixes#15500 (i.e. both the KDL and the underlying problem that
led to it; it only crashed because the wrong pointer was passed
to kernel_free, whoops.)
In two places in elf.cpp, sprintf is used which does not check for buffer overflows. This could potentially lead to malicious executables trying to reach memory
they are not supposed to. Instead, it's possible to use snprintf with a sizeof() call.
I'm not very well-versed into C/C++, so this is just based on what I've learned. Please do provide feedback, I would like to get into more useful contributions :)
Change-Id: I9c36a9938f9c99b3849e77aa9cd2eab313f5bb95
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1975
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
* Move x86 hpet behind timer interface.
* Add a few if x86,x86_64 macros to start.cpp.
Change-Id: I583ec1b064785182e6d48dfbcd91b1bb2ead4b44
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1929
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
* Add a link to the Quick Tour to the desktop.
* Remove the Welcome page from desktop. We don't want to clutter
the user's desktop more than necessary. As "Home" page of
WebPositive, it's still very visible.
* Mention the Quick Tour in the Welcome package description.
* Add a "quicktour" script similar to the welcome/userguide
that opens the online version if it's not installed locally.
* Add icons to the userguide and quicktour scripts. Fixes#14706.
* Add bookmark and launcher for the Quick Tour.
Adjust the AddFileDataAttributeRule to create its temporary file in
the "common" architecture, the file is not architecture specific.
Add a rule PrepareScriptWithIcon in src/data/bin/Jamfile to assign
an icon and make the script executable.
Change-Id: Ia7604ff4715a5aaf9a645c1b3333a954d6a4dafc
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1924
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
It's simpler to have these around, they allow autotools to find the
functions the regular way (using AC_SEARCH_LIBS) as the autotools don't
use the include file and can't see the #define we are putting there to
redirect to the __ prefixed version of the methods.
Change-Id: I6a9743e88503fbdcba98e276375bc11f73a64411
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1889
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
This reverts commit 3a2175926b.
A single week is clearly not enough to test a new memory allocator.
Bring back hoard2 for the time being, we'll consider rpmalloc when it
actually works better.
BString initialization can fail, even when it's allocated on the stack.
Use a const char* to make this code simpler. We lose the ability to
differenciate unknown opcodes, but these should not happen, or the
function should be extended to handle them all.
The previous code used a fixed margin, which would lead to too small
bars with small font sizes (the bar content would not even be visible).
Instead, use the font height as the base for the bar height, which
allows us to use the same code everywhere, no matter the menu item
height (which can vary depending on if there is an icon, etc)
Fixes#15391.
Creating a BReferenceable sets its reference count to 1.
create_port() was then acquiring 2 references for the two lists
it inserts the port object into, and subsequently delete_port()
releases those.
But that "reference 0" never was released anywhere, and so
despite being removed from hashes, etc. port objects were
just leaked, along with whatever messages remained in their
queue, never to be freed. This of course can add up pretty
quickly in systems that created and deleted ports frequently,
for instance, in long-running media playback, opening/closing
applications, etc.
As far as I can tell, this bug was introduced in the fix to
#8007 (7f64b301b1), which introduced
the ref-counting system to the port heap, so it has been with us
since 2013 (!).
Fixes#15489, and probably some of the other "media playback
memory leak" tickets.
The old implementation was based on an ancient copy of the FreeBSD
busdma code for x86, and did not make a bunch of assumptions that
we make basically everywhere else (for instance, that we can request
arbitrarily-aligned contiguous physical memory from the VM.)
As a consequence, it had a significant amount of code devoted to
bounce pages, which are just a waste of resources on x86, and
for that matter, probably any other architecture Haiku will ever
be ported to. (Even if we do need to run on some system where
only a small portion of system memory can be accessed by devices,
likely we would reserve that memory for just this occasion anyway.)
I was initially under the impression that the bounce-pages code
never turned on, but apparently due to the "alignment" check
(and also the "Maxmem" check, which was to defined to 32KB...?!)
it does indeed activate on a variety of systems, and maybe
(in the case of drivers that do not call sync() properly) even
is the cause of some of our ported driver breakage.
The new implementation is pretty much optimized for Haiku,
and shares almost no code or structure with the old one (save
for a few functions that really only have one proper implementation.)
Tested with ipro1000 and rtl81xx. Regressions are more than possible,
so please don't hesitate to file bugs if your network driver now
fails to come up (or you get KDLs.)
Jérôme Duval