Instead of adding "dummy views", leave the original views intact
and just add a resizing hack to take care of any movements that
apps have inflicted.
Fixes#16411, a crash in WonderBrush, and compatibility issues
in some other applications.
We need a different constant or mechanism to get the document
window border size, it appears, or a static method to get
a scroll bar's preferred size.
Should fix#16422.
Two indices into the fEntries ring buffer are used in TimeComputer,
fLastEntry which points to the most recent sample and fFirstEntry which
points to the oldest one. The drift calculation then uses the oldest
values pointed at by fFirstEntry to produce smoother values.
Both indices are initialized to 0, then fLastEntry is incremented prior
to writing the first sample, resulting in the first sample to be written
to fEntries[1]. When drift is calculated on subsequent samples, they
were using the uninitialized data from fEntries[0] due to fFirstEntry
still pointing there, until enough samples had been added for
fFirstEntry to be moved forward. The resulting incorrect drift values
would depend on the entry content and ratio between real and performance
time and generally end up being much too small.
The drift values are published on the time source and used to correct
the conversion between performance and real time in
BTimeSource::RealTimeFor(). Given the incorrectly small drift values,
this conversion produced real time values far in the future, causing
increased delays in processes that wait for such computed real times.
One likely victim was the startup of the AudioMixer, as it generally
starts soon after the driver and its MultiAudioNode. If it started right
in the time window where the drift was broken, it would end up delaying
its initial buffer processing by a factor generally depending on the
difference between real and performance time start points, so usually
the difference of the start of the boot process to the start of the
audio driver.
The symptom was then noticable by initial silence after boot, as the
mixer was not producing any buffers until the wrongly calculated real
time had been reached. After that, lots of queued up events were
processed at once, resulting in a CPU spike and glitchy audio for a
couple of seconds after which audio finally normalized. As the problem
was in the MultiAudioNode all mutli audio drivers were affected, HDA
being the most prominent.
As the erroneous delay depended on the initial entry content and the
boot time, it was highly variable. Whether or not the mixer was affected
at all also depended on it starting reasonably early after the driver,
which made the symptom of the bug appear and disappear depending on
slight timing changes, making unrelated code changes look like they were
affecting the bug.
The fFirstEntry index is now updated to fLastEntry after the initial
entry is added, so that the drift calculation always uses valid data.
Fixes#16222, may also affect #15472 and possibly other "no audio"
tickets in case they are really "delayed" audio tickets.
Change-Id: I61f4a67e8b8bf14d2f311cb41b24a1c385aebc19
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3092
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The socket is a blocking one, which means Read() will block unless data
is available, thus WaitForReadable() is useless in this context.
Testing also shows a 2x performance increase from removing this call due
to poll() performance being botched when KDEBUG_LEVEL >= 2.
Change-Id: I3170f865e961112b420c1548726bb6fd38e94cb2
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3078
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This make sure that the temporary buffer will always be deleted should
any premature return happens.
Change-Id: I448ec7c3f3eeca1ef2b6473b49323f34bcb7bf86
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3077
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Instead we can trigger a Read() immediately, as our socket is blocking
and won't return until some data has been made available. This avoids a
potentially costly syscall in the loop body.
Change-Id: I899f55ede41af7cb7e9311aa04006b33c40d3ee4
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3076
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This commit brings the following changes:
- DownloadProgress() should now be reported for every DataReceived()
calls, similar to other BUrlRequest classes.
- Properly verify whether a listener has been set before invoking them.
Change-Id: I4ded82e318ba580b8869c3d1751da4e36882c39f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3075
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This simplify the clean up code path and make sure that the temporary
buffer will always be freed on exit.
Change-Id: I70c1a25bfa66c4f4a96dd3d0af3765a67e305fb2
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3074
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Trigger DownloadProgress after DataReceived, similar to how other BUrlRequest
classes behave.
Change-Id: I4858c3736b1b1ebec55af9903dbfd4b976a77df3
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3073
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Make BFileRequest reports download progress after every DataReceived()
calls.
DownloadProgress() format has also been changed to use 0 as
`bytesTotal` when the total size is unknown. This is similar to
BHttpRequest functions currently.
Change-Id: I2920ea00c4f841bb666425be6f8da418e913c727
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3072
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This commit implements a check for the flag raised by Stop() to cancel
a given request as soon as possible. Cancelled requests will return
B_INTERRUPTED regardless of whether the request has completed,
on par with how BHttpRequest is behaving at the moment.
Change-Id: Ia8a95b910cff158c710c5b2ed58b4675e705642e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3071
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
hrev54429 added some changes to logging in HaikuDepot which broke the
build of the tests.
The build for haikudepottest.so adds some cpp files from the
HaikuDepot source. Now that Logger::NameForLevel and
Logger::IsLevelEnabled are referenced in some of the code being tested
we need to include Logger.cpp as well.
This just adds Logger.cpp to the haikudepottest.so build.
Change-Id: I80a8bb2053c3c78d821ce3cf9902c3a42b0def37
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3056
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
This ensures that the allocated physical memory uses 32 bit addresses.
Also avoid writing to the 64 bit address registers when the controller
is not 64 bit.
Change-Id: I58008d68bcd9579903534f824db2660f73e39160
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3065
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The spec says that changing the DMA memory addresses of a stream should
really only be done after a reset and before the first run. Stopping the
stream is not enough, as the controller is allowed to cache the
addresses even when the stream is paused.
Note that this is applied to both, the initial configuration of buffers
and to the case of dynamically changing stream parameters. In the initial
case this should always be a no-op as the controller was previously
globally reset.
In the dynamic reconfiguration case this fixes random memory corruption
due to the controller still accessing and modifying physical memory that
is released by the driver. With some controllers, such corruption was
easily triggered by changing the input and output sampling rates for the
HDA device in the media preferences.
The return value of the reset call is intentionally not checked to allow
for it to partially or fully fail. At least for HDA under QEMU, the
stream reset fails to start, while the initial stream stop still works
and prevents the memory corruption.
Change-Id: I7c6e6547ee08889a2990de26d5eed5e73b2ca13c
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3063
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Don't unconditionally enable PCI interrupt generation as this only
applies when MSIs are not in use. Delay the evaluation and setting of
the interrupt disable bit until after it is clear whether or not MSIs
are to be used.
Initially force interrupt generation off as early as possible. Depending
on the initial state of the controller, some spurious interrupts might
come up and we really don't want them to occur before everything is set
up in the right way.
Change-Id: Ifb12f5eef1cbf8ecfa3f352564139125d8ad2169
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3062
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This is already properly done in uninit_driver.
Putting the module in device instead of driver uninit meant that on a
device reopen the gPCIx86Module would always be gone and therefore MSIs
could not be used anymore even if they previously were.
Change-Id: Ib3bddefbe6bcb02fa1c97f3c843cecaf31c80e3e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3061
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Just disabling it will leak the vector reservation and makes it
impossible to configure an MSI on the device again.
Also removes the check for the gPCIx86Module as having an MSI configured
really implies its presence.
Change-Id: I9f0e3e63c988af515d23ad93d86918cde9add97a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3060
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This was previously only done if reset failed.
Change-Id: I30ebe1d302087816bccfe67e3d236c9446425aea
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3059
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
In the start case this adds debug output in case a start fails.
For stops this makes sure the stream DMA engine has actually stopped
operating, which is a precondition for some other operations.
Change-Id: I0e2731513febd0e0cd4e1f0ef89cf3d7312a47e1
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3058
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
It is a recurring pattern to set some bits, then wait for them to be
read as set or the reverse. For resets this is done once in both
directions, so factoring this out removes quite a bit of similar code.
No functional change intended.
Change-Id: I2ae4b6cce490c33e1a027328f01fbffea67c5180
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3057
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Remove workaround for BTextView bug from 2006 that no long applies
in FileTypes ApplicationTypeWindow by allowing the text views to
align themselves on FrameResized().
Don't override height on version text views, default height is good.
Change-Id: I41e5a9244c5c79eee3bba133064d016673e008e2
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3053
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
This was the last system daemon/server to not have an icon, so I thought I'd give a go at this!
This icon will still need to be added to Haiku's wpa_supplicant repository however.
Change-Id: Icd4e60ec759daaece30669aa8125fce953bbbf95
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2698
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Two usage scenarios:
* Wrong directory selected when invoking as Tracker add-on.
I often find myself having TextSearch invoked on selected child,
when I wanted it to open in parent context.
* Result was not found in target directory, so maybe the search
should be broader.
Change-Id: I2621f3cec7459572ddae438de4ba42ce74432e28
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3044
Reviewed-by: humdinger <humdingerb@gmail.com>
* An upstream bug exists which results in the tianocore
bios crashing when attempting to read from qemu's
(unconfigured, but present) flash device.
Change-Id: Ie9f02a290abc29cce3a5e279382750c0b14164dc
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3049
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
