- Newer devices use a different layout for the backlight PWM registers
- Get the min brightness level from the BDB
Change-Id: I99745a022dd38733a4c2386f91c4c57016dd2acd
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5162
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
* Move the default size and position settings for ApplicationTypeWindow from its constructor to FileTypesWindow::fSettings, and update these settings when the window is closed.
* Add _Frame() for extracting a BRect from fSettings.
* Keep a BPoint parameter in the constructor, which allows each new instance of the window to be slightly offset from the last one.
* Submitted in response to a comment by humdinger on https://review.haiku-os.org/c/haiku/+/4926
Change-Id: I0fa8a9ca8f18cf4093363bff713f0f80f6c04cd5
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5164
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
* In the Application Type window, increase the weight of typeBox so the primary effect of resizing the window is to control height of the Supported types scrollView.
* Increase the height of scrollView so that it extends below the Remove button (presence of a button in a row seems to make row height static, preventing scrollView expansion).
* Modify ComplexLayouter in attempt to address root cause of the initial height of typeBox being too small to properly display the contents.
* Fixes#14936
Change-Id: I94ad8c5c8140814bfc2c399803f4d629ecd467bd
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4926
Reviewed-by: humdinger <humdingerb@gmail.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
After the previous commit's fix, it seems that modesetting is working fine,
at least on 0x1616 here. Backlight control however does not work.
Also remove two IDs that are dubious and were dropped from the Linux
driver as well.
Part of #17675.
The old implementation used the real lock_memory(). This is problematic
and does not work for a large number of reasons:
1) Various parts of the kernel assume memory is locked only very
temporarily, and will often wait on locked memory to become unlocked.
The transient nature of locks is further demonstrated by the fact that
lock_memory acquires references to structures, like the address space,
which are only released by unlock_memory
2) The VM has a hard assumption that all lock_memory calls will be
exactly balanced, and maintains internal "WiredRange" structures
on areas, etc. corresponding to the original lock_memory calls.
Maintaining separate data structures as this code did is a recipe
for even more problems when the structures are manipulated separately,
leading to confusing or incorrect behavior on unlocks.
3) Areas with locked memory cannot be deleted, nor can the pages which are
locked be removed from the areas/caches. This of course is most notable
when destroying teams which locked memory, but the problem also occurs
when just using delete_area, resize_area, mmap/munmap, etc.
Because of (2) and especially (3), adding support for mlock()-like semantics
to the existing memory locking system is just not a good option. A further
reason is that our lock_memory is much stricter than mlock(), which only
demands the pages in question must remain resident in RAM and cannot be
swapped out (or, it seems, otherwise written back to disk.)
Thus, this commit completely removes the old implementation (which
was seriously broken and did not actually automatically unlock memory
on team exit or area destruction at all, etc.) and instead adds a new
feature to VMAnonymousCache to block certain pages from being written out.
The syscall then just invokes this to do its work.
Fixes#17674. Related to #13651.
Change-Id: Id2745c51796bcf9a74ba5325fe686a95623cd521
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5147
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* Resize(): adds more space to the end of the bitmap.
* Shift(): moves all bits in the map up or down.
* Use size_t instead of int for indexes.
Also add unit tests for the new functions (they seem to be passing.)
Reference material for shift implementation:
2c56d43c1e/bitops.h (L977)
Change-Id: Ia85768aaeed7bd3ffef3a9f575f05331e048fe50
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5146
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Now only image relative relocations are produced. runtime_loader do not use symbol
resolution for itself and programs can't link with it. Also it is loaded in
special way and do not register in image list available for symbol resolution.
So there are no meaning in self importing.
Change-Id: Iff3cb0ee5ef1dd307134d52c3c911759c59a9b5c
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5153
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Reviewed-by: X512 <danger_mail@list.ru>
Reviewed-by: Fredrik Holmqvist <fredrik.holmqvist@gmail.com>
Some APIs will require the repository source
code to be sent in the future instead of the
repository code. This change prepares for
this.
Change-Id: Iccf0baca077ab81356ed81c18d14122a5b0dacec
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5137
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Internal display on my laptop isn't detected yet so modesetting doesn't
work, but at least I get vblank interrupts and backlight control.
Fixes#17569
Change-Id: I86dd56bc3fc2c288688242e34d9220028036ab74
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5156
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
The revision 1 structure should have 21 items, but on my laptop, it doesn't.
That's fine, we can parse it as if it was a revision 0 structure. This way I
can see the battery status on my machine.
Change-Id: I743173e05318d686049454983e378a08c0a1980a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5155
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Change-Id: I1f42447e537ea7522ac299f028d530beb5067350
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5142
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
see Devicetree Specification,
section 2.3.5 #address-cells and #size-cells
The #address-cells and #size-cells properties may be used in any
device node that has children in the devicetree hierarchy and
describes how child device nodes should be addressed.
The #address-cells and #size-cells properties are not inherited from
ancestors in the devicetree. They shall be explicitly defined.
If missing, a client program should assume a default value of 2
for #address-cells, and a value of 1 for #size-cells.
Change-Id: Iafed49358540f8ac7aa673c3dc0191c9b580250b
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5144
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
That's right kids, std::remove doesn't (and can't) actually remove
things from containers! Instead you have to pass its results into
container::erase in order to do anything at all.
Fixes#17579, and in my testing at least, the strange crashes
and heap corruptions.
Includes support for new I219 device families.
Taken from the 13.1 releng branch (currently on "beta 2" status.)
Tested in QEMU and VMware. The "e1000" device works OK in QEMU,
"e1000e" does not anymore, but reportedly the FreeBSD devs say
it does on bare metal, so this is probably a QEMU bug (it doesn't
seem to be a commonly used device.)
This reverts commit 8497a2cc28.
The VFS layer is not at all ready for this. Many places in the
code implicitly assume ino_t values will never change. This
functionality is only necessary for live shrinking of partitions,
which is a feature niche enough we do not need to worry about
implementing it in the first round of resizing (if ever.)
This is a bit excessive: a file with a B_MINI_ICON resource of the wrong
size should not result in crashing Tracker, the resource should simply
be ignored.
Fixes#17668.
Change-Id: I55a210eb829e568d254d8ab569720145c0ea5a09
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5115
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
