IRC channel logs

<damo22>ok there are two known bugs now preventing X from starting on real hardware

<damo22>1. acpi translator doesnt handle int 9 properly

<damo22>2. vesa is broken on coreboot

<damo22>i get intnull(9) during boot and freeze

<damo22>i think we need to add interrupt handler registration to acpi

<damo22>its currently not implemented but im not sure why im not getting the corresponding error message

<almuhs>damo22: maybe this irq is linked to other thing?

<almuhs>other thing: why https://darnassus.sceen.net/ doesn't load?

<youpi>almuhs: just temporary hick-up

<almuhs>ok, thanks by the info

<almuhs>now online

<damo22>irq handler [4097]: new delivery port f5e10bc0 entry f5547ee0

<damo22>why does it try to use 4097?

<damo22>i just implemented irq registration

<damo22>random init open failed

<damo22>how do i skip random init?

<damo22>inside the acpi translator

<gnucode>damo22: ok there are two known bugs now preventing X from starting on real hardware...I think you meant to say

<gnucode>there are 2 known bugs preventing X from starting on real hardware using coreboot/libreboot

<gnucode>I'm using X on real hard ware with a T43 (proprietary BIOS)

<damo22>yes

<damo22>ok i found and solved a chicken/egg problem

<damo22>libirqhelp cannot fail when cannot connect to acpi because acpi might need to register an irq

<damo22>now i get "start: pci acpi intnull(9) HANG"

<damo22>what is special about int 9

<zamfofex>Small piece of thought: I wonder what a “minimal” Hurd distro would be like size‐wise. Something like maybe DSL, but for the Hurd. I was able to build a usable Linux kernel weighing about 0.5 MB.

<gnucode>damo22: I'm trying to wrap my head around the irc conversation that you all had today. I probably will end up re-reading it a few times to try to figure it out.

<gnucode>zamfofex: probably pretty tiny. You could take a look at flavio's cross-hurd project.

<damo22>youpi: is gnumach UP built with --enable-apic ?

<youpi>no

<damo22>ohhhh

<damo22>i built a UP with --enable-apic and it seems to get further on real hw

<damo22>but rumpdisk cannot probe the AHCI

<damo22>its difficult to debug without a serial console on hw

<damo22>i sent in some patches to the ML to get things closer to working for acpi on actual hardware

<ZhaoM>darnassus.sceen.net is down

<user_oreloznog>Good morning hurd!

<etno>What is the pattern for tracking client related resource/session in a mach server ? Is there an event on the ports provided ? Or does the server have to explicitely listen for a client's death ?

<damo22>if the mach server exits, you can clean up after the server loop i guess?

<damo22>but thats server side

<damo22>im getting this error from rumpusbdisk:

<damo22>ehci0: can't map memory space

<damo22>something to do with bus_space_map() im guessing

<etno>damo22, I mean: how does a server detect when a client dies ? The ports sent to clients have an event, or the server listens for every client life-cycle ?

<youpi>etno: you have the dead-name notification

<etno>I guess it is MACH_NOTIFY_DEAD_NAME via mach_port_request_notification(). Thanks !

<damo22>"sudo Xorg -logverbose 7 -logfile test.log" can give me info i need when vbe fails on real hw

<damo22>it just says No screens detected

<damo22>it does not try to probe vbe or int10 sub modules of X

<damo22>youpi: #if defined(__i386__) || defined(__amd64__) || defined(__hurd__)

<damo22> xf86AddMatchedDriver(md, "vesa");

<damo22>is __hurd__ the correct thing to check for?

<damo22>or should it be __GNU__

<youpi>both will work

<youpi>ah, no, it's hurd that would work

<youpi>not __hurd__

<youpi>better use __GNU__

<youpi>mm, not event hurd works

<youpi>s/event/even

<youpi>I can commit that directly to xserver

<damo22>do you want a patch?

<youpi>it's trivial enough, thanks :)

<damo22>i will test

<damo22>youpi: i dont understand the versioning, which branch of xorg-server do i use from salsa to build xserver-xorg-* ?

<youpi>debian-unstable

<youpi>usually I just apt source, to simply get the current source

<damo22>ok there is xorg-xserver in salsa as well as xorg, so i got confused

<youpi>xorg is the meta-package

<damo22>i can try hacking the binary to replace fbdev\0 with vesa\0\0

