This change makes to draw parent view before current view if current view
ViewColor is transparent. Views with transparent parts such as BDragger are now
drawing properly without workarounds.
Change-Id: I0450d1f012555137c8e7dd2d08c0c27df39465ff
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2091
Reviewed-by: Stephan Aßmus <superstippi@gmx.de>
Fixes#15548.
This change disables immediate drawing of background on expose and makes drawing background a part of the update session. In previous version expose/update separation is incorrect in some cases. For example when view with B_FULL_UPDATE_ON_RESIZE is resized, it will be updated with expose cause, that will trigger flickering. Correct handling should be update on old visible area and expose on area that became visible. If immidiate exposed area erasing is preferred, it need more work to fix. Anyway delayed redrawing cause problems only on slow machine or on slow responding applications, but current master approach cause flickering even on fast machines and on any application that use non-transparent view color.
Multiple expose/update requests also seems not work properly.
Change-Id: Ibd64eb2545ceb1197f1c8bc89043de6f87f11778
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2021
Reviewed-by: Stephan Aßmus <superstippi@gmx.de>
Changed the keymap filename to match the ISO standard
Change-Id: I009640ed976f155cfba3925e852e543f03475bc7
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2079
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
- Put workspaces settings in their own box below the screen box.
- Put brightness slider inside the screen box (currently it works per
screen, not per workspace).
- Move screen name to the title of the screen box.
Remove Set background... button, but keep its label for MonitorView
tool tip to let you know that clicking on it opens Backgrounds. There
wasn't enough room for this button with the brightness slider.
When brightness slider is hidden the window is shorter (unless you
have a lot of options on the right.)
Change-Id: I8b39d9e074e7e6abca2c37545f21c456289de381
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1984
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
* This will help catch bugs such as in #15607.
Change-Id: I25b28932f9db4e2abe8499dd829c910bb565086b
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2082
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
glibc does the same. Technically, some of these builtins did
not exist / did not work before GCC 4.4, but the source tree
cannot be compiled with a version that old anyway.
x86_64 and _x86 need to keep the old functions for now, of
course; but all other architectures can probably feel free
to drop the s_isnan, etc. functions from their glibc.
This will make upcoming patches easier...
Change-Id: Ifb76ea74076553228c9741a8ee3ecb0e1cf736a3
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2076
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
- The name for the registers were swapped
- The width and height were also swapped in one of them
- Remove some old #if 0 code that touched these registers but has been
disabled for a while.
LVDS panels must really be driven at their native resolution, otherwise
they will simply not work. This means we should basically never touch
the video timings on that side. We need to only set the source size in
the pipe configuration, and let the panel fitter figure out the scaling.
On my G45 laptop, this allows me to use non-native resolutions on the
laptop display. This also means when booting with a VGA display
connected, I do get a valid display on the internal panel (using the VGA
resolution). VGA still gets "out of range", so we're still not setting
up something there.
If I switch to VGA display in the BIOS, I get a working picture there
and garbage on the internal display, which is progress (before I would
get a black screen on the internal display)
Fixes#12723.
This patch fixes the build of unittests on x86_gcc2.
src/tests/kits/shared/KeymapTest.cpp:
* Don't use auto
* Don't use braced-initialization for std::map.
src/tests/system/kernel/vm/Jamfile:
* Link lock.o from kernel source to include _mutex_lock and
_mutex_unlock when linking libkernelvmtest.so
Change-Id: I60e02bfb23334064ec25d767f659a188e393ed1c
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2074
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
The "generic" files are actually not generic at all. They were
imported for the PowerPC port and assume a matching format for float.
However, x86 uses a different format as the values are stored with 80
bit precision in the FPU. Therefore the generic implementation is
not appropriate whenever it does bit manipulations.
The glibc implementation uses the same sourcecode as the x86 version
for atan2, and there is no reason for us not to do the same.
Should fix#14933
Change-Id: I9addcfdf8b0f980c8842480885b59c0133866756
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2067
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
For #15515
As mentionned in the ticket, we may also want to hide the symbols
altogether from libroot for newer API/ABI versions, unless we still want
to provide C89/C99/C++98/C++11 compatibility, in which case we still
need them around.
Change-Id: I0ee267fb6c4c2f4bae9b1ba6f68e2bcefc399a7f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2061
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This patch fixes a bug in the BMemoryIO unit tests that made them
fail and adds an additional test case for read-only buffers.
The failing test case invokes BMemoryIO::WriteAt() with the position
parameter set to -10, which is invalid and should result in a return
value of B_BAD_VALUE. And it does, but the test fails because it was
testing for the return value 5, as in 5 bytes copied.
An additional test case is added for read-only BMemoryIO objects. If
the BMemoryIO(const void*, size_t) constructor is used then it will be
marked as read-only, so writes should fail with B_NOT_ALLOWED.
Change-Id: Icf4b837c77fba2be958f9d3e4b3adb18a23b037f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2066
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This allows to have all the tools (resizefs, fs_shell, etc) merged, and
split out the remaining BFS resize changes in a way that makes some
sense. We can easily merge all the basic infrastructure (ioctls, etc)
without any of the actual resizing code (I'll leave that to
professionals).
libprint had a very conservative size limitation (4MB) for the bitmap it
allocates. This leads to splitting a page to print in several "bands"
(about 5 in my testing). However, these may still be too large for the
printer driver to handle, which means the driver may be further slicing
things up, or other drivers may need the full page anyway and recompose
it in some way.
Instead of an hardcoded limit, now try to allocate a bitmap for the
whole page, and if that doesn't work, progressively increase the number
of bands until we manage to allocate a bitmap. Stop when we have split
the page in 256 bands, as it seems rather pointless to be that far. Call
debugger when this happens, as there doesn't seem to be a way to do
better error handling here (the code used to raise std::bad_alloc if
BBitmap allocation failed, or just return an invalid bitmap and view).
Change-Id: Iba690f68c748d20828709244a23e82a08185390e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1922
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
There is a section of the spec that dictates how TRBs need to be
sized within a TD, and we were not following that. This should
bring us into compliance.
See inline comments for more details.
This is useful for example on the eeePC 701, where the EDID/DDC lines
from the LCD display are not wired to the video card as expected (I
confirmed this by downloading the eeePC schematics, the LCD is somehow
wired to what would normally be a PS/2 port on the embedded controller).
In this case, there is no way we can get the EDID data from the usual
means, however, we still know the panel resolution by looking it up in
the VESA BIOS, and if we found it there, there has to be an LVDS panel,
so we can configure it.
Should fix#14066.
