- User Since
- Dec 9 2017, 2:51 PM (174 w, 3 d)
Mon, Apr 5
Thu, Apr 1
Builds fine for me
oops, thought I did remove that include, but somehow didn't
Wed, Mar 31
Oops, with git now, we don't need $FreeBSD$ in the Makefile either
- Use backlight(9) subsystem
- Add SPDX tag
- Some formatting changes
Only include linker_set changes
- options EFIRT is not in MINIMAL, so now device smbios can't be either, so kldload smbios would be the way to go in MINIMAL
- address feedback
Oops, the sets were not fixed
Tue, Mar 30
Fri, Mar 19
Thu, Mar 18
+1 on the request from xdg-desktop-portal
Mon, Mar 15
oops, forgot efi.h change
Mar 14 2021
argh, left another debug print :D
Also add suspend-resume support (need to backup/restore private registers, also reinitialize).
Mar 13 2021
One interesting problem that I'm not sure how to properly solve: this device's description in ACPI (at least on Lynx/Wildcat) does have a _CID:
Mar 10 2021
Mar 9 2021
Added vbefb (not tested)
Mar 2 2021
Mar 1 2021
Feb 25 2021
Remove __BIT NetBSD-ism, add sc_ to all sc fields
Feb 20 2021
Feb 19 2021
Feb 16 2021
Feb 1 2021
Jan 29 2021
Jan 20 2021
Rebased, switched to MPIDR for cpuid finding
Jan 10 2021
The code of the binary itself doesn't require X stack, but the attempt to map stack as X somehow comes from libthr anyway for no good reason.
Anyway I just made these stacks non-executable too in my tree, so this is just notes for upstream about what things conflict with W^X.
Jan 9 2021
Hm, ctfmerge hangs in cond_wait_common → _thr_umtx_timedwait_uint → _umtx_op_err
(I think this didn't happen with the previous W^X variant enabled but I'm not 100% sure)
Jan 7 2021
Jan 6 2021
I wonder if there are machines that support any of the existing communication methods. eMAG would need acpi-i2c support…
Jan 4 2021
Added flag check (NT_FREEBSD_FCTL_WXNEEDED)
Jan 3 2021
Dec 30 2020
Dec 28 2020
- Rebase on top of landed eventfd :)
- Remove padding fields
Dec 25 2020
Dec 18 2020
Dec 12 2020
Notable side effect of setting kern.vt.fb.default_mode: switching from efifb to GPU fb does not increase resolution.
Fun effect with Radeon GPUs: a GOP mode with the wrong aspect ratio will be stretched, but GPU native framebuffer setting the same resolution via kern.vt.fb.default_mode will instead be pillarboxed :)
Dec 11 2020
Dec 10 2020
Dec 5 2020
oof. Hopefully this is good now, I haven't tested everything, but lots of things build fine without gtk2 now.
https://github.com/freebsd/freebsd/commit/36362eb0a0a1862a0898a6e17844a54f3f28f114 looks like extra code in the main driver itself was required for this hardware to work too, and we now have that
Way too many things have :gtk2 here, no gtk3 apps should need it
Nov 28 2020
Nov 21 2020
Nov 17 2020
I suspect this would be much more acceptable if rather than "never using linuxkpi" and introducing some duplication, it would be something like a clearer separation of linuxkpi into "bottom layer linuxkpi" (that doesn't force "writing a linux driver" but provides functionality necessary for e.g. drm) and "top layer linuxkpi" (the stuff that makes linux drivers almost just compile). It's already somewhat like that – it is possible to just pick some headers from linuxkpi and use their functions in a native driver, and it doesn't force you to write a linux driver.
Nov 11 2020
Nov 10 2020
Nov 9 2020
Now named with the __ convention and using libc_private (didn't know about it).
Nov 6 2020
Added specialfd. Okay, that doesn't look too bad. I haven't tested intentionally causing problems from userspace, but other syscalls seem to be doing the same thing as here with user structs, I guess everything that could go wrong is handled inside copyin?
Server-class arm64 machines also have SMBIOS data present. Maybe just condition the actual warning print to amd64 | i386 but try it everywhere?
Another thing. That syscall, would it have to be documented? Or would it be okay to pretend that we have the eventfd(2) "system call" when in reality it's a libc function calling into a private specialfd system call?