<youpi>:D

<youpi>but really, recompiling a package is a mere apt source foo ; apt build-dep foo ; dpkg-buildpackage

<youpi>that being said, we already have __i386__ defined on gnu/hurd

<youpi>so that won't make a difference

<youpi>it'll only be for non-x86 hurd

<youpi>but is there vesa there?

<damo22>no idea

<damo22>it says "No devices found"

<damo22>something is failing very early to probe

<damo22>it doesnt get past this line, it fails here

<damo22>[2927384.009] (II) VESA: driver for VESA chipsets: vesa

<damo22>on qemu, it loads vbe submodule and int10

<damo22>but the log is falling very short on coreboot hw

<damo22>which is interesting because vesa is implemented by seavga on qemu

<damo22>so it should be very similar code

<damo22>on qemu [2927384.029] (II) VESA(0): VESA VBE Version 3.0

<damo22>[2927384.029] (II) VESA(0): VESA VBE Total Mem: 16384 kB

<damo22>No devices detected.

<damo22>s/found/detected

<damo22>hw/xfree86/common/xf86Bus.c: 154

<damo22>its failing there

<damo22>LOL:

<damo22> Identifier "Card0"

<damo22> Driver "vesa"

<damo22> BusID "PCI:0:1:0"

<damo22>but on real hw the BusID is different

<youpi>you had a hardcoded configuration?

<youpi>you shouldn't need one

<damo22>gah

<damo22>\o/ got to the bottom of this

<damo22>the VBE 3.0 is detected but no screens are usable because mode 3 is the only mode

<damo22> https://paste.debian.net/plainh/2f0e8bd5

<damo22>this could be fixed in seavga by exposing more VBE modes but still setting mode 3

<damo22>if coreboot can light up the display only at a single resolution, it should be configured to be the maximum resolution of the attached monitor

<damo22>and also somehow support mode 3

<damo22>the display could be modeset once by coreboot and any resolution lower could fit inside the old framebuffer

<damo22>but it cant be set to mode 3 initially or there isnt enough pixels to display X

<damo22>and its just a text console otherwise

<azert>damo22: I think that the bios is reporting the old video mode 3 (80x25 16 color text)

<azert>If you configure your framebuffer to be graphical, then either you boot directly into X11 or you need to setup a graphical framebuffer console, that I think the Hurd currently doesn’t have. Right?

<youpi>azert: it doesn't indeed, but AIUI it's basically only x86 that has a real textmode that the hurd console current supports.

<youpi>Adding a graphical support to the hurd console shouldn't be too hard

<azert>youpi: sure

<azert>What I am wondering is if the Hurd console supported such a feature (necessary for x64) then one could also export one of the many frame buffer apis so that X11 can use them

<youpi>probably

<azert>youpi: freetype is gpl3 compatible. Can we use this library to make a frame buffer console?

<azert>I’m a bit worried about non-fixed size fonts..

<youpi>sure we can use it rather that reimplement the world. But we can as well for a start just blit the font glyphs that we already have support for

<azert>But the better scalability over bitmap fonts seems like a plus

<youpi>sure

<youpi>I'm just saying that the MVP doesn't need that

<azert>youpi: in my opinion the quickest refactor would be to split vga-dynafont.c in two files: one that is vga specific and the other backend independent

<azert>Then write a fb-dynafont to support the same fonts on a frame buffer

<azert>and finally a framebuffer backend that basically uses blitting plus scaling according to the configuration

<azert>One can add multiple scaling functions such as the ones implemented by dosbox to add a touch of retro taste

<youpi>not even necessary to scale, you can just do like linux' console: just have as many characters that can fit without scaling

<youpi>> split vga-dynafont.c in two files: one that is vga specific and the other backend independent

<youpi>Indeed, the font loading and the vga-dynamic part should be split

<youpi>the vga-dynamic part is what makes it cool on vga, but useless when doing sw blitting

<gnucode>This is weird to me to learn that the BIOS (coreboot) has to provide support for the OS

<gnucode>graphics

<youpi>probably essentially the functions starting from dynafont_lookup_internal are really vga-only

<youpi>gnucode: BIOS provides various support for the OS

<youpi>e.g. can be acpi

<youpi>it's way simpler to support odd hardware when it's the bios that sets it up

IRC channel logs

2024-10-21.log