Or that lmao
#uDRM - a portable Direct Rendering Manager
maiden birch
maiden birch
Get and set is enough
hexed flare
Also make it void 
tawdry trench
make what void
hexed flare
set
tawdry trench
why
maiden birch
That might do an allocation
If u have one priv field and u need it
Id keep just in case
tawdry trench
that's up to the kernel anyways
hexed flare
if (srand() % 1000 == 0) uapi_pci_set_context(NULL, NULL); to keep the kernels in shape 
maiden birch
Bruh
tawdry trench
mfw
maiden birch
We're not feeling well today
hexed flare
What if you're running it in userspace 
tawdry trench
user mode kernel
tawdry trench
tawdry trench
tawdry trench
okay hows this
maiden birch
Maybe something like
Attach an opaque private context 'ctx' to a pci device handle, which can be retrieved later via the getter
tawdry trench
done
maiden birch
Nice
main crow
did you consider creating type aliases for uapi_handle
so that there's uapi_pci_handle or uapi_spinlock_handle or whatever
(and its still typedef'ed to void*)
maiden birch
yeah that would be good i guess
tawdry trench
did you consider creating type aliases for uapi_handle
shit true
that makes more sense
will add
why is uapi_pci_address part of types.h and not pci.h
maiden birch
no because kernel api headers should not include other kernel api headers
but other pci related headers would probably operate on a handle
so whatever
tawdry trench
then have a pci_types.h 
tawdry trench
lol
maiden birch
Ah yes
waxen orbit
what in tarnation
tawdry trench
~/repos/menix-os/menix/modules/drv/gpu/drm/udrm/include/udrm/uapi
main crow
idk if i already mentioned this
why are you passing the pci_address as a pointer?
tawdry trench
this is infys making
pci_address is a struct with bus, slot and whatnot
though that could be encoded in a long
maiden birch
why are you passing the pci_address as a pointer?
Because it has a lot of fields and won't fit
Into regs
I think
tawdry trench
it has 2 u16 and 2 u8
maiden birch
U can change it to pass by value if u want
agile halo
yeah it fits within one reg
agile halo
;asm -O1 ```c
#include <stdint.h>
typedef struct {
uint16_t seg, bus;
uint8_t dev, func;
} pci_addr;
uint8_t addr_dev(pci_addr addr) {
return addr.dev;
}
ruby berryBOT
tawdry trench
it's over
maiden birch
Wait wtf
tawdry trench
funny
;asm -O1 ```c
#include <stdint.h>
typedef struct {
uint16_t seg, bus;
uint8_t dev, func;
} attribute((packed)) pci_addr;
uint8_t addr_dev(pci_addr addr) {
return addr.dev;
}
interesting
maiden birch
Til
tawdry trench
last month i learned my boss made the SysV ABI
maiden birch
Lol
maiden birch
Who's your boss
maiden birch
Nice
waxen orbit
that's pretty cool
maiden birch
are we doing a pass by value then?
tawdry trench
why exactly don't we pass the address individually?
you can have 6 register args, that's more than enough
maiden birch
how is that better than having them in a struct?
tawdry trench
idk, one type less
maiden birch
well idk
timid shore
oh neat didn't know sysv would enregister things like that
(pardon my calling it enregistration if that isn't the term, it's what they call things in the dotnet vectorization/optimization sphere where I first learned the term)
jade pecan
I use it for my syscall return stuff, its neat
tawdry trench
I use it for my syscall return stuff, its neat
same
ultra based
smh astral is just menix if the process management and scheduler were actually good
jade pecan
smh astral is just menix if the process management and scheduler were actually g...
My scheduler is shit!! I will rewrite it soon enough
jade pecan
Sounds like a vmm issue rather than scheduler
tawdry trench
that's why i said proc management π’
it's absolute garbage rn
i'm amazed it even loads busybox
main crow
Because it has a lot of fields and won't fit
yeah so it will get ABI'ed into a pointer anyway
or alternatively it will be in regs and it will be faster anyway
so
lol
median yoke
technically, you were right
tawdry trench
you were write
elder forum
Will this project eventually allow for accelerated graphics on new OSes if things go well?
tawdry trench
that's the goal
young copper
astral gate
How is uDRM planning to do things like memory management? For example, I know that Linux has internal memory management features that can be used by for example GPUMM instead of having to roll its own everything.
tawdry trench
can you explain further?
astral gate
It's just something that I'm curious about (nowhere near wanting to do anything drm at the moment :(). For example allocation and management of device memory.
tawdry trench
well, if you mean how stuff is mapped, there is a kernel API which must be implemented
astral gate
yeah... but that's not entirely what I meant
So GPUs (except integrated ones) normally have their own dedicated device memory ('physical' GPU memory). Allocating and freeing pages of that is something which the kernel's MM subsystem might already be able to do.
Duplicating such code in uDRM is undesirable. But also hard to avoid, as it is pain for kernels that do not have such capabilities.
tawdry trench
uDRM would handle foreign GPU memory itself
this obviously means you have to use the built-in DRM component
since uDRM can be used with a custom backend
astral gate
So GPUs (except integrated ones) normally have their own dedicated device memory...
Well this is actually misguided because of earlier messages,
since GPUMM is actually about managing the virtual address space that the GPU sees. Regardless, similar questions are relevant.
Although I should probably actually look at the architecture of uDRM before asking such questions.
young copper
waiting for udrm day 15141412312141141414010940124809124
tawdry trench
real
maiden birch
are u working on it atm?
maiden birch
yeah
tired steppe
Can you pin the first message with the link to github
young copper
.
young copper
π¦
frozen matrix
when are we getting Nintendo GameCube/Wii "GX" drivers in uDRM
tawdry trench
frozen matrix
but in all seriousness that'd actually be super awesome
it's not that bad of a GPU
the only half bad thing is that on the Wii, in order to actually display a picutre, you need to yell at an encoder chip sitting on i2c
tawdry trench
it's more of a question of documentation
frozen matrix
who needs documentation when you have code
https://github.com/devkitPro/libogc/blob/master/gc/ogc/gx.h
https://github.com/devkitPro/libogc/blob/master/libogc/gx.c
young copper
I think it would be better if udrm had good functions and optimizations with linear framebuffer
like a swiss knife
astral gate
I think it would be better if udrm had good functions and optimizations with lin...
make your own swiss knife.
(assuming you refer to things like 'draw a line from point A to point B' or 'draw this string of text at these coordinates')
IMO an important detail with this type of library is that their scope is kept relatively small. As an example, uDRM should export interfaces for managing display outputs, GPU memory, and sending commands to the GPU (this is basically what DRM is). Operations such as blitting an image to the screen can be implemented on top of uDRM.
inner crater
given that the kernel itself isn't necessarily expected to issue commands by itself, the need for utility funcs providing that is kinda limited
like I'd expect mesa to build them up and the kernel+uDRM just be a handler passing the command buffers on to the GPU (after some validation etc)
tawdry trench
like I'd expect mesa to build them up and the kernel+uDRM just be a handler pass...
that's the idea
tawdry trench
where kernel
young copper
where kernel
what kernel
young copper
how are you going to test without your kernel
a
i can test it in my kernel when u say to me
astral gate
udrm-linux when?
tawdry trench
hexed flare
when are we getting Nintendo GameCube/Wii "GX" drivers in uDRM <:trl:82931664119...
After the Rooster bootloader is released
frozen matrix
only 500 more years
unkempt hearth
only 500 more years <:trl:829316641191886888>
Inshallah a whole lot less than that
unkempt hearth
oh?
I'm/It's not dead, though dolphin/revolution isn't the highest priority target rn
frozen matrix
ah, fair
I wish I had a GameCube, since it's a far easier target than the Wii
I'd try to improve support for it myself if I had the time π
static prairie
the only half bad thing is that on the Wii, in order to actually display a picut...
that's not that uncommon afaik
unkempt hearth
ah, fair
I wish I had a GameCube, since it's a far easier target than the Wii
If it gets to the point where uDRM for Flipper is called for/possible, Iβd give you money to buy a GameCube
tawdry trench
i'm going to work on udrm this week
i'll try to finish the kernel interface so i can have people test things
starting off with virtio-gpu instead of bochs because bochs needs port io
tawdry trench
free time moment!
i probably need someone to provide an implementation in their kernel because mine is too shit to actually run uDRM/Mesa
young copper
i probably need someone to provide an implementation in their kernel because min...
nyaux.
tawdry trench
nyaux can't run mesa afaicr
young copper
managarm
maiden birch
starting off with virtio-gpu instead of bochs because bochs needs port io
just add headers to do BARs i guess
bar_map/bar_unmap bar_read/write
tawdry trench
ye
do we support port io at some point?
bochs would be the only driver that needs it
jade pecan
i probably need someone to provide an implementation in their kernel because min...
Astral has mesa 
astral gate
I think the hobbyist osdev community as-a-whole might be unprepared for uDRM
tawdry trench
lol
there's at least 2 kernels without DRM drivers but with DRM capability out there
that's enough for me
mortal harness
I think the hobbyist osdev community as-a-whole might be unprepared for uDRM
if you build it they will come
tawdry trench
^
maiden birch
do we support port io at some point?
no
tawdry trench
good
maiden birch
we support a bar_read/write
which supports whatever the host wants
but actualy port io we need as well i guess
astral gate
well I'm glad that uDRM might be more than an idea when I have enough of a kernel to warrant DRM
maiden birch
for uPS2 and ACPI stuff
maiden birch
bar rw is enough for bochs right?
tawdry trench
no, bochs does modeset using port io
maiden birch
i guess we need arch headers then
hm?
all arches have port io
x86 just has them as separate address space
tawdry trench
so on other archs it'll just be mmio?
maiden birch
its a separate range in memory
main crow
the fwcfg DMA interface isnt always present
maiden birch
its still mmio just called pio tho right
main crow
also i think it might be port mapped anyway
main crow
its still mmio just called pio tho right
no its port io
maiden birch
i dont mean x86
main crow
on other platforms its a feature of the pci controller usually
main crow
yes
tawdry trench
but bochs doesn't use the bar from what i have read
agile halo
it doesn't even have a bar for it
main crow
kinda
main crow
you cant assume its mappable though
maiden birch
huh
main crow
x86 lol
maiden birch
its a handle that we treat as opaque tho
main crow
why then
maiden birch
r/w is done via api as well
tawdry trench
i'm not clear on how i would use that then
main crow
map_iobar(bus, slot, func, bar index) -> opaque handle
tawdry trench
again, it's not a bar
agile halo
its not a bar
maiden birch
use LTO
tawdry trench
maiden birch
(no J )
tawdry trench
or
maiden birch
why isa
astral gate
some sort of handle factory + uapi_io_inb(handle, offset)/uapi_io_outb(handle, offset)
tawdry trench
this
maiden birch
it is, just this naming is uncommon
main crow
yeah true
timid shore
just call it map_io and leave a doc comment
main crow
there is a problem tho
astral gate
maybe uapi_io_open(start, size)
main crow
this doesnt work for pci
maiden birch
/*
* Map a SystemIO address at [base, base + len) and return a kernel-implemented
* handle that can be used for reading and writing the IO range.
*/
uacpi_status uacpi_kernel_io_map(
uacpi_io_addr base, uacpi_size len, uacpi_handle *out_handle
);
void uacpi_kernel_io_unmap(uacpi_handle handle);
/*
* Read/Write the IO range mapped via uacpi_kernel_io_map
* at a 0-based 'offset' within the range.
*
* NOTE:
* 'byte_width' is ALWAYS one of 1, 2, 4. You are NOT allowed to break e.g. a
* 4-byte access into four 1-byte accesses. Hardware ALWAYS expects accesses to
* be of the exact width.
*/
uacpi_status uacpi_kernel_io_read(
uacpi_handle, uacpi_size offset,
uacpi_u8 byte_width, uacpi_u64 *value
);
uacpi_status uacpi_kernel_io_write(
uacpi_handle, uacpi_size offset,
uacpi_u8 byte_width, uacpi_u64 value
);
for bars you have separate function
maiden birch
this doesnt work for pci
for PCI we use the bar helpers u have suggested
agile halo
it doesn't have to be io specific
tawdry trench
^
main crow
its literally just for legacy io though?
astral gate
it can potentially be extended to other forms of io in the future
main crow
that should be different functions
astral gate
so like uapi_io_open (address_space, start, size)
agile halo
or actually maybe it kinda does
maiden birch
id just call it map_io and not overload it tbh
maiden birch
so like `uapi_io_open (address_space, start, size)`
interesting idea
astral gate
so like `uapi_io_open (address_space, start, size)`
there is a disadvantage to this type of thing
and it is that now uapi_io_read() and uapi_io_write() actually needs to store some useful information in the handle to determine the address_space
maiden birch
we already have this https://github.com/uDrivers/uAPI/blob/main/vm.h
so yeah lets not do
astral gate
otherwise the simplest implementation is just handle = (long) start;
maiden birch
lets just do uapi_kernel_map_io or map_pio or something idk
astral gate
it might just be me, but I like the open()/close() terminology more
because you're not so much "mapping" IO addresses, as you're declaring that "I intend to do port IO here"
astral gate
well naming is unimportant anyways
maiden birch
it might just be me, but I like the `open()`/`close()` terminology more
i did that for pci devices btw
but thats because that handle will be used for a lot more in uapi at least
like just referring to a pci device in general
astral gate
so not just me then :-)
tawdry trench
it depends on the context
maiden birch
here open makes a lot of sense because its a general purpose handle
maiden birch
it depends on the context
there's still no close there btw π
astral gate
to make an argument somewhat grounded on facts and not opinion, I guess it can be argued that open and close makes more sense for a microkernel design (as uapi_kernel_pci_device_open() might literally translate into a call to open() or a similar function)
astral gate
Will uAPI use the #include <uapi/...> include path?
because that conflicts with e.g. Linux use of that very same include path
tawdry trench
no
astral gate
great
main crow
also how are you doing on the whole driver thing?
astral gate
oh yeah it uses <udrv/...>
main crow
seems a bit more important than the kernel API, tbh
tawdry trench
also how are you doing on the whole driver thing?
elaborate
tawdry trench
what about it
main crow
how are you doing with it?
tawdry trench
didn't really have time to focus and mainly just did research into imagination and intel gpus
main crow
ah okay fair enough
astral gate
that would be pretty epic
main crow
tbf virtio is the easy one
astral gate
so what kernel will you be using for testing?
main crow
you may want to use linux for testing
in userspace
hosted, good debug tools, you can turn off drivers, does vfio
tawdry trench
good point
i've only ever written like 3 or 4 linux drivers before
this is going to be fun
main crow
well that turns off real drm, right?
main crow
why?
tawdry trench
because the drm manager is still going to run
main crow
even if you turn off the device?
tawdry trench
yea
tawdry trench
no it won't
main crow
well then whats the problem with the drm stuff running
tawdry trench
i mean yea i can disable gpu drivers, but since uDRM has two components i want to test both the DRM manager and the drivers
main crow
i mean yea i can disable gpu drivers, but since uDRM has two components i want t...
may i suggest testing modeset only at the start
and for that you dont need to mess with drm stuff
tawdry trench
sure, for now kms should be fine (pun intended)
main crow
also you can just make a fake /dev/dri node via CUSE
and then mess around with chroot to make apps see it as the real /dev/dri
actually idk if that would work
tawdry trench
dunno
main crow
yeah i think it would
maiden birch
tbf virtio is the easy one
idk man
it seems so
but leo tried and failed
with mesa that is
maiden birch
accel
main crow
oh yeah thats hard
tawdry trench
modeset shouldn't be a problem
maiden birch
modeset is like direct reg writes right
main crow
modeset is way more valuable imo
main crow
i mean if you have to choose one
tawdry trench
accel is useless without kms
main crow
accel is useless without kms
is it
tawdry trench
yes
main crow
why?
tawdry trench
what if you're stuck with a shitty gop fb
main crow
well then it will suck
tawdry trench
or better yet, no gop at all
main crow
usually its not that bad
tawdry trench
anyways, i'll start working on virtio now
tawdry trench
time to read specs
maiden birch
is bochs done?
maiden birch
virtio modeset is also 10 loc no?
tawdry trench
not really
main crow
virtio modeset is a lot more
tawdry trench
afaict you have to do some queue setup
maiden birch
do u need actual commands for it
main crow
keyronex has drivers for it
astral gate
afaik virtio-gpu modeset requires virtqueues
maiden birch
why do u need two?
main crow
idk but keyronex makes two
so i assume you need them
actually seems like for modeset you only need one
maiden birch
anyway we'll wait for marvin to tell us
maiden birch
ah ok u can just ignore the cursor one
iirc its usually just done as an overlay plane
tawdry trench
yea cursors are an extra plane
main crow
private enum BXVGA_DISPI_INDEX_ID = 0;
private enum BXVGA_DISPI_INDEX_XRES = 1;
private enum BXVGA_DISPI_INDEX_YRES = 2;
private enum BXVGA_DISPI_INDEX_BPP = 3;
private enum BXVGA_DISPI_INDEX_ENABLE = 4;
void bxvga_write_reg(uint idx, uint val) {
outw(0x1CE, cast(ushort)idx);
outw(0x1CF, cast(ushort)val);
}
ushort bxvga_read_reg(uint idx) {
outw(0x1CE, cast(ushort)idx);
return inw(0x1CF);
}
void bxvga_set_video_mode(uint w, uint h) {
bxvga_write_reg(BXVGA_DISPI_INDEX_ENABLE, 0);
bxvga_write_reg(BXVGA_DISPI_INDEX_XRES, w);
bxvga_write_reg(BXVGA_DISPI_INDEX_YRES, h);
bxvga_write_reg(BXVGA_DISPI_INDEX_BPP, 32);
bxvga_write_reg(BXVGA_DISPI_INDEX_ENABLE, 0x41);
}
lol this is literally all you need to do to do bxvga
tawdry trench
checks out
main crow
plus find the framebuffer in the appropriate PCI BAR
maiden birch
well yes and no
astral gate
see, here's the thing with this type of 'portable driver collection' that uDRM is: some things benefit from being able to use internal interfaces. eg. if the kernel already has infrastructure for virtio devices, it'd be nice to use that. but that comes at a cost in uapiβkernel size.
maiden birch
there are some vga writes u must do to refresh qemu window
we've debugged bochs restore for oberrow suspend code
tawdry trench
oh yea, sometimes bochs just doesn't care about blitting
it keeps stuff that should be cleared on screen
main crow
ramfb is the cool one anyway
maiden birch
bochs can too
main crow
shush
tawdry trench
should i include a driver for ramfb at some point?
main crow
yes
maiden birch
sure
tawdry trench
sounds like a job for simpledrm
main crow
though note that its nontrivial to implement correctly
because you may need to synchronize with the os
tawdry trench
oh
main crow
fwcfg is global
maiden birch
ramfb is the cool one anyway
tawdry trench
ramfb != simpledrm
maiden birch
wtf is ramfb then
main crow
-device ramfb -vga none
agile halo
a qemu specific virtual framebuffer device
maiden birch
all small ones are under tiny/
tawdry trench
well simpledrm is designed to map over "simple" framebuffers
main crow
#[derive(Debug, Clone, Copy, Pod, Zeroable)]
#[repr(C)]
struct RamFBControl {
addr_hi: u32,
addr_lo: u32,
fourcc: u32,
flags: u32,
width: u32,
height: u32,
stride: u32,
}
pub fn probe_ramfb(node: &Device<fw_cfg::File>) {
if node.name != "etc/ramfb" {
return;
}
// TODO: fail gracefully here
assert_eq!(core::mem::size_of::<RamFBControl>(), node.size as usize);
let buffer = OwnedBuffer::new(RAMFB_WIDTH * RAMFB_HEIGHT * 4);
let addr = buffer.as_ptr().as_ptr() as usize as u64;
let ctl = RamFBControl {
addr_hi: ((addr >> 32) as u32).to_be(),
addr_lo: ((addr >> 0) as u32).to_be(),
fourcc: u32::from_be_bytes([b'X', b'R', b'2', b'4']),
flags: 0,
width: (RAMFB_WIDTH as u32).to_be(),
height: (RAMFB_HEIGHT as u32).to_be(),
stride: (RAMFB_WIDTH as u32 * 4).to_be(),
};
node.write_entry(bytemuck::bytes_of(&ctl));
let ramfb = DeviceRc::new(RamFB {
parent: node.dup(),
buffer,
});
super::fbterm::FBTerm::new(ramfb.cast::<dyn Framebuffer>().dup());
}
and the driver is like no code
maiden birch
but my bootloader has it so
better than linux
mortal harness
i think ramfbs get described in a simplefb entry in an device tree by the firmware
such as shkwve or IBM SLOF
main crow
i think ramfbs get described in a simplefb entry in an device tree by the firmwa...
that doesn't include all the modeset stuff though π¦
tawdry trench
shkwve feature complete confirmed
i don't think you can modeset simpledrm
let me check
main crow
yeah
and you can do it with ramfb
i can write a /chosen/framebuffer FDT entry too btw
so
clear W
main crow
wtf
they dont do ramfb tho
"etc/ramfb" yields no matches
eh whatever its fine i can live with a monopoly on ramfb devices
tawdry trench
lol it only has one valid mode
main crow
lol it only has one valid mode
fn fb_available_modes(self: &Device<Self>) -> Vec<VideoMode> {
vec![VideoMode {
id: 0,
pixfmt: pixfmt("x8r8g8b8"),
width: RAMFB_WIDTH,
pitch: 4 * RAMFB_WIDTH,
height: RAMFB_HEIGHT,
}]
}
``` shkwve I also have it in my kernel
tawdry trench
kek
agile halo
agile halo
tawdry trench
nouveau in a bootloader near you
maiden birch
looks so much cleaner than rust ngl
main crow
anyway im gonna try making keyboard support works
tawdry trench
looks so much cleaner than rust ngl
this
maiden birch
well
jade pecan
Need to take some tips from astral on how to write unclean code this is too clean for my soul
maiden birch
if you think so
agile halo
and .serialize lol
maiden birch
optional too no?
main crow
and the optional
maiden birch
so like most of it 
main crow
true lol
tawdry trench
and the BOOT_FB.initialize member function
BOOT_FB could be a struct with function pointers
main crow
BOOT_FB could be a struct with function pointers <:meme:575445094589661215>
that would suck in terms of perf
tawdry trench
it's literally the same thing, no?
tawdry trench
if BOOT_FB had vtables
maiden birch
it's literally the same thing, no?
it would be if this is a virtual class
which it isnt
tawdry trench
udrm in shkwve when
main crow
udrm in shkwve when
when it works, and i feel like writing a driver, and its not that bad and integrates with my device subsystem properly
main crow
and when i actually do real hw it could help on
maiden birch
be a qemu os like serenity
main crow
no i want to be an m1 os
maiden birch
lol
main crow
no i want to be an m1 os
m1 display stuff is great afaik
they have all the hard display logic on a coprocessor
jade pecan
be a qemu os like serenity
Does it not boot in real hw
maiden birch
Does it not boot in real hw
lol no
main crow
sometimes yes
jade pecan
Even astral boots in real hw if you dont want a keyboard
tawdry trench
https://sdomi.pl/weblog/23-serenityos-realhw/
hahahah wtf
menix runs on more machines than serenity
maiden birch
probably even nyaux does
main crow
lol
tawdry trench
IT DOESN'T EVEN HAVE UEFI SUPPORT????
agile halo
oh also qwinci doesn't do a device subsystem
yeah for the ramfb specifically I don't, for other devices I do have proper discovery stuff ```cpp
static DtDriver SPMI_DRIVER {
.init = spmi_init,
.compatible = {"qcom,spmi-pmic-arb"}
};
DT_DRIVER(SPMI_DRIVER);
static DtDriver GIC_V3_DRIVER {
.init = gic_v3_init,
.compatible {"arm,gic-v3"},
.provides {"gic"}
};
DT_DRIVER(GIC_V3_DRIVER);
WHAT ARE THESE GUYS DOING
maiden birch
IT DOESN'T EVEN HAVE UEFI SUPPORT????
its grub only so no
tawdry trench
how does anyone take them seriously π
mortal harness
how does anyone take them seriously π
browser
tawdry trench
...
maiden birch
(which is now a separate project )
mortal harness
possibly you can even visit facebook with it now to send messages to your mam
jade pecan
Making an os that only boots from a floppy and downloads the entire image from the network
tawdry trench
possibly you can even visit facebook with it now to send messages to your mam
you can do that with managarm on real hw
mortal harness
(paraphrasing a blogpost by the serenity os guy, i can't remember his name, cillian alexander or something like that)
main crow
yeah for the ramfb specifically I don't, for other devices I do have proper disc...
no driver composition tree? cringe
mortal harness
andreas klinge, that's it
main crow
kling
maiden birch
lol
tawdry trench
andreas cring
maiden birch
u mean cringe
main crow
no driver composition tree? cringe <:meme:575445094589661215>
- no type safety
you dont even have enough information for pretty colors
agile halo
no driver composition tree? cringe <:meme:575445094589661215>
its also cringe in that it has defer init status 
I am not completely sure what other good alternatives there are tho, like in this case I depend on the phy reset node to be initialized before the main driver
mortal harness
Making an os that only boots from a floppy and downloads the entire image from t...
keyronex doesn't have a tmpfs at the moment so to test whether it could boot to the posix server on real hardware, i had to do an e1000 driver and do mount over 9p
tawdry trench
its also cringe in that it has defer init status <:KEKW:913708372329644042> I am...
ur c++ is so clean
jade pecan
keyronex doesn't have a tmpfs at the moment so to test whether it could boot to ...
Is 9p complicated
mortal harness
that's why i can't test it to that extent on bare metal raspi4 yet - it has some stupid proprietary nic called janet
main crow
Is 9p complicated
virtio-9p is trivial
mortal harness
Is 9p complicated
it's one of the most trifling protocols
maiden birch
its also cringe in that it has defer init status <:KEKW:913708372329644042> I am...
os
tawdry trench
mortal harness
use 9p2000.l and you've basically got the crudest possible serialisation of linux vfs operations over either virtio or a network transport
main crow
yeah
jade pecan
Interesting
maiden birch
it's one of the most trifling protocols
why is that
main crow
its also cringe in that it has defer init status <:KEKW:913708372329644042> I am...
i have a kinda similar thing except with the PLIC (and every other driver that needs interrupts)
my "solution" is to always probe all the FDT nodes for a plic first
mortal harness
why is that
original 9p is basically just "here are the 9p fs ops in the simplest possible serialisation available", 9p2000.l is the same for linux vfs ops
agile halo
ur c++ is so clean
idk what is so clean about it except that I try to keep logically related things in blocks instead of cramming everything together without newlines
tawdry trench
you write c++ like i write c
mortal harness
https://github.com/chaos/diod/blob/master/protocol.md here is the closest to a canonical spec
main crow
idk what is so clean about it except that I try to keep logically related things...
NEWLINES?
whats that
you mean putting everything in one big block with zero separation?
mortal harness
NEWLINES?
something that MINOCA loves, plan9 doesn't, and the rest of us feel somewhere in-between about
maiden birch
my "solution" is to always probe all the FDT nodes for a plic first
interesting
wrong ping lol
i mean 9p is very old right
main crow
yeah
9p2000.L is the cool one
its super easy
especially compared to the hell that is NFS
unkempt hearth
tawdry trench
Now do accel too
inner crater
No I'm serious
You and infy know full well that I didn't manage to get it to work
I would like to see someone succeed
inner crater
I saw the GPU being hit in gputop or whatever it was called
But I never got the result rendered
I was submitting buffers just fine tho
Like I even manually decoded and verified their validity
tawdry trench
hm
maiden birch
You and infy know full well that I didn't manage to get it to work
Indeed
tawdry trench
inshallah we will get this to work
if i do i should probably write driver bindings for managarm
maiden birch
if i do i should probably write driver bindings for managarm
Yeah, managarm was one of the first to adapt uacpi too.
Keep in mind they already have drm
tawdry trench
perfect
maiden birch
And their GPU drivers live in userspace
main crow
i mean, i'm open to shkwve uDRM support
tawdry trench
π₯Ί
maiden birch
i mean, i'm open to shkwve uDRM support
No mesa port sooo
tawdry trench
well it still does the kms
maiden birch
Only modeset for u
hexed flare
i probably need someone to provide an implementation in their kernel because min...
pmOS GUI any% 
maiden birch
pmOS GUI any% <:ultrameme:729026898666979428>
Mesa first
tawdry trench
hexed flare
for PCI we use the bar helpers u have suggested
Will there be a separate function to read/write from/to PCI registers?
maiden birch
Will there be a separate function to read/write from/to PCI registers?
Already exists
hexed flare
https://sdomi.pl/weblog/23-serenityos-realhw/
wtf
hexed flare
Already exists
because those kinda need a global lock, if you don't have ecam
hexed flare
pmOS GUI any% <:ultrameme:729026898666979428>
(I don't even have a shell yet)
Though I guess I'll have whatever I want if I port mlibc
maiden birch
because those kinda need a global lock, if you don't have ecam
Ofc
We won't have any sort of resource without r/w helpers
To make it as portable as possible
hexed flare
I wonder how uDRM will react to casually being fork()ed
tawdry trench
i wonder how drm_open should work
that would require some form of posix i think
unless we abstract that away as well
does that even make sense?
you're doing ioctls anyways
tawdry trench
@maiden birch uAPI file functions Y/n?
uapi_file_open, uapi_file_close and the sort
i need a way to interact with a VFS
jade pecan
How would you know like what path separator to use and stuff
tawdry trench
exactly my point
i mean, technically speaking uDRM assumes you're on a unix/posix system
because of ioctls
linux drm does this
i need to think of a way on how to properly abstract this
my initial idea was to keep reference to the /dev/dri handles after they're created and use those pointers for i.e. udrm_file_open
so
udrm_file_handle udrm_create_card_node(const char* name, udrm_device_handle device);
uapi_status udrm_file_open(udrm_file_handle file);
u mean like vfs ops hooks?
tawdry trench
i don't really need path access, i just need a way to hook into read/write/ioctl calls to the /dev/dri/card0 etc nodes
maiden birch
yeah
agile halo
can't you just like have callbacks that the kernel calls for them?
agile halo
well like the kernel would create the file and then redirect reads/writes/ioctls to udrm
tawdry trench
well, udrm still has to tell the kernel to actually start doing that though
if you're using the built-in drm impl instead of your own
livid sentinel
what exactly would be the purpose of uAPI file functions? loading .so/configs?
tawdry trench
no
tawdry trench
so
```c
udrm_file_handle udrm_create_card_node(const char* name, udrm_device_han...
this
i will just have a function to do this
and expect the kernel to handle this appropriately
livid sentinel
has this something to do with the way linux treats everything as a file/file descriptor?
if yes, please dont, it would be a pita to use on anything that doesnt follow that principle
technically uapi would only need to tell its interface that it wants to be notified of certain actions
without needing to know if its like a file descriptor or something else
tawdry trench
has this something to do with the way linux treats everything as a file/file des...
it doesn't really matter as long as i can expose the functions
that said, drm kinda assumes *nix
I'll try my best to keep nix specific shit out, but i can't tell atm
livid sentinel
things like posixs are fully ok, the problem starts when uapi starts to make assumptions on things like how the os structures things internally
livid sentinel
it doesn't really matter as long as i can expose the functions
maybe a opaque object like aproach?
you call init and it returns a opaque object on which you can do stuff including giving you more objects
timid shore
yeah that would be preferable
livid sentinel
that way the interface layer can do the conversion between native and uapi
timid shore
yeah
maybe its my not entirely understanding DRM but i dont see why anything here should ever be a file
livid sentinel
imho "everything is a file (descriptor)" is one of the most stupid things ever
half forge
"everything is a file descriptor" is great because a file descriptor is just a synonym for a handle
tawdry trench
maybe its my not entirely understanding DRM but i dont see why anything here sho...
all drm user actions are done on a file
half forge
"everything is a file" is.. less great
timid shore
"everything is a file descriptor" is great because a file descriptor is just a s...
then just call it everything is a handle imo
livid sentinel
"everything is a file descriptor" is great because a file descriptor is just a s...
the problem starts once you treat a device like a file with open/close etc, everything is a handle is fully sane but then you need specific operations for each handle type
timid shore
all drm user actions are done on a file
actually a file in a real file system? or just an opaque handle that is treated like a file in existing systems that use drm?
tawdry trench
existing drm systems all have actual files
/dev/dri/cardX
you open the file to open the card and to obtain a handle
timid shore
like its a file with contents stored on disk? surprising for something under /dev then
tawdry trench
like its a file with contents stored on disk? surprising for something under /de...
no
it's a virtual file, i might've misunderstood your question
timid shore
then it isn't a file in the sense i meant and given its a device I believe it should never be represented as a file
its a block device by the sounds of it
tawdry trench
yea
timid shore
does udrm plan to do discovery at all?
if not then it should just take an opaque handle when being given a card and then pass that back as context when doing read/write/whatever ops later imo
tawdry trench
does udrm plan to do discovery at all?
discovery of cards?
tawdry trench
no, the kernel does the pci detection and then the kernel shim is supposed to call the probe function of the driver
timid shore
ok cool
in that case it should definitely be some sort of kernel-context handle that gets passed into udrm on probe and kept if it is a card so that the kernel can reference the device in io callbacks
main crow
its a block device by the sounds of it
character device
block devices are only for disks
and only on not freebsd (iirc)
main crow
NT HANDLE == linux file descriptor
livid sentinel
on udrm init the kernel gets a handle with that it can for example register a pcie device to udrm/ its drivers and the udrm object can be used to enumerate gpu objects that are created when giving udrm a gpu
or something simmilar
timid shore
NT HANDLE == linux file descriptor
i know
main crow
so yeah same thing
timid shore
character device
so its a device with read/write methods but no seek?
main crow
so its a device with read/write methods but no seek?
it has all of them
or none of them
the behavior depends on the kind of device
timid shore
ig thats the better question is what methods does udrm need the card device to have
main crow
ioctl
and mmap
actually i dont know mmap
some kinds of file descriptors you get from DRM need to have mmap tho
and ioctls on literally everything
timid shore
ok and for the people who think in terms of windows, what does it need to ioctl for? everything or anything in particular?
my kernel has no interest in even pretending to be posix-like so im wondering if udrm will ever be an option
half forge
DeviceIoControl
agile halo
yeah windows also has ioctl
half forge
(I'm pretty sure the set of DRM ioctls depends on the specific driver)
main crow
it does
half forge
there's a few generic ones but yeah
main crow
DeviceIoControl, or whatever API you have that is glued up to mesa ioctl
tawdry trench
there are shared ioctls and driver specific ones
tawdry trench
yea i think modeset doesn't need driver specific stuff
timid shore
wait is udrm implementing or calling these? shouldve clarified that first
half forge
udrm is the kernel's side of things so it implements ioctls
timid shore
ok so thats not an issue with tying things in then
tawdry trench
wait is udrm implementing or calling these? shouldve clarified that first
implementing
half forge
if it uses them as well I'd say that whatever code does so is hacky and should be rewritten
timid shore
a nonposix system would just call the right ioctl for whatever it needs to call
so thats cool then
brings the question again of why theres any need for vfs as described above though
tawdry trench
brings the question again of why theres any need for vfs as described above thou...
there is not
timid shore
just give back an opaque handle for each card you successfully probe
tawdry trench
yea but that doesnt solve the problem, because HOW would i do that
as in, what's the desired design here
timid shore
what is the signature on probe?
id assumed probe takes a prospective maybe-video-card device and returns something to indicate if udrm can take ownership of it
mortal harness
brings the question again of why theres any need for vfs as described above thou...
Drm inherently part thereof
tawdry trench
uapi_status udrm_bochs_probe(uapi_pci_handle pci_device);
timid shore
id just add a second parameter thats uapi_device_handle* or something like that, no?
tawdry trench
there is a udrm_device_register function
that registers the handle
this is called by the drivers
timid shore
that takes the pci device too i assume? in that case that should be all you need, no?
tawdry trench
wdym?
main crow
some graphics devices aren't associated with a PCI device
timid shore
ah true rip
either way theres a function to register a graphics device with udrm that returns a handle
tawdry trench
there's simpledrm for example
timid shore
just let that handle be the one passed to read/write/ioctl/etc
main crow
there's simpledrm for example
KMS-only uDRM doesn't really need to have simpledrm
tawdry trench
why not
main crow
the point of simpledrm is to turn a framebuffer into a drm device
tawdry trench
it's just a way to refer to a fb
main crow
and the point of KMS-only uDRM is to turn a graphics card into a framebuffer
so i dont really get what the point of having simpledrm would be
half forge
udrm isn't intended to be kms-only though right
main crow
actually ig it might be useful for probing stuff
timid shore
yeah that would let you use a unified setup for it all presumably
shut sorrel
: kms :
maiden birch
most tested library
tawdry trench
median yoke
@maiden birch I feel like uAPI should have acpi related stuff in the headers
(don't ask me what, I don't know)
maiden birch
it should yes
maiden birch
kernel api for parsing pci caps is overkill
maiden birch
maybe as a separate library used internally by udrm
tawdry trench
that's not the issue
it's boilerplate that i would have to copy paste between drivers
(assuming it's used more than once)
median yoke
<@353593948523986945> I feel like uAPI should have acpi related stuff in the hea...
It probably should have functions for D states (for PW management)
And tables
maiden birch
There should definitely be a power.h or something
median yoke
Also there is PCI D states
maiden birch
And igpus need aml for notifications and stuff
main crow
it's boilerplate that i would have to copy paste between drivers
its just an internal function thats part of udrm
tawdry trench
ig
tawdry trench
@maiden birch if we have no way of getting the page size, i vote to make uapi_kernel_allocate_pages work in bytes instead of pages
maiden birch
We should require it via platform/arch.h or something
Like uacpi does
It should be a define
tawdry trench
what about dynamic page size that may not be know at compile time
maiden birch
Make the define call a function instead
I think overridable arch.h or similar is the way
tawdry trench
hm
reason i'm sayin this is that kernel_map also takes bytes instead of pages
so both should use the same params
imo
shut sorrel
bytes seems better
tawdry trench
?
maiden birch
so both should use the same params
Dunno lets discuss a bit later
main crow
it always will be 64k or less, afaik
tawdry trench
the problem is that i want to have at least x bytes of physical memory
main crow
so if the os has dynamic page size, it just reports 64k
ah wait right
yeah
that doesnt work super well
tawdry trench
i basically just need a malloc that gives me physical addresses
tawdry trench
i'd be fine with that
main crow
oh also
maiden birch
i basically just need a malloc that gives me physical addresses
Maybe that should be separate api
main crow
phys_alloc(size, align)
which returns the tuple (OS address, device address)
oh wait that doesnt work, you do need the page size
maiden birch
DMA buffers should be separate API imo
maiden birch
No idea what Marvin is cooking
main crow
thats just a normal allocation
tawdry trench
virtio wants a physical address
main crow
a physical one that is
tawdry trench
that's what i'm saying
tawdry trench
and we also have no api to convert virtual to physical
main crow
you do need an API to get the OS page size
maiden birch
uapi_virt_to_phys?
main crow
and we also have no api to convert virtual to physical
you cannot do that
this cannot work
you must allocate both the physical and virtual addresses at once
because the gpu can be behind an IOMMU
maiden birch
I would just make it so u can virt to phys kmalloc allocations
Not for dma
But for stuff like this
main crow
I would just make it so u can virt to phys kmalloc allocations
but you cant
maiden birch
Surely u can
main crow
kmalloc allocations do not have enough alignment for that
and could cross page boundries
maiden birch
Wdym
maiden birch
vmalloc api when
main crow
what you need is an api for allocating dma buffers
main crow
virtqueues are literally DMA lol
maiden birch
They are?
main crow
yes?
half forge
anything that involves the device accessing normal ram is dma
main crow
yup
maiden birch
Then I guess Marvin is up for a design challenge
main crow
do you want me to spoil the fun by showing what the fusl solution is
typedef
#ifdef FUSL_PHYS_32BIT
uint32_t
#else
uint64_t
#endif
FUSL_PHYS;
struct FUSL_PADDR {
// Virtual address FUSL can use to access the memory
uintptr_t fusl_address;
// This is the address the device should use to reference this region, if you support IOMMU
// this is is the device-virtual address, otherwise it's the physical address.
FUSL_PHYS device_address;
};
// Allocate physical memory for the given device.
// If IOMMU is used, it may help to reference `controller->pci_dev` or `controller->user`
// Pointer stability for `controller` is _NOT_ guaranteed!
struct FUSL_PADDR (*palloc)(struct FUSL_Controller *controller, size_t size, size_t align);
you have a palloc which returns both the virtual and physical address at a given minimum size/align
no idea why there is an explicit align tbh
maiden birch
```c
typedef
#ifdef FUSL_PHYS_32BIT
uint32_t
#else
uint64_t
#endif
FUSL_PHY...
Makes sense
tawdry trench
what's fusl again
main crow
ah i guess if its less
main crow
what's fusl again
n00byedge's usb thingy
also keep in mind that device addresses are device-specific
you cant get one "in general", you must get it for that specific PCI device
half forge
yea it mostly doesn't exist on x86 but on other architectures the device's physical addresses are often completely different from cpu's physical addresses
maiden birch
Just pretend no other arches exist
maiden birch
Dark fire has an aarch64 windows laptop
tawdry trench
so do i
maiden birch
Which is cool
median yoke
Dark fire has an aarch64 windows laptop
Fake news
tawdry trench
so what
maiden birch
Least rich suse employee
tawdry trench
laugh at the 16k iommu user
main crow
laughs in apple,t8103-dart
livid sentinel
What about a map_device_memory which takes in the wanted size and returns a handle virt addres and device relative address, it always aligns the region to a page boundary and is allowed to use a iommu
And a map_config_space map_bar
The handle of map_device_memory can be used to resize the allocation or delete it
livid sentinel
To my knowledge drivers don't need to know where in physical address space something is mapped as long as they know what address the device needs to access it
tawdry trench
same
north rock
with reactos WIP kernel and asahi linux dual boot
maiden birch
ros boots on arm64?
north rock
boots is a strong word
maiden birch
lol
north rock
i wrote the port from the ground up awhile back, realized the architecure of resource managmenmt in ros is broken
and then started pursuing fixing hal/acpi
etc
tawdry trench
how broken is the x1e acpi
north rock
it never got to usermode
north rock
I stopped blaming hardware acpi being ass when its unable to boot linux a long time ago
Linux has some serious issues
i have a lot of hardware that can't boot linux
tawdry trench
well as long as windows boots
north rock
we'll see soon i guess if uACPI handles it
maiden birch
we'll see soon i guess if uACPI handles it
well the blob did load in userspace uacpi at least lol
north rock
so there we go
i have an rk3588 with windows on it too,
and a qc710
and uh. 5 different phones
and a pinebook pro but i wrote the blobs for that one
obtuse matrix
I guess uUserspace is just busybox xD
main crow
What about a map_device_memory which takes in the wanted size and returns a hand...
with a lot of allocator designs, you can't request any size other than one page
livid sentinel
with a lot of allocator designs, you can't request any size other than one page
physical pages?
without a iommu these wouldnt work in the first place
livid sentinel
then they definetly need the capability to give you continous physical pages
agile halo
yeah a lot of hardware works just fine with single pages
main crow
windows does not have the ability to do that at runtime
they can do it, but its insanely slow
and you should only do it at init time
(they linearly scan the pfndb for free pages for that)
tawdry trench
virtio needs consecutive pages
main crow
no it doesnt
livid sentinel
yeah a lot of hardware works just fine with single pages
cant imagine that gpus would work with that unless some kind of scatter gatter list is used
tawdry trench
it says in the spec
main crow
cant imagine that gpus would work with that unless some kind of scatter gatter l...
they need a scatter gather list
tawdry trench
memory has to be physically continuous
main crow
then you should make a smaller queue
the queue size is an upper limit
iirc
yeah
its the maximum queue size
tawdry trench
yes you can make it smaller, but is there any upside to it
main crow
not the required queue size