IRC channel logs

<damo22>as far as i understand, drm implements gpu acceleration via ioctls

<damo22>with hardware specific implementations done per card series

<damo22>and the kernel has all the low level implmentations

<damo22>its supposed to abstract the complexity away so there is a common interface for running gpus

<damo22>maybe we can implement a dummy libdrm that just has the framebuffer from multiboot

<damo22>modesetting and crtc selection is a big deal on hw

<damo22>but we dont even need that

<damo22>trying to copy libdrm/omap driver, but it doesnt make any sense, its all talking about buffers and how to create and reference them, but nothing about drawing to the screen

<etno>My understanding of DRM (rudimentary), is that it provides display and rendering context mgmt. Then the majority of chips will do GL/vulkan/VG rendering in each context. There has to be a way to simply map video memory instead and use soft/mesa, but omap is likely pure hardware rendering.

<etno> https://man.archlinux.org/man/drm-memory.7.en#Dumb-Buffers

<damo22>i spoke with dave airlie, i can implement a dummy drm driver that allocates buffers in userspace to cpu memory and writes the buffers to a dumb framebuffer via ioctls, then add a simple libdrm client that hooks into it

<etno>damo22: the long term goal would be to have a Hurd server respond to ioctls on /dev/dri/card0 so that Wayland+libdrm is happy ?

<damo22>yes, that is the short term goal

<damo22>but no hardware accel

<damo22>it can reuse the grub multiboot fb

<etno>The default rendering stack would be using those dumb_buffers at the bottom.

<damo22>i was thinking of calling the drm driver dumbfb

<damo22>(02:36:21 PM) airlied: drm_mode_fb_dirty_cmd

<damo22>(02:36:56 PM) airlied: sw renders to the buffer, and that will sync dirty regions to hw

<etno>Overall, this sounds terrific damo22 (and terrifying as well 😅)

<damo22>its subtle, but there is no draw command, drm just marks regions of fb as dirty and then the ioctl tells the hardware to fix it

<damo22>with a pointer to some src, dst clips

<etno>How do you plan to share the framebuffer device between DRM and the new Hurd's fb console ? Should the fb console become a DRM client?

<damo22>ive done that, i wrote a device(mbinfo) that tells userspace where the framebuffer is

<damo22>oh you mean the new vt thing

<damo22>they should probably be mutually exclusive while X uses the fb

<damo22>s/X/wayland

<damo22>with no page flipping, the display might tear, but i could implement a software page flip by memcpying a whole complete frame to the display memory in one go

<etno>Not more than current X, I suppose

<azert>damo22: what is pageflipping? Sounds like something that should be atomic

<azert>If you really need it, maybe gnumach could provide support for that, because I suspect it is a mechanism to hide the vsynch complexity to api clients by swapping their buffers on their behalf

<azert>you cannot do that with memcpy

<azert>Since memcpy will take time

<damo22>ok

<damo22>i will ignore it for now

<solid_black>hi

<sneek>solid_black, you have 1 message!

<sneek>solid_black, azert says: I understand that about owl, but can you please explain to me what does it really needs Cocoa/GNUstep for? Maybe the Hurd could implement just that part instead of going the full drm way

<solid_black>azert: Owl is fundamentally built around Cocoa, it's a Cocoa app and a Wayland compositor at the same time

<solid_black>you can say that it uses Cocoa as a backend, instead of DRM

<solid_black>it was initially developed to provide an XQuartz-like compatibility layer for Wayland on OS X

<solid_black>and later I ported it to GNU/Hurd using GNUstep in place of Apple's Cocoa just for fun

<youpi>on unrelated news, I got the debian gccgo package built on x86_64-gnu, and bootstrapped gnat too thanks to flavio's scripts, now building the debian package

<solid_black>\o/

<etno>🎉

<damo22>only 60 ioctls to implement :\

<gnu_srs>damo22: Did you look at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=909436 and

<gnu_srs> https://gitlab.freedesktop.org/mesa/drm/-/issues/24?

<solid_black>I don't, uh, think that filing issues against upstream projects that they FTBFS on GNU/Hurd is appropriate

<solid_black>it's up to us to make sure that they do

