* 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.)
As Jam prints the entire erring command on failure, including this if-test
in the command itself makes the output somewhat difficult to decipher.
So instead we use two separate rules based on whether or not NO_DOWNLOADS
is set or not.
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>
We don't include the wpa_supplicant on the minimum image, so
these aren't very useful (it seems one needs the wpa_supplicant
to connect even to an unsecured network, with our setup.)
Anyone who needs one of these and also has a reason to use the
minimum image can easily add them back via their UserBuildConfig.
