#uACPI - a portable and easy-to-integrate ACPI implementation
1 messages ยท Page 52 of 1
just added a return
You cant use aml on real hw if u have half of the api stubbed
i'll add the PCI driver then
I swear I need to add api smart checking and prefix every log message with [BAD KAPI] or something lol
(If it detects stubbed stuff)
have a -DUACPI_SANITY_CHECK_KAPI and require any bug reports to run with it enabled
Maybe you can just log when kernel API fails, and add a define to silence it?
Like not only if it's just stubbed
no
kernel api is allowed to fail lol
it's your fault for not implementing it
the kernel api is there literally so you implement it
that's why you make it a compile time option
yeah but it's stupid lol
The failures are usually because of OOM
exactly
A lot of kernels panic because of it anyway
which the kernel should be able to either on its own or know that it had happened
And if something returns NULL, it's usually because it's stubbed
So if you know that the kernel returns NULL when it's out of memory, you can silence it
And you can make it a debug/notice log level anyway
so a log message is harmless
making it a debug log makes sense
But I agree it's bad
i agree
Like the fault is on the kernel
i take messages a bit literally sometimes
and uACPI is a serious library and perhaps should be doing this stuff because some kernel doesn't follow the rules
out of 20 now?
You can have kernel api fail log level define or something, and make it a warning by default so it's obvious
And people could redefine it to debug/disable?
Idk
Its true that its super unlikely that any of the uacpi allocation APIs fail in a serious kernel because those usually have tons of mechanisms to stall a kernel allocation by all means possible to satisfy it
Like call into page reclaim, dump page cache, invoke oom killer, use emergency pool, compact existing memory etc
But its still not an error to oom and uacpi should handle it gracefully
i'm saying you could make it an explicit warning/log message
i still think it's dumb to make a dedicated "feature" for this
i would say it's okay if uacpi logged a debug message every time a kernel api failed
like, the first line of debugging something is enabling debug logging
and that will tell you which kernel api failed and why
Yeah, just too many places using kernel APIs and too annoying to maintain this
You could perhaps make kernel API defines use different error codes?
Like set msb bit
Then you just go over the codebase with a giant replace
Hmm, why is this helpful
U can do this right now, set the msb when returning errors from your api
so users can differentiate between uacpi and kernel api errors i guess
Sure it's not a valid enum but it is for you
The only difference is no error to string for uacpi
It doesn't really check other than to stringify it
that's the problem
Error string can say returned by kernel in parenthesis
i think the idea is that uacpi would treat it as a regular error without the msb
And u can easily hack enum to string to pop the top bit
but you can check that bit
That's possible yeah
that's pain
Though what if it's null
you'd need to either allocate the string then append based on the bit or duplicate all the cases
Anyway
Yep
These are solutions against dumb
but i still think it's dumb for uacpi to add more code to catch someone returning not implemented from a kernel api lol
Which shouldn't be needed in context of osdev
Yeah like
Either use barebones or implement everything
The other use cases aren't supported officially
tbh it just feels like having kapi checks and self test is a bit too much of hand holding
Do you have a uacpi test image btw?
there's a test runner
I mean something to test uacpi on a real hardware
Fuck I replied to myself
nah, it's just too much work
but ymmv
but it will be the ultra kernel 
Fuck it, I will turn uacpi-os to a test image
still waiting for the report threadโข๏ธ
and the fancy logger
i need to star the repo actually
same, im waiting for it to self materialize 
starred.
thanks
(while i waste time on minecraft)
is that your python-to-aml project?
i wish my kernel would just appear out of thin air like that too
yeah
I will just remove that part and turn it into a simple uacpi runner instead
it already has some basic threadig and stuff iirc
nice
@fiery turtle are uacpi_kernel_io_{read,write}* functions ever going to get called on !x86?
i think technically uncertain but almost certainly not
i'm doing some refactoring to my abstraction layers and the question is if i do conditional compilation inside of those functions or only include a definition when compiling for x86_64
why should users even see uacpi error codes
just do if !x86_64 return not implemented inside them
wha
wdym
would you rather have a boolean return value from functions that return status codes right now? lol
status codes have a great use case: they let you figure out what went wrong
you said users
why would users care about who issued the error
and why would users have access to uACPI anyways
isnt that a kernel thing
in that case, yes of course you should return your own error codes
and the kernel designer had better not confuse them with their own error codes
fine
and, while it's an arbitrary integer, you should probably return one of the uacpi status codes
technically not all arbitrary, the success value is set
off the topic but i was definitely thinking how i could integrate uacpi into boron and i was thinking. if i'm going to make it a dll i should probably allow drivers to link against each other
yes
nothing prevents it
u can return UACPI_STATUS_UNIMPLEMENTED
so that for example stornvme.sys would link against the kernel and also against uacpi.sys for bus enumeration (and power management probably)
e.g. on linux it would read from pci io ports
yeah id return unimplemented for non-x86 io port things and if it ever trips that then figure out for that arch
the problem is my abstraction layer rn ๐
i can't call asm wrapper functions outside of the arch/ module
maybe a skill issue on my end, but i really want to discourage using inline asm in generic code
you can always have per-arch impls in each arch/ module
and have the non-x86 ones return unimplemented for now
you can make it a separate dll, but its usually a very core component of any os especially for further device discovery and pci initialization etc so usually its not even a module
can def have a driver module on top of it though, ala windows acpi.sys
which idk if that does all acpi or just the device stuff
yeah but windows also has multiple smaller acpi drivers that are built into the kernel
yeah
for earlier code
hence the driver module on top of it part, the driver running on top of the core kernel's uacpi stuff
yeah thats possible
thats technically what i do except my drivers are just their own files that are part of the same compilation unit
my api can technically do separate modules for drivers except i dont support dynamic linking or loading rn lol
i have yet to think about how im gonna resolve cross module dependencies
just have everything being compiled together as a single unit like i do and like is the norm for zig its easy
ok, I have a "bare minimum" kernel that should be able to run uacpi properly
nice
now to enable random stuff so you can test more than just the init
Nice
I said revived not reviewed
i'm blind
what sort of random stuff, of curiosity?
So far the feedback is positive
idk, I guess power button and wakeup sources
bro does not care ๐ฅ
so I can also implement a sleep function or something alike
to test sleep and wakeup from sleep
Test on real hw 
tbh I should before saying that my code works :^)
lemme try on my laptop
oh wait first I need to add a framebuffer thing
i still need to add PCI lol
I am using 0xE9
at some point ill test my stuff on hardware lol
someday
im also using 0xE9 though lol
i'm working on threads now so i can run uACPI properly
Very few people know that u can detect 0xE9 prescence by checking that in(0xE9) == 0xE9
Just a random fact
yeah, its a cool thing
Lol
Yeah it works on both qemu and bochs
once you initialize acpi, the kernel won't have ps2 emulation
problems for later ig
Would be nice if you added repl to run random uacpi functions
i kinda want to get an x86 SBC with a hardware serial port just to test osdev things on tbh
Like eval methods, dump the namespace
that is exactly my idea
I want to have a c like repl
Damn
and have all the uacpi functions as symbols
Nice
technically most desktop computers have hw serial
i just don't know if the OS can use it
well yeah true ig
for example, my motherboard exposes the pins for it
but either way i want an SBC that i can use normal basic serial to get info out of to then do osdev with
should
for each module
if module contains function then
thats the module
I see myself designing it like this at least
Kernel modules are compiled with the option that prevents the linker from throwing errors if functions are undefined
So I don't need to link one kernel driver to have it import another's functions
Which means that kernel drivers will be able to have circular dependencies and it would be allowed
The only thing that won't, is the kernel
I wonder if it could be used on loongarch...
My kernel kinda maybe had S3 sleep working with uACPI on physical hardware 
uACPI has managed to shut it down (S5) after recieving power button event in QEMU
So I guess
mine doesn't even recognise S5 is even an option (i hope it's bc of the PCI api)
real
It has iocsr, which is kinda like io on x86?
this only on my laptop tho
Like what if ACPI wants to access it, what does it do?
__declspec(dllimport) for real dlls.
From GED
i do not use msvc
i was talking about dlls as a concept rather than dlls as strictly PE format dynamic library objects
And kinda not even kernel
๐
I meant mechanism behind it. It's not compiler specific. I'm not pushing anything. I am just also thinking on integrating many things and shared my thoughts on the close subject. I'd make it a driver, boot time one, some kind of root enumerator. I'm actually close to start with it.
the way gcc works is you have to explicitly link against a shared object in order for the linker to say "fine, we will leave this as an import"
so like, -lboron if you want to link against libboron.so
this works fine for user space but i kinda do not want the kernel to be a "shared object" (because idk if limine supports loading those and im not taking chances)
(although i could just create a libboronkernel.so which is literally just the kernel objects in library form and then link against that and serve it relocations from the boron kernel proper actually)
(because the modules only remember the names of imported functions and nothing else)
just have a prekernel 
no
i wanted that for a while but just decided not to bother
You know what "slop" really is? that pathetic overhyped rust the only outcome of using which is dividing by 20 the number in a phallometric contest.
lmao
okay "phallometric contest" is funny
yes, elf can't provide real dlls, so if you stick with it, you can't use this useful mechanism for driver intercomuniction. however clang can make PEs. For x86 and arm. And since they added mips pe support as I heard, maybe dllimport is available for it as well. And maybe even for loongarch too, since it's a mips clone. Fortunately, having picked what I really need for the wanted design, I don't have such issues. My issue is the extremely poor ACPI support for arm targets. So I need some kind of dtb engine equivalent to the acpi enumerator for machine topogy discovery. And that fdt is so fkn sucky, so demotivating.
dtbs are easy
elf shared objects are a type of DLL and there is no "real DLL". DLL, shared object or dynamic library are names for the same concept
PE DLLs have one feature that ELF shared objects don't have though which is that function imports are tied to a DLL within an application/DLL
while ELF just has a list of SOs that need to be loaded
Because they don't do anything. Without "bindings" they are just nothing. And those bindings in fact mean "just write a specific driver everytime for eachndevice". Still you won't have such nice things as s states transitions anything that aml does. Dtb are crap.
That very feature, you'd benefit from for what you wete talking about and to what I commented. Easily provide "helper" functions from a driver to other drivers. The NT way.
Yet you don't get an equivalent for "everything else" dtbs are incapable of on dtb supplied machines. You just get this garbage dtb full of linuxisms and nothing working even in the stock linux. try to get an arm sbc with suspend to ram or hibernation. On freaking "power saving arm" platforms. You can fry eggs with them and linux. This is how it works without having acpi they are so arrogant towards. With the fdt pulled off cluelessly from openfirmware without much thinking.
that's why x86 is the only real platform
Because red hat are lamers?
They introduced this fdt to use instead of acpi.
i was experimenting with the automatic creation of a symbols file & a pseudo kernel library (linked against by kernel modules, but the kernel dynamic linker knows it's really a placeholder for the kernel) to this end
the alternative is to use that linker option that ignores undefined symbols
but i don't like that one
the power button works on my laptop without needing an EC driver 
and its a really new laptop, so its quite surprising
there are some aml errors, not sure if its related to the ec or not, but I am gonna write an ec driver regardless
Nice
Can you show them
can't relate, my kernel doesn't even run on my laptop :/
Probably they just didn't cheap out on circuitry to route it properly
So some of them are object already exists that also happen on Linux
But one of them is the bat0 complaining about undefined in op
ah ive seen this already
Now I checked the aml (I can send you later) but it does actually properly check for _REG in EC being called
this is basically untested code brecause no ec driver
so it hits a path with undefined local
yeah but u run _REG before initialize usually
this is why it works fine
anyway yeah send the dump
but i think one of mishakov's laptop is like this
Is there a chance you run _REG by accident with default handler?
I'll check it again later then, I looked at it quickly and I didn't see it make a mistake, but I haven't looked too deep
u say it checks for ECAV
Yeah
this is what ive seen on mishakovs laptop as well
but in the else
it forgets to initialize a local
And it sets it in _REG
so its undefined
Could be then
and then it uses it
its a common untested thing they have in BAT0._STA
linux doesnt call BAT0._STA because it knows it has no _INI since ACPICA does subtree prescan to speed up namespace_initialize()
basically its a cosmetic issue
yeah
I see
It is really weird to me that there is no ECDT tho
Like, when am I expected to install my own drivers?
i mean not all laptops need early EC
Yeah but the _STA needs it technically
after initialize() iirc
_STA would be called way later
Ok so I am doing it in the right place
Wait so why do you call it?
during namespace_initialize it expects all _INI to be called
_INI can only be called if _STA returns 0xF
and u cant go into child namespaces if _STA failed
so u kinda have to
or u can pre-scan to know what subtrees u can skip
but i just dont do it because its fast anyway
I see
Is that what windows does as well?
Like, running untested acpi code paths is a bit scary 
u mean would windows call _STA there?
Yeah
And it's not like it's a missing ec driver, it doesn't provide ECDT, so it would happen on windows as well
it would probably have an EC driver at that point, but I doubt it has any sort of advanced tree pre-scan
windows just doesnt do any advanced things with aml
would be interesting to check I guess
But it won't since the firmware doesn't provide ECDT you can't install the EC driver before initialize
technically
the namespace is already loaded at that point
so u can find the EC device
Yeah you could install the driver
no one knows what order the windows driver does it
well thats not what linux does at least i think
id have to re-check the code
but i should experiment to see what widnows does in this case
Btw for the love of god can you add to the osdev docs the set interrupt controller function? I forgot it's name and had to search all the header files for it 
And given it's a pretty important part of the acpi init it could be helpful
its in utilities.h
Also I feel like the namespace iterations are missing a few docs, like I couldn't figure out of find_node gives you an existing reference or if you need to unref it (from the code it seems like an existing reference)
But if it gives an existing reference can't it be a bit dangerous?
I see
but yeah a comment would be nice
Right now the problem I had is that the second ec resource had a type of zero, so I might have a bug somewhere in there
it explicitly denies access to namespace nodes that are temporary
Yeah I saw that
aka only exist if theres currently aml being executed
All the temporary node stuff
isnt that just the resource terminator?
I am using the get_current_resources, which returns length + entries
I check the length >= 2, the first resource is IO as expected, the second has a type of zero, which idr what it is
wait
Yeah, and I looked at the aml and it doesn't have that, so probably did something funny in my code
Nah, I would probably do the same
Might be worth a comment, but if I looked more than two seconds at the struct it would also tell me what I did wrong :^)
You just saved me from adding heap guards and expecting a bug with the allocator
lol
to be fair that macro is also 1 line above the struct
btw it might be easier to just uacpi_for_each_device_resource
that does free on its own
u dont even have to keep a pointer
uacpi_for_each_device_resource(dev, "_CRS", lambda, ctx)
there's also uacpi_for_each_resource for an already existing resource buffer
Yeah uacpi had a lot of helpers, really nice to use it
Even better when using it correctly
:^)
thx
why are circular dependencies useful?
because consider a strongly connected component in the dependency graph. if any of the modules in it are loaded, all of the modules in it have to be loaded. therefore, we might as well consider the strongly connected component a single module.
So that I don't have to link uacpi into my HAL
(Although it's possible (but slim chances) that there is no need for UACPI to use the HAL or the HAL to use UACPI)
Also why would I not want to link uACPI with the HAL? LARPing purposes
yeah so this won't happen
because the kernel depends on the HAL
yes
the HAL needs ACPI tables for initialization (MADT, etc)
and ACPI needs the kernel for memory allocations, IRQ handling, etc.
if I really didn't want to have circular dependencies then I could ship my own implementation of ACPI tables for the HAL
in fact, I already do that
but this is a very good point. if uacpi and hal depend on each other what's the point of them being separated?
two uACPIs in one kernel? ๐คฏ
lol
thats fun
https://review.haiku-os.org/c/haiku/+/8937 haiku pr is finally doing something
but nah
we'll see what happens
so a couple options
- build in uACPI with my HAL (no separating the two)
- the HAL and uACPI are circularly dependent (de facto no separating the two and only for larp purposes)
- the HAL comes with its own ACPI table parser and uACPI doesn't directly depend on the HAL (the two can be separated but there is code redundancy and my ACPI table parser is probably inferior)
What is LARP
Yeah I'm not sure, what's the advantage of decoupling uacpi from Hal on x86?
being able to boot without ACPI support
Live action role play
Pretending to be something you're not, in this case
Yeah but why would you want this
Does windows have a mode like this
Just in case
I think so
Is it not possible to make it skip acpi init behind a flag for exceptional cases like that?
I know you can disable the ACPI shutdown and have it show the "It's now safe to turn off your computer" screen in the latest Windows 11 but I'm not sure that disables the entirety of ACPI
Yes you can
Or you can just omit uacpi.sys from loading
Probably not, because it need acpi for device discovery and PCI brdige allocation and discovery as well
Like that would probably disable all of PCI and i2c as well
Potentially USB
Why would it disable all of PCI? You can scan PCI devices the brute force way
By scanning every bus, slot, and function
You can ofc lol, but I doubt windows has a brute force scan fallback
Its not safe either
Probing bogus busses might hang some controllers
In this case it also has to trust bios for bar window allocation
Which is probably fine but yeah idk
It has to trust the firmware for a lot of things anyway
Yeah basically it cant check any resource collisions
what would be better, micropython + ipython shell, or a C like repl shell
both would have full access to uacpi functions and what not
Python is probably way more powerful
it would require some ffi glue but yeah
does micropython have enough stuff to run ipython?
also micropython is quite annoying
no idea
"Kuroko's Basketball is a Japanese sports manga series written and illustrated by Tadatoshi Fujimaki"
its something someone on the server made?
is there a way to tell limine to use the highest resolution available? it annoys me that it doesn't use full screen on my laptop
it probably tries by default
its likely that your laptop doesnt provide an edid via uefi
so limine just picks whatever is safe
although laptops usually do provide it so idk
in the limine screen it is full, in the os screen it is not
or is this a flanterm thing
limine probably doesnt do modesetting
and default gop is native res usually
but idk ask mint
ever since the discord was killed its a bit harder to ask limine questions
updated score on i5 12400f
you can just ping me
tbh
tru
and no Limine itself doesn't do modesetting, it uses GOP or VBE
tbf I rarely need limine help because it just works 
if you mean that Flanterm just uses a smaller rectangle in the middle of the screen, that is limited due to using the Flanterm internal bump allocator
if you use a proper allocator you can get full screen
np
@fiery turtle yeah its the exact same thing with the local not being initialized
can i use the bump alloc at the start, and after i init my vma switch to that?
you will need to destroy the context and create a new one
any stubbed api functions?
there is fb_reinit i saw
makes sense
thread id is 1*
and schedule stuff is unimplemented
yeah, what itay said
you have to create a new context
@fiery turtle will anything break if I noop in spinlock/mutex acquire/release until the scheduler is initialised?
I assume it would not
should be fine
further resource type support pushed to zuacpi
as well as actually accepting the existence of alignment in resources
nice!
it now has enough resource types to handle everything that q35's acpi tables gives me
I love this project
(plus an nvme controller on top)
I spent the entire day rewriting the threading and sync code because I thought I had a bug in it, only to release I got the order of the data and command port wrong in the CRS 
skill issue
I still have a bug in the scheduler tho, waking a thread from interrupt doesn't wakeup the core to actually run the thread I woke up 
Lol
At least they're better now I hope
they are simpler
Use mwait 
before I had a futex like primitive, and I switched it to just having a semaphore+cond as the primitives instead
smh
I actually removed a bunch of random from the kernel I based off since I want this to run on older hardware as well lol
I still depend on constant tsc, since that is the simplest time keeping, but I am not using tsc deadline for example
I use the lapic
nice
reminds me i need a futex primitive
is your think open source? curious to take a look at scheduler code
yeah, its uacpi-os
I will need to implement the workqueue stuff eventually, I am starting to get TODO prints for wait_for_completion 
also reminds me I haven't implemented timers at all yet, so there are no timeouts
i wonder where thats called from for u
I added a lid driver
so I register a notify
I think once I added that it started calling it
ah yeah
would it be more correct to clear the gpe inside of the gpe handler, or inside of the worker thread that handles it 
wait I guess I need to clear it at the handler, in case it wasn't for SCI_EVT
depends on the gpe
take a look when managarm clears it idr
or haiku is probably a better EC driver
what's fixed event 3?
see the enum in event.h
yeah i get an error that that failed to enable when booting from my laptop and it makes sense
thanks
u get a sleep button event?
sleep button is routed via notify probably
I think uacpi has some method to check if a specific fixed event is present in hardware
its a bit in fadt
ok I finally got to getting the query value from the EC
I now need to call QXX or something right
_QXX
there are a ton of debug prints in this aml ngl
I think most of it is from a template being replicated for each root port tho
fair
ok time to implement the work queue thing
what's _OSC?
thx
did a bios update on my laptop and unfortunately there are no acpi table changes
or well, two tpm-related addresses changed, but no logic changes unlike the previous bios update
because its already flawless clearly 
yeah
```
[ 1.046741] ACPI Error: AE_NOT_FOUND, While resolving a named reference package element - _PR_.P000 (20240827/dspkginit-438)
[ 1.046762] ACPI: _TZ_.THRM: _PSL evaluation failure
[ 1.046792] ACPI: thermal: [Firmware Bug]: Invalid critical threshold (-274000)
oh well
i assume the philosophy is the classic "if it boots windows it's good enough"
windows also doesnt resolve named references in the interpreter
so maybe it works in the windows workflow somehow
niice
wait, how did you detect the lid change?
Also bonus thing, clicking the power button prints a process list
Apci has a lid device
oh cool
It triggers a notification on a change and you can query it
fucking magnets, how do they work
thx
how do u shutdown then lol
especially with how they also mixed in the EC to it
its just a bunch of cancer to deal with correctly
I have no idea how my keyboard is connected on this laptop tho
the touchpad is i2c
from what I seen
ps/2 kbd and i2c touchpad seems like a common arrangement
oh also I didn't actually implement the ec address space operations lol, since they were not needed yet
keyboard is prob ps2
that's how it is on my laptop
same
yeah its ps2 on my laptop as well
its so freaking cancer
how am I supposed to know when stuff is keyboard and when stuff is ec
at least on your laptop the power button doesn't require an amd gpio driver :^)
the fuck is this
virutal
XDD
wtf is an intel usbgpio lol
drivers/usb/misc/usb-ljca.c
it looks like it's an internal usb device that has an i2c, spi and gpio controller?
good shit
i hope i can some day get the same crack that hw engineers get
dafuq
why
whats wrong with the pch
the lpc exists for a reason
anyways I guess to actually continue and add a proper shell I will need an actual ps2 driver
sad lif
make a uPS2 while you're at it 
Tbh it is kinda tempting to do so
Tho is uAPI a thing now
Did you ever continue working on it
basically
At least lto is a thing
attribute alias as well
The main annoyance with PS2 is the fact that there is a lot of weird synchronization between the keyboard and mouse
And I think the data port is shared between the EC and PS2
Command port is different tho
huh
how would they synchronize it
Like, verify me if I'm wrong, but from what I seen 0x64 is the data and 0x66 is the command for the EC on my PC, and PS2 is 0x64 data and 0x60 command iirc
i mean yeah i think so
i just dont understand how that works
without race conditions
Maybe if you are fully interrupt driven it won't fire multiple interrupts (?)
Or well, how does it know when you are done
It seems like Linux has multiple layers of abstractions
So you have the keyboard/mouse on top of libps2 which is on top of serio
ofc it would have 10 layers for ps2 lol
its linux afterall
@vast kestrel should we put this kernel in the uacpi org after its done?
Sure
maybe I could add some CI runs at least in QEMU on every commit
I mean define done :^)
whenever u feel like its what u envision
Yeah having some automated tests could be cool
like i have tons of tests but none of them test kernel mode
I want this to be enough to take a random computer and ensure that uacpi works on it with a known good kernel
that would be cool yeah
So if someone comes with some hardware error they can run it first and know if it's expected or not with uacpi
It's also why I want to keep the kernel pretty simple
Or well, as simple as something that can run acpi can be
Btw it seems that the acpi EC in Linux doesn't use any of these stuff, it just works directly against the controller
(the libps2/serio that is)
Maybe it's up to the controller to ensure it doesn't mix stuff, even tho it would be funny if as long as the EC is doing stuff keyboard doesn't work lol
yeah its probably synchronized at chipset level
i like that u use uacpi_snprintf in your kernel
i was gonna do that as well lmao
if rip in range(windows_ps2_driver_start, windows_ps2_driver_size): dont_do_ec_stuff()
I think both ps2 and ec have a bit that says if there's anything in the data port
So that's how they synchronize probably
Although I wonder if that means the keyboard hangs if ec is not handled
And its most likely also routed via i2c so you don't even have to use ps2
So maybe they assume if you have an ec driver u also have i2c
But the keyboard stays as PS2 no?
Idk if you noticed but all of the error handling is based on uacpi_status lol
Nice
No idea
But yeah the kernel is shaping up great so far
Yeah I like how it's built, it's relatively clean
I need to cleanup the scheduler a little, since right now everything stays on the first core
I think implementing most of the standard acpi devices could be nice
As a reference
For a second I read it as AMD GPU 
Mishakov did it for his kernel
Nice
Its not that big of a driver
90% of GPIO drivers is a bit mask of config and data :^)
Yah
Intel chipsets have a ton of stuff to route GPIO as gpes and smis and scis
Ye
Having the kernel be multi-arch would be interesting
Definitely
Hardware reduced acpi support :^)
Well, I am not adding support for other arches so PRs are welcomed 
Lol
More like lack of support for other features
There is some random, like gpe devices or whatever it was
Tho no idea if any hardware actually uses it
The ged yeah, but its 100 lines
Once you have all these helpers the drivers just fall into place
I just remembered I wanted to suggest some uacpi helper function but I completely forgot what it was
Lol
That's wrong, I use it but I don't restore the state (so it's just a shutdown) lol
How do you support i2c?
I think it didn't get merged to QEMU
uUSB when
Smbus drivers
Ok I think I realized something, because the command registers are different, it can know if what you are about to write is for keyboard or EC
probably
And assuming that the EC is not buggy, indeed the OBF can be set for either
So in the write case if you start a kbd/EC command it will wait for that one
And I guess it's the same for IBF
Wait no that's different
Even tho
I wonder if you write to the EC if the kbd will have IBF set as well
that would most definitely break lol
Also what if you write to one reg and then another
Because Linux doesn't lock it between them as we saw
It can work if that sets the IBF on the second command reg
the order in which the "data full" bit wil be set should be synchronzed
And it stays full until you are done with the other thing
I wonder if there is any open source EC firmware
i remember reading an implementation
someone posted a link
dont remember where
maybe in this thread
I'll search when I get home
yeah that works
lets see
I sure do like it when the firmware asks a question
ok actually all the 3 cases are funny
ok so this is the keyboard handler https://github.com/system76/ec/blob/86dbc9ba3a6d0a77a54208037c99990188a3f660/src/board/system76/common/kbc.c#L453
it seems to run once every 1ms
which sounds a bit high ngl
the output will check if the state allows it to send back keyboard/touchpad/mouse data
so while you are doing a command it will not send keyboard data
but outside of a command it will
Is there a KBC STATE EC?
Maybe its not even shared on the framework
I have one dump
gib
Scroll up
actually lemme find the EC stuff
WTF
linux would use the first two probably
the rest are just for bookkeeping
is 62/66 shared with kbd?
ps/2 uses 0x60 and 0x64
nope those are not shared
maybe I was dreaming
hold on
yeah skill issue on my side 
its 0x62 as well
I remembered 0x60
ok so there is actually no problem
nice
does it actually use the GPIO instead of SCI on the system76 laptop?
if it's an amd laptop that's not unlikely
me and @calm latch have laptops that wire the power button through the amd gpio gunk
ok so there is no problem with ps2 and ec, just me being completely blind
so time to add a ps2 driver for fun and profit
one thing I do wonder is how the ec handles the mouse stuff
wdym? if the touchpad is i2c it doesn't go through the ec
wait fuck yeah it won't do the dual port mouse in there
you need an i2c controller driver and it just uses hid over i2c
I was hoping to see how the controller handles it when ps2 has two devices 
- usually a gpio for irqs
it seems on my laptop the i2c controllers are discoverable over pci/pcie
anyways I don't need mouse for this, keyboard is enough
afaicu you still need to associate it with the aml node for it, since the aml for the touchpad refers to the controller that way
yeah it has a node in the AML
but that is standard PCI stuff
@fiery turtle is there some helper to lookup a pci node under a pci controller device?
ps2 emulation is turned off when you enable acpi
my i2c touchpad didnt have ps2 emulation even before i added acpi to my kernel
@fiery turtle do I need to call the _STA myself to ensure that I can deal with the device?
or well, that it exists
what context
for example in the acpi driver dispatcher
so because I am using uacpi_namespace_for_each_child I need to call _STA myself
got it
in the main dispatcher u can just use uacpi_namespace_node_info
or actually, that doesnt have sta but yeah
sta u check yourself
uacpi_eval_sta
ok cool
should I first check _STA and then HID/CID or the opposite 
I feel like first check _STA
_STA first, then namespace_node_info
which collects everything there is about a device
then u can just give that struct to probe for example
including uid, hid and cid
uacpi_get_namespace_node_info
oh I just now noticed that the node info has the cid and hid
I called the others manually until now lol
yeah u dont have to
theres also eval_{hid,cid} if u really want to do it manually
yeah that is what I did
bruh
u could also just unconditionally eval it and check against UACPI_STATUS_NOT_FOUND
meh
it cant collide with aml errors because aml errors have a separate enum value
I already use the info so why not
yea
how can i get battery info from uacpi?
there is acpi smart battery
heyyy ps2 works
ngl
its really clean to have ACPI as a device bus
you just see devices and initialize them
nice
ultra progress this week: I made an atomic.h header

uacpios progress: full scheduler, work queues, every acpi driver in existance, allocators

Tbf it helps to not care too much about performance or scalability
The sync primitives I made are based on go, so it's not too bad
bro flanterm looks so good
how did you lose your introduced role?
i'm built different
what does that entail
lets see what uacpi does exactly
yeah it just writes an smi and waits for the mode to change
it just pokes fadt registers
is that two webcams?
no
light sensor
ah
makes sense
[UACPI_REGISTER_SMI_CMD] = {
.kind = REGISTER_KIND_IO,
.access_kind = REGISTER_ACCESS_KIND_NORMAL,
.access_width = 1,
.accessors = { &g_uacpi_rt_ctx.fadt.smi_cmd, },
},```
it waits for the SCI_EN to be set
so either your io kernel api is broken or fadt is garbage
i'm guessing the first one
bro WHATWEASJITYGSEROJHSRDOIJFUK
lmao
remove-talc
arch
idfk what this function does man
but the base yes
i keep forgetting
which one
io_map takes the base, and io_read reads from the mapped relative to the mapped
the io_map functions
so if it maps 0x100, then read will read 0 to read the 0x100 port
it's base+offset for io_read
for x86_64 basically nothing
or will read 1 to read 0x101
like ts so simple man
oh yea i forgor to do this
smh
#[unsafe(no_mangle)]
extern "C" fn uacpi_kernel_io_read8(
arg1: uacpi_handle,
offset: uacpi_size,
out_value: *mut uacpi_u8,
) -> uacpi_status {
unsafe {
(*out_value) = asm::read8((arg1 as usize + offset) as u16);
}
return UACPI_STATUS_OK;
}```
how did u implement it correctly
and then say
idk how it works...
also io_map/unmap should be arch specific too in that case
that is io_read
ah
and he never initializes it
he uses the handle as if it was the base
just like many kernels do
if u wanna be cool then ```rs
#[unsafe(no_mangle)]
extern "C" fn uacpi_kernel_io_map(
base: uacpi_io_addr,
len: uacpi_size,
out_handle: *mut uacpi_handle,
) -> uacpi_status {
let io_window = Box::new((base, len));
unsafe {
out_handle.write(Box::into_raw(io_window));
}
return UACPI_STATUS_OK;
}
and then u can do bounds checking in io_read{8,16,32}
or you can just out_handle.write(base as uacpi_handle);
if i had a penny for every aml blob

epic
so basically previously u would write to random io registers
causing ur hw to do absolutely random shit
lol
wow on the fw13 there are 0 acpi warnings or errors
I think my battery is low :^)
It started spamming these notifications
Also when connecting to power it gave a response to the query that aml doesn't have a handler for 
Lol
How often
yeah yeah
That's strange tho
So u don't get a notify when plugging in?
lemme quickly fix so it won't throw on it but warn instead
and see what it tried to call
Q37 and Q38
they were called
but they reference something that doesn't exist?
actually it doesn't have the same error as what I had before
oh wait
maybe because I threw in from this it caused the entire thread to abort
idk
anyways it seems to be working, and the PNOT not exists is true, its not defined anywhere
but its after the entire handler
or well, in Q38 its in the middle
I should add the smart battery device
but no first keyboard and shell
is PNOT a thing?
nope
maybe SSDTs
aml names are upper case so yes
yep