<damo22>its good to have libdrm compiling on hurd, but we need to port the driver before it will do anything

<damo22>gnu_srs: i am working on a simple framebuffer that will reuse whatever grub finds as graphical display mode and reuse that as a drm driver

<damo22>basically i need to implement ~60 drm ioctls as a hurd server

<damo22>most of them dont need to do much

<damo22>but if i write it nicely, we can extend the support to all the other cards that drm works on in linux

<damo22>although thats a much bigger job

<gnu_srs>damo22: With the patches in #909436 if I remember right a lot of software rendering was possible to enable.

<gnu_srs>solid_black: ?

<damo22>its possible that libdrm not being available at all blocks the swrast driver from working at all

<damo22>so that would be nice to fix, but my work is still valuable to enable grub framebuffer to be reused

<damo22>basically, i am adding the server part of drm, but for a dummy device

<azert>damo22: your work is very useful even just to provide a stub for those 60 ioctls

<azert>The first driver you could implement, for instance, is a null driver that sends everything to /dev/null

<azert>The second one would be a dummy frame buffer one that you are planning

<azert>The third could be something that streams everything over the network

<azert>Still dummy

<damo22>youpi: where do i put all the structs for this? https://git.zammit.org/hurd-sv.git/commit/?h=drm-server

<damo22>it looks like i might need to duplicate them in ioctl_types.h and defs

<youpi>yes

<damo22>bedtime

<janneke>do we have any failure/success reports for thinkpad x230 (32 bit hurd version)?

<solid_black>(hi janneke!)

<janneke>when trying to boot a fresh guix install, it fails with

<janneke>[ 1.0200050] vendor 8086 product 1e03 (SATA mass storage, AHCI 1.0, revision 0x04 at pci0 dev 31 function 2 not configured

<janneke>[ 1.1100050] chacha: Portable C ChaCha

<janneke>ext2fs: part:1:device:wd0: No such device or address

<janneke>the same disk boots fine when i plug it into my x60

<janneke>hey solid_black

<etno>janneke: let me attempt the easy one: is your disk controller in legacy mode ?

<janneke>etno: yes...would it have passed through grub if it wasn't in legacy?

<etno>Yes, it would work with grub

<janneke>etno: the disk has only one partition, doesn't non-legacy need a boot partition?

<janneke>the bios says: both, legacy first

<youpi>it doesn't have to be separate

<youpi>ah, you mean efi

<youpi>it needs an efi partition, yes

<youpi>but if you boot in bios mode, whatever the mode of the disk controller, a single partition is completely fine

<youpi>(boot mode != disk controller mode)

<janneke>ah!

<janneke>ACTION goes to look in bios again

<janneke>my SATA Controller mode was is "AHCI", setting to "Compatibility"

<etno>👍

<janneke>hmm that slightly changes rumpdisk(?)s messages to

<janneke>[ 1.0200050] vendor 8086 product 1e01 (IDE mass storage, interface 0x8a, revision 0x04 at pci0 dev 31 function 2 not configured

<janneke>[ 1.0200050] vendor 8086 product 1e09 (IDE mass storage, interface 0x85, revision 0x04 at pci0 dev 31 function 5 not configured

<janneke>but still

<janneke>ext2fs: part:1:device:wd0: No such device or address

<youpi>yup, the gnat-13 package does build

<youpi>damo22: was thinking: probably we're supposed to cope with fb_type being either RGB or INDEXED

<youpi>also, in the rgb case, the field_position and mask_size fields should be used instead of hardcoding a 8/8/8

<gnucode>well I got me a severed HEAD. :) I should probably read through the git tutorial at least once. And or read the manual. :)

<sneek>Welcome back gnucode, you have 1 message!

<sneek>gnucode, p4r4D0xum says: We're talking about manufacturing homebrewed chips - z2 made in 2021 has 12x100=1200 transistors, that's 1/4 of intel 4004

<gnucode>sneek later tell p4r4D0xum I've not heard of z2 before! 1200 transistors seems quite a lot for being made at home! also you have the most "heavy metal rock band" sounding irc nick I've ever heard!

<sneek>Will do.

IRC channel logs

2024-10-30.log