The old implementation was based on an ancient copy of the FreeBSD
busdma code for x86, and did not make a bunch of assumptions that
we make basically everywhere else (for instance, that we can request
arbitrarily-aligned contiguous physical memory from the VM.)
As a consequence, it had a significant amount of code devoted to
bounce pages, which are just a waste of resources on x86, and
for that matter, probably any other architecture Haiku will ever
be ported to. (Even if we do need to run on some system where
only a small portion of system memory can be accessed by devices,
likely we would reserve that memory for just this occasion anyway.)
I was initially under the impression that the bounce-pages code
never turned on, but apparently due to the "alignment" check
(and also the "Maxmem" check, which was to defined to 32KB...?!)
it does indeed activate on a variety of systems, and maybe
(in the case of drivers that do not call sync() properly) even
is the cause of some of our ported driver breakage.
The new implementation is pretty much optimized for Haiku,
and shares almost no code or structure with the old one (save
for a few functions that really only have one proper implementation.)
Tested with ipro1000 and rtl81xx. Regressions are more than possible,
so please don't hesitate to file bugs if your network driver now
fails to come up (or you get KDLs.)
* Rename device.c to device_hooks.c, as this is what it really contains.
* Rename compat.c to device.c, as it implements the generic "device"
related functions, both for compat layer internals and FreeBSD
public ones.
* Move malloc and related operations out of the now-device.c,
and place them in a new "malloc.cpp", which also incorporates
compat_cpp.cpp.
No functional change intended.
in the Preferred Languages ListView.
Change-Id: I423263ba0c6753a278f70e479eb2b711ca1d7670
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1959
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
See bug #7428 and hrev46251 for details.
Fixes#15452
Change-Id: I3bc8871c83e714ff624827d96c0b594fef1f1ae1
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1957
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
We can convert a bitmap icon to B_RGBA32 and scale it at the same
time if we pass in the right size to IconUtils. Don't error out,
force the icon_size to be either B_LARGE_ICON or B_MINI_ICON,
grab the bitmap at that size then convert and scale it.
Implement a second fallback. If the scaling and converting fails
then use ImportBits to convert the icon from B_CMAP8 to B_RGBA32
then center it without scaling.
Fill with transparent before drawing bitmap to prevent artifacting.
Fixes#9554
Change-Id: I827589236fa4f1521e3139ec29b7d60d51d2f879
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1960
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
By setting B_NOT_MOVABLE and B_NOT_RESIZABLE flags the calendar window
can't be moved or resized by holding ctrl + alt + left/right mouse button.
Change-Id: If7f280ab6595b32a6c9521051540ffba0c76d211
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1965
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
This copies the behavior of BeOS R5 ScreenSaver prefs.
Don't invoke the listview on AllAttached() anymore, this would make
the selected screensaver start when the pref window opens.
Horizontally center the Test button.
Change-Id: I65471112d37d9efd17945f05bce485ff2fece9dd
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1958
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
The tab frame is drawn behind the tabs.
Create a new DrawTabFrame method in BControlLook and HaikuControlLook
that draws the tab frame background.
Until now we've been reusing the DrawInactiveTab method to draw the tab frame
in BTabView. While this works on HaikuControlLook, it doesn't work on other
ControlLook's (such as BeControlLook) that draw their tab frame differently.
Add FBC method to preserve binary compatibility on gcc2 and gcc4.
Move DrawTabFrame method to where _ReservedControlLook1 was in header.
Set rect to area of tab frame in TabView instead of doing the
calculation in HaikuControlLook so that others may benefit.
Change-Id: I513e238914f6d680f495659b6ec902df15555015
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1936
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
With B_NOT_V_RESIZABLE ctrl+alt+rmb can be used to resize the window
in undesired ways. Set window size limits to prevent user from resizing
the window beyond the set size limits.
Update window size limits on ScreenChanged()
Fixes#15067
Change-Id: Ia10eafb9860009019be35ec5c244d034861eeae9
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1968
Reviewed-by: Axel Dörfler <axeld@pinc-software.de>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Drawing the battery using BControlLook:DrawButtonBackground does not
work as expected with alternative ControlLook installed. Instead
draw the bevel and gradient without using BControlLook.
Renamed empty to unfilled. Replace single base color with unfilledColor
and fillColor.
unfilledColor appears to have change but it is the same #4c4c4c
(75, 75, 75) color just untinted. Specify the color using hex values.
Put all battery drawing inside the fHasBattery conditional block.
Copy rect to fill and use it to draw the filled area.
Use make_color() to make the unfilled color.
Change-Id: I615c4dc1b9e0206b4ac0259d3183fe691584209b
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1967
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Ironlake and SandyBridge use the same layout for the interrupt register.
Previous generations don't use PCH so the interrupt register is
different. Next generations shuffle the bits again to make space for a
3rd display pipe.
Thanks to D3ant for letting me test this on his computer!
* When the "interfaces" file contains a configuration for a missing
device, the first interface found would be overwritten, irregardless
of its status.
* Now, _ConfigureDevices() properly honours the
"devicesAlreadyConfigured" list.
* This fixes bug #14908.
This reverts commit e06f640862.
As mentionned in #15145, the cache directory itself must exist,
otherwise, various applications are broken. A slow install process is
better than a broken install, so, revert for now. A better solution
needs to be found.
This was not stored in BeOS, but that looks like an oversight on their
part and adding it is unlikely to break anything.
Change-Id: I5dbaeb85adf97afc5040a3ecc1bff264af0b0b57
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1888
Reviewed-by: Axel Dörfler <axeld@pinc-software.de>
Pointed out by LGTM.
Change-Id: Ia3d1093c8c21fd5bee05e47eb7694c6dd4ecf391
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1930
Reviewed-by: Axel Dörfler <axeld@pinc-software.de>
In Reader::Read(), memory is allocated to '*buffer' at line 40,
but freed with 'buffer' at line 45.
Pointed by Clang Static Analyzer.
Change-Id: I18e49791da639a6bc2041e944a39ceb73a2e5055
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1931
Reviewed-by: Axel Dörfler <axeld@pinc-software.de>
Change-Id: Icc1673b331d9afb3a7b34c91e7b1f20c3dee964a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1871
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Note there are 32bytes on disk for the checksum, but only the first 4
are used. This is because btrfs can (or could, at some point?) use
sha256 instead of crc32 when higher reliability is needed (but high
performance isn't).
Change-Id: I8a2bcf8f462440568d9b3e2d9fbdb7208723bfb9
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1596
Reviewed-by: Chế Vũ Gia Hy <ugen@cinnamon.is>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
* Improved the "Oh no!" text of the button.
Change-Id: I9b15f3dccca24a5e394d42890985fd42c49f7587
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1925
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Reviewed-by: Stephan Aßmus <superstippi@gmx.de>
Change-Id: I8a2bcf8f462440568d9b3e2d9fbdb7208723bfb9
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1596
Reviewed-by: Chế Vũ Gia Hy <ugen@cinnamon.is>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Change-Id: Iffea088f7234ab7d458ed0cabc4ded0aa50009c2
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1617
Reviewed-by: Chế Vũ Gia Hy <ugen@cinnamon.is>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Use the gcc builtin instead, which generates more efficient code (it
saves a function call) and means less platform specific code to write
for us.
Change-Id: I1d55b5703027b2ea4ecde2438ea306bd4850eb32
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1859
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
It just deadlocks, so let's try to go without it and hope for the best?
Should fix#14301
Change-Id: I3cbd6e800a64da31f1fb1f1fb66b088e0298596e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1899
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
To help understand the problem in #14276
Change-Id: I334a5cdfa149d335068f2135d13ed729b53fe6ab
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1900
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
As for other devices, N=1 makes no sense because N-2 is eventually
written to the hardware register, so wherever these values come from,
they can't be correct. Replace with the values from the Intel manual.
Also fix confusion as to when the + 2 or - 2 is applied to M1 and M2
values. The documentation says M1+2 and M2+2 are used in frequency
computations, but we instead write M1-2 and M2-2 to the registers, so
the M1 and M2 in our limit structs has an offset of 2 from the docs.
Should fix#13694.
Change-Id: I87157154d22a5e6caf622d71a2f0e0b9ff21a2fa
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1902
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This reinstates commit 2b5ebfcfd5.
According to the POSIX specification, a NULL iov_base means
"do nothing." So we should treat that as such properly,
and not consider it an invalid address.
Fixes#15356.
Change-Id: Ia9438777f1da8ca32f93e0d85229230c809e6711
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1918
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
The HAIKU_FIRMWARE_NAME_MAP macro takes a size parameter to define the
firmware map array type, and then a multi-dimensional array literal is
assigned to the array defined by that macro.
This is error-prone. The idualwifi7260 driver, before this patch, had
the size incorrectly set to 6 when the number of entries was 7, which
sliced the last entry off of the map, making it unavailable to the
driver. After fixing this size, the driver properly loads the
iwm-8265-22.ucode firmware on my computer.
This patch changes that macro to take a const char[][2] literal as its
only parameter, making it less likely for this sort of bug to be
re-introduced.
Fixes#15413.
Change-Id: I78a75e692a8637af0f13d1eb16180ce8d95d0852
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1917
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
