* https://github.com/raspberrypi/firmware/issues/643
* Mimics what the RaspberryPi guys adjusted it to in
the firmware.
* Solves corrupted UART serial on the RaspberryPi 2
* I think linux live-probes this frequency via dt-bindings.
Revision of last commit, everything I said about how we needed to
use 8px instead of 12px for the drag width and replicant tray
padding was correct, BUT, because we are subtracting from the
window width setting we need to account for the width of BOTH
draggers, so it becomes 2 * 8px or 16px that needs to be
subtracted -- sorry about that.
The minimum Deskbar width was calculated to fit 6 replicant icons,
however, this calculation doesn't take into account the extra width
taken up by the recently added second dragger. Consequently only 5
16x16 replicants currently fit.
However you can expand Deskbar to fit 6 (or more) icons now so it
is not a big deal.
Would it be desirable to adjust the minimum Deskbar width to fix 6
replicant icons again?
In this commit:
a44504a168
Deskbar: Refactor TRelicantTray::LocationForReplicant()
I made the following assumption that:
* if index == 0 return right away, no calculation required.
But this assumes that the first replicant will always fit on the
same line as the clock which doesn't work if you have a wide clock.
Update to always calculate the position even of the first replicant
in vertical (multi-row) mode.
In horizontal mode we still skip some calculations for the index 0
case.
Also I was using kClockMargin (12px) for the right margin, the
right margin should be only 8px: 5px for the dragger plus 3px more
for kTrayPadding. Finally we add in the width of the clock and
extra clock margin iif we're on first row and clock is not hidden.
Fixes (hopefully the last of) #8641
Damage in latter portions of the downloaded package data can cause the
meta-data for the caching to load OK, but the actual data is unable to
be parsed. In this case, the application can fail to refresh the
broken data. This change will mean that the data is "moved aside" into
another file so that on the next run, the application will load fresh
data in place.
This should have been done along with the time_t change, but I forgot
to check this then.
Technically this breaks ABI against BeOS, but:
1. BeOS used an int32, so we'd already slightly broken ABI here
2. Only one thing at HaikuArchives (VMwareAddons) and one recipe at HaikuPorts
(samba) uses this function at all.
If it turns out some critical BeOS app uses this, then I guess we can enclose
GCC2 guards around it, but since I can't find any evidence of that, I'm
pushing it without them for now.
The only thing of any real use in this directory was the Be Newsletter
article, and the objdump from BeOS R5 (at least I guess that's what it is...)
so I kept those.
As far as I can tell, these functions were "added" because they appear
in a symbols dump from R5. Nothing calls them, they don't do anything,
and they do not appear in R5 headers.
This reverts commit 2960780faa.
Sorry for the noise; I thought I'd run a compile but apparently it was
only a partial one.
It seems that the netboot core is linked into the main bootloader
no matter the build configuration, which means that since this one
function was called, the linker tried to resolve all the other symbols
from that static library. Which of course failed.
The NetStack.h header is currently not usable from C code. So while
net_stack_init() is called from platform code, we cannot call
net_stack_cleanup() from OpenFirmware's platform_start_kernel().
Thus call it directly from main()'s cleanup TODO, having assured
that the function is a no-op when no network stack was initialized.
Signed-off-by: Augustin Cavalier <waddlesplash@gmail.com>
The UDP service does not own the UDP sockets. When shutting down,
inform the bound sockets that the service is no longer available.
This allows subsequent method calls to error out cleanly.
Signed-off-by: Augustin Cavalier <waddlesplash@gmail.com>
Add a cleanup function net_stack_cleanup() that calls a new NetStack::ShutDown() method.
Make sure this method works even if the network stack was never initialized.
Signed-off-by: Augustin Cavalier <waddlesplash@gmail.com>
It is currently done in both ~EthernetService() and ~NetStack().
Since NetStack is where it's added and where an explicit accessor function is provided,
choose that location.
Signed-off-by: Augustin Cavalier <waddlesplash@gmail.com>
UnicodeBlockView::SelectBlockForCharacter and CharacterView::_FrameFor
use the same linear search to find which block a character is in, so I
refactored both to use a shared BlockForCharacter function in UnicodeBlocks.cpp
that is a binary search. CharacterView::_BlockAt also had a TODO comment to
use a binary search, so I rewrote it as a binary search. It's not the same
search as the aforementioned BlockForCharacter function. These two changes
ought to improve the overall performance of CharacterMap.
Signed-off-by: Augustin Cavalier <waddlesplash@gmail.com>
The application was previously making a number of different
requests to the application server in order to pull-down
meta-data (ratings, localization etc...) for packages. This
will now happen in one request per repo. The data is
also cached locally and freshness of the data is checked
back with the server before new data is pulled down.
The reason for the erratic behavior was that the tcp implementation
silently drops window update messages after noting the update but without
triggering any data send event. Before the new TCP patches were applied,
the implementation relied on a retransmission timeout to trigger a send event
after a window update. One of the new patches dealing with the ideal timer
changed the semantic of the restransmit function call and caused the behavior
witnessed.
But a retransmission timeout is not the correct solution to window update. In
fact a retransmission is not a desired effect of window update. So in the patch
attached, I have changed the behavior of the implementation to immediately
acknowledge the window update (along with data from SendQueue) and thus solving
the problem of complete halt in data transmission.
The patch also has the changes re-implemented that were reverted back but had
nothing to do with the issue at hand. For the time being, I have also removed
the "ideal timer" part from the patch (although it wasn't creating any
conflict). I initially decided to implement the ideal timer using the same
timer used for retransmission to avoid adding an additional timer. But as I
have seen, it can be problematic. So I will be re-implementing the ideal timer
and thus it was not included in this patch.
Signed-off-by: Augustin Cavalier <waddlesplash@gmail.com>
Fixes#13704.
