* Don't bother aligning the PCI memory addresses; they will already
be aligned, and even if by some mystery they aren't, map_physical_memory
should be able to handle that. This greatly simplifies the code.
* Use one pointer and then four different offset fields instead of four
different pointers. This is what DragonFlyBSD and FreeBSD do; it's
a negligible loss in performance (or none at all, depending on arch
and compiler) as it requires only one more add, and greatly clarifies
the code as to what's going on.
* Remove (both previously and now) unused fields from the header.
* Compute runtime and doorbell register offsets correctly (there
was a missing bitmask.) This is how it's done on FreeBSD and
DragonFlyBSD.
* Actually write the high bits of the DMA addresses. Checked against
FreeBSD and DragonFlyBSD.
* Tweak error message.
Possibly fixes the "invalid bus space memory access" crash, but
I don't have any hardware that occurs on so I couldn't check.
Tested in VMware, VirtualBox, and on a ThinkPad E550 (Broadwell).
Registrar schedules an event every second to do
fRoster-CheckSanity(). This uses 2.5% cpu on my machine
when idle. Changing it to five seconds lowers it to 0.1%
waddlesplash then pointed me to this bug which changes it
to watch for team deletion and call fRoster->CheckSanity()
As I know little in this area, it's mostly based on what
LaunchDaemon does in MessageRecieved.
* Adds check for completed installation when exiting BootManager
or DriveSetup.
* If installation has completed, quit or restart buttons are maintained,
along with appropriate guidance, rather than the UI reset described in bug
Change-Id: I064ccecb77b1a0e4347e1e36564614383b1409d5
Reviewed-on: https://review.haiku-os.org/c/881
Reviewed-by: Stephan Aßmus <superstippi@gmx.de>
We don't watch its children, and most drivers within it are within
subdirectories. Further, all drivers in it are really symlinks to "bin",
which we also watch. So there is really not much purpose in watching
"dev" directly.
Should fix#4638.
When the canvas api was introduced, ServerPicture was changed to work with Canvas,but this was not updated.
Change-Id: I37c68111f4a60408768656260bfc73a27f1f65f4
Reviewed-on: https://review.haiku-os.org/c/501
Reviewed-by: Stephan Aßmus <superstippi@gmx.de>
addon/network settings/hostname
allowing the hostname for the system to be set by the user using
the preferences gui
Change-Id: I676c368070ef89a20435f97ee39e3caa25abf8f9
Reviewed-on: https://review.haiku-os.org/c/870
Reviewed-by: Axel Dörfler <axeld@pinc-software.de>
Reviewed-by: Stephan Aßmus <superstippi@gmx.de>
If available, getifaddrs() will now return additional entries for
different addresses of an interface. This is similiar to how NetBSD does
it.
This allows software such as libuv to construct detailed information
about network interfaces within the system.
Adrien have some concerns about getaddrinfo() wouldn't correctly exclude
IPv6 addresses after this change so a test was added to cover that.
Change-Id: I8c5d3a02b9294d746ca928a285f40344dfd6e3cb
Reviewed-on: https://review.haiku-os.org/c/874
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Just use BControLook where appropriate. It already provides a nice arrow
drawing function (also used in DeskBar expander and in scrollbar
buttons).
Fix second part of #8900
Changes by John Scipione:
Update menu mark and submenu arrow color with menu text color
Use text color for checkmark and submenu arrow colors, tint less black.
This means that colored bg/white text menu item will also draw a white
checkmark and submenu arrow.
Break out BMenuItem::Draw functionality into private methods _IsActive,
_LowColor() and _HighColor() methods and use them to set the mark colors.
Scale submenu arrow and checkmark with item height (which scales with
font size.)
does not align shortcuts with submenu arrows... but if you were to do
that you'd add item->Bounds().Height() / 2.
Signed-off-by: John Scipione <jscipione@gmail.com>
Change-Id: I8299094ef88bf227510b116eb1b84c261dc94723
Reviewed-on: https://review.haiku-os.org/c/341
Reviewed-by: Stefano Ceccherini <stefano.ceccherini@gmail.com>
Reviewed-by: Axel Dörfler <axeld@pinc-software.de>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* Patch checks for pathless results, and in cases where acpi/hid is returned uses the hid element.
In case of any non-hid nodes returning no path, a separate "unknown" entry is also added.
* Also disables one "not implemented" message in line with https://review.haiku-os.org/c/haiku/+/696
Change-Id: I7ac92c7f3c5cb03401b9502aa345a86f117a5a20
Reviewed-on: https://review.haiku-os.org/c/879
Reviewed-by: Axel Dörfler <axeld@pinc-software.de>
Since BeOS had no anti-aliased drawing except for text, it didn't
matter whether drawing diagonal lines (for example) in B_OP_COPY
or B_OP_OVER. Applying the meaning of B_OP_COPY strictly to everything
else would have broken pretty much every existing BeOS, resulting
in broken drawing for anything but straight lines and rectangles.
The solution was to treat B_OP_COPY just like B_OP_OVER *except*
for text rendering, where we could be compatible with the BeOS
behavior. Nevertheless, one can sometimes observe apps using B_OP_COPY
where they /should/ be using B_OP_OVER for rendering text, resulting
in white edges around the glyphs where the actual LowColor() does not
match the current background on which the text is rendered.
There is however a problem when glyphs in a string overlap. Some
fonts have overlapping glyphs by default (handwriting, etc). With
the LCD sub-pixel filtering, this problem is visible even in fonts
where glyphs don't overlap normally, for example 'lt'. The leftmost
pixel of the 't' is smeared due to the filtering and produces an
almost transparent pixel which is rendered (using the low color as
the background) on top of the 'l'. To fix this, one would have to
render the string into an alpha mask buffer first, and then blend it
all at once using B_OP_COPY. This however defeats the point of
B_OP_COPY, which is to be a performance optimization. So instead, I
opted for the solution that is already in place for everything else,
which is to make B_OP_COPY behave like B_OP_OVER. For the case that
this would have produced a difference, i.e. rendering with the solid
high color, one needs to clear the background using the low color,
before rendering text, or it would have looked broken. So in practice,
there cannot be a difference.
Change-Id: I4348902ae754507f1429e0a9575f03d8ecbce333
Reviewed-on: https://review.haiku-os.org/c/877
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
* Additional newline in tooltip text to prevent clipping on low
resolution displays
Change-Id: I8262256d2eb1cc72fb5ffe502c3112285b4f46e5
Reviewed-on: https://review.haiku-os.org/c/878
Reviewed-by: Stephan Aßmus <superstippi@gmx.de>
We now remove it manually for one library to break the dependency loop.
Change-Id: I24061705b4656d444bbe7b4a6af836303f44c020
Reviewed-on: https://review.haiku-os.org/c/873
Reviewed-by: Stephan Aßmus <superstippi@gmx.de>
Fix 'true' value becomes a class object.
Change-Id: I7d36c024a9fec7c9649765370f529de2df44d7cb
Reviewed-on: https://review.haiku-os.org/c/868
Reviewed-by: Axel Dörfler <axeld@pinc-software.de>
It seems the cronjob that usually updates these was never migrated to
the new server. We should fix that, but in the meantime, these files are
now a year old, so let's update them.
It has been unused since 2010, when the usb_port printer transport
was rewritten to use the USBKit.
Change-Id: I224e07fb35cd9696c07b8f22dd51d3c67d92e0a9
Reviewed-on: https://review.haiku-os.org/c/869
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
The test app currently shows a number of problems in text rendering
* Above a certain font-size, there is no glyph caching, which
also means there is no sub-pixel filtering. It is actually
the same problem right now for all vector-drawing. It uses the
sub-pixel rendering pipeline, but without any filtering.
* This test feels very sluggish. Something is going on which seems
to be very unoptimized. To be observed when resizing the window
and causing redraws.
* Overlapping glyphs are handled wrongly in B_OP_COPY mode. The
problem is that glyphs are drawn one at a time, but B_OP_COPY
also draws the background color. In case some pixels already
drawn with the text color by one glyph are drawn again by the
next glyph, but with the background color, then it looks like
gaps in the text. This problem has always existed. With the
double filtering that was recently fixed, it was just especially
visible, since, due to the smearing, it was much more likely that
there were extra background pixels at the left side of glyphs.
(Right side, too, but without visual effect.) Of course not
completely transparent pixels, those are not drawn, but almost
transparent pixels.
Change-Id: If590a4c93983c5a3ff0772c19074c408be8e1e74
Reviewed-on: https://review.haiku-os.org/c/871
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This includes changes to support the 8188EE device, as well as a
number of critical bugfixes to 8192EE devices, which should make
the driver much more stable and reliable overall.
This driver was completely rewritten and merged with its USB counterpart
in FreeBSD 12. I've imported the USB code, even though it's not compiled
in at all, because it's more than likely I'll get around to USB WiFi support
before FreeBSD 13 comes...
Untested, because I don't have one of these PCI devices.
Yes, this is kind of hacky to put the printer driver as a special case
in here, but we already do this for the Preview driver, and IPP's
printer detection is pretty broken, whereas adding a printer URL manually
seems to still work.
Works around #12702.
It seems some controllers are assigned "invalid" interrupt lines under
the expectation they will be allocated an MSI. So, don't reject
these devices for having an invalid interrupt line until after
we have tried to allocate an MSI for them.
Should fix#14792.
Not used and largely untouched since 2005. FontSelectionView
supersedes FontMenu, and MenuView's options were merged elsewhere
(e.g. Alt/Ctrl swapping now lives in Keymap.)
Now that HAIKU_TOP is a relative path, nearly all paths Jam actually
has to deal with will never contain spaces, so this is now feasible.
Only one issue remains after this commit (namely, setting
HOST_BUILD_COMPATIBILITY_LIB_DIR.)
On a dual-core system with no other applications but the standard ones
running, my standard "compile HaikuDepot with hot disk cache" benchmark
shows a consistent ~5% improvement after this patch (~33.7s -> ~31.9s sys).
On systems with higher core and thread counts, these numbers are probably
very much larger (I'd imagine it could be up to even 10 or 15%.)
Change-Id: I5df2a075bae7c71b84c6fcd33ead60df8e844757
Reviewed-on: https://review.haiku-os.org/c/861
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This was left unimplemented since the dawn of Haiku; but it's so rarely
used nobody seems to have noticed. I've taken care to leave it optimized
for the current thread case.
Change-Id: Ib028a37963b2da6d0ca9b4dbd5a5f4a74ecf25b4
Reviewed-on: https://review.haiku-os.org/c/860
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
This method is much less error-prone than the prior one, as that required
the driver structure to have an exported symbol identical to its "name"
field, a fact that is usually true but not always (we've had an ifdef
in the atheroswifi driver for a while now due to this.)
So when we have it, we now just use the driver_t* directly, which
should push any of these problems from the run-time stage to the
compile-time stage. It's also a significant performance
improvement.
* Print a message when not resuming a thread because it is running.
When I was using this command while working on ipro1000, I assumed
that "no news was good news." But it seems that wasn't the case.
Hopefully future developers will be less confused after this.
* Allow resuming threads that are in "asleep" or "waiting" states,
not just in "suspended" state. Presumably a developer poking around
in KDL knows what they are doing, so allowing them to do this
seems to make sense.
... and B_DO_NOT_RESCHEDULE unset. We already have equivalent panics
for mutexes and condition variables, so it seems to make sense to
check for this too.
There have been some bug reports recently about hard deadlocks with
symptoms (i.e. kernel debugger can't even be summoned) that match
"interrupt handler thread was context-switched while holding interrupt
lock," and this is the only major remaining path to that without
such a check.
This would have also helped me with recent FreeBSD driver porting;
I forgot to pass the flag once and deadlocked my system in precisely
this manner.
Now that we use SYSINIT for the "module" code instead of manually
maintaining lists, we have to make the static library slightly differently.
See inline comment.
Changes to the Haiku module will come in the next commit.
There are a few Haiku-specific changes in here; most notably some
hacks to prevent struct size changes from breaking wpa_supplicant,
and a removal of the full ieee80211_channel structure from some ioctls
where we previously returned it.
FreeBSD 12's net80211 layer contains only 2 small KPI breaks from FreeBSD 11,
so we can upgrade it, apply those 2 changes to the drivers which are affected
(as the changes are in some lesser-used functions), and then upgrade all drivers
one at a time.
* Remove cast to void* in AddItem() at line 775, so that
avoid that the object which was created using 'new' operator
is immediately cast to another type.
Change-Id: I0722661611d0393896c1aac161a702a4c2f1d5d8
Reviewed-on: https://review.haiku-os.org/c/857
Reviewed-by: Barrett17 <b.vitruvio@gmail.com>
* Remove cast to void* in AddItem() at line 363, so that
avoid that the object which was created using 'new' operator
is immediately cast to another type.
* Also remove other casts in AddItem().
Change-Id: Ia20ab39ef50dce12b9d06ca5b1736a8a8e3e9cdd
Reviewed-on: https://review.haiku-os.org/c/856
Reviewed-by: Barrett17 <b.vitruvio@gmail.com>
The currently included version of libfreetype already has the LCD
subpixel filter turned on by default. With the switch from my
"averaging filter" back to Adrej Spielmann's filtering, there was now
another filtering being done on top of what Freetype already does.
There also seemed to be a problem with the left edge of cached
glyph bitmaps, which I didn't bother to look into. The visual result
of this change is that text looks much crisper, and the display
bugs at touching glyphs is gone.
On the other hand, LCD sub-pixel rendering is still turned on
globally, i.e. for all vector drawing, and for uncached rotated
text. The Freetype filtering is not applied there. This problem did
not exist in my "average filter", since it happened at the scanline
rendering level, not only for cached glyph bitmaps. It is however
not a regression introduced by this commit. It needs to be fixed
separately.
Change-Id: If93c2b85ed479670e6679227984fd8d9f77c11f6
Reviewed-on: https://review.haiku-os.org/c/855
Reviewed-by: Stefano Ceccherini <stefano.ceccherini@gmail.com>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* Also implemented recording DrawString(string, length,
BPoint[] locations), which was previously not recorded at all.
* Also implemented playing back recently added drawing commands
in PicturePlayer.cpp. I don't quite understand what this is
actually used for, but it seemed it was forgotten. I just followed
the pattern already established in the code.
* The other important bit in this change is to update the pen
location when it is needed while recording a BPicture. Often
the BView will use PenLocation() in order to transmit drawing
commands to the app_server which use absolute coordinates only.
This isn't actually so nice, since it means the client has to
wait for the server to transmit the current pen location. If there
were dedicated link-commands for pen-relative drawing commands,
the client could just keep sending without waiting for the server.
In any case, the app_server needs to update the pen location in
the current DrawState and even the DrawingEngine even while
recording a picture, because some next command may need up-2-date
state information, such as the font state and the pen location.
* I have not yet tried to find /all/ instances where the DrawState
needs to be updated while recording. This change should repair
/all/ font state changes, all versions of drawing a string, and
all versions of StrokeLine().
Change-Id: Ia0f23e7b1cd058f70f76a5849acb2d02e0f0da09
Reviewed-on: https://review.haiku-os.org/c/817
Reviewed-by: Stephan Aßmus <superstippi@gmx.de>
This time we use the pci_info directly, it avoids a possible race with
PCI config regs, and we already have the value there anyway.
Signed-off-by: Augustin Cavalier <waddlesplash@gmail.com>
One crucial fix by me: check if size == 0. This avoids the deadlock
seen in #14795.
Includes some logic fixes to Haiku-specific code in the MII drivers,
and one new chipset supported by the rtl81xx MII driver. Otherwise,
no major functional change.
mmu_man changed this to be dynamically computed based on the BAR size.
It seems his computation was somehow incorrect, as it tries to allocate
a very large region here which deadlocks in the physical memory mapper.
Restoring this to 128KB un-breaks the new ipro1000 driver on more
recent hardware.
"Fixes" #14795.
pause() has granularity of "hz", which on FreeBSD and in our compat layer
is defined to be 1000 (so, 1ms.) As "safe_pause_us" is used copoiously
throughout startup code, this meant that (1) startup takes 100-1000x longer
than it needed to (this driver seems to most commonly delay for 10us),
and (2) this could in theory block the boot for multiple minutes if one
got particularly unlucky with the scheduler.
Probably helps with or even outright fixes#14795.
