hrm...

Who do I need to get into contact with to handle issue tracker/gerrit account management?

jclulow is probably your best bet

Sounds good. I will likely dispatch an email here shortly then. Thank you jbk.

Your attention please!

Whomst amongst you will run this for me and tell me the output: pfexec mdb -ke 'fb_info::print paddr'

paddr = 0xbe9d7000

not sure to what degree I have an fb

To some degree, certainly!

across an assortment of machines: paddr = 0xf9000000 ; paddr = 0xbc000000 ; paddr = 0xfa000000 ; paddr = 0; paddr = 0xfd000000

thanks sommerfeld

Critically they're all inside the 32-bit space

I think things become a bit sad if the framebuffer mapping ends up higher than that

yeeeah, nah: github.com/illumos/illumos-gate/blo…/uts/i86pc/boot/boot_fb.c#L422-L423

We should really get to the point where loader can just jump to the ELF entrypoint

in long mode already

(BTW, those machines were a mix of oldish (decade+) and newish (purchased in last 2 years) plus one virtual machine (oddly, that wasn't the one with paddr==0)

Yeah. I have a brand new machine that has an AMD GPU which has chosen to put the framebuffer up high at 0xfce0000000

which, hilariously, when truncated, is I think e0000000

which is the mmio base for PCI

ope

That is a disaster.

the paddr=0 machine is the newest, and it's got displayport and HDMI connectors (displayport worked on initial install but it's running headless right now with a serial console)

sommerfeld: I think when you're headless sometimes the firmware just won't plumb up the graphical EFI stuff

which makes total sense -- why waste memory on a frame buffer nobody's going to use?

well, (a) the firmware doesn't actually know that, (b) I might plug one in!

But the real answer is, of course, DRM/KMS

so that we can, you know, turn the screen on ourselves as needed, etc

alas

I will stop us shitting into the mmio space lol