IRC channel logs

<azert>I was thinking about the _HURD_HANDLE_IOCTL mechanism. Does it allows to hook up ioctl in a library? i.e. could you start implementing everything without any server or rpc, and then move the bits to a server once there is a real need

<azert>What is the point of implementing about 200 rpc if they all return zero? You could just hook them up with a function that returns zero

<azert>You’ll likely need a few rpc, but you could start implementing just those

<damo22>azert: maybe i should implement drm server inside libdrm

<damo22>then there are no memory objects to be created between a server and a client that serves no purpose

<damo22>the reason to implement all the rpcs is because if we want to use real gpu hardware we can hook them up to real implementations

<anatoly>ZhaoM: i think the first link (with sid) is a symlink to the iso file under the iso-cd directory. If you ahvhe both files downloaded just compare them.

<azert>damo22: if you can implement drm totally client side then go for it, but maybe you cannot since if there are multiple buffers there should still be a central authority blitting them coherently in the single frame buffer

<azert>but yeah that would be the first thing to try out

<azert>damo22: the correct place to hook the ioctls isn’t libdrm, it is glibc.

<azert>You want it downstream of libdrm for full api emulation

<azert>and in any case it is glibc that takes care of the ioctl logic on the Hurd

<damo22>it doesnt have to be ioctl()

<damo22>but i dont know how to solve the memory pointers issue

<damo22>linux creates userland accessible virtual addresses

<damo22>but mach cannot

<solid_black>hi

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

<sneek>solid_black, janneke says: yes, that's the fix; thanks. good to know it's upstreamed and better to take it from there.

<solid_black>sneek: botsnack

<sneek>:)

<librehawk>When are we getting STABLE BARE METAL?

<damo22>librehawk: if something is not working, that would be a bug and should be reported

<azert>damo22: I think you are making confusion bringing up together two distinct issues

<azert>The first one is Linux compatibility. You really want that and for doing that you need to emulate the Linux api, exactly

<azert>Turn up this is possible by adding hooks to going as youpi pointed out

<azert>The second thing is the Hurd rpc api that needs to deal with the fact that you cannot just pass pointers around and expect them to work

<azert>This second issue would be solved if you could implement the whole drm client side, in the glibc hooks for the ioctl. Because it makes sense to send pointers to glibc

<azert>Since this is likely to be impossible, then you will need to define an rpc api only for the things that are necessary

<azert>This doesn’t even need to be public, at least at the beginning

<azert>And possibly you will have to share memory around, you do that using memory objects

<azert>Memory objects are handles to memory regions, it is actually quite straight forward

<azert>You could use files and mmap MAP_SHARED

<solid_black>memory objects are anything but straightforward

<solid_black>(but yes we could expose device memory with them, or something)

<solid_black>other than damo's stub, did anyone actually figure out how to actually put things on the display the modern/DRM way? (i.e. not via framebuffers)

<janneke>ACTION just built a 64bit hurd image on guix (hurd-team branch)

<janneke>it doesn't boot yet though :)

<etno>solid_black: never did it myself, but I would start with https://github.com/ascent12/drm_doc/blob/master/02_modesetting/src/main.c

<etno>Well, it's actually framebuffer, but obtained via DRM

<solid_black>yes, so that too stops at a "dump buffer"

<azert>solid_black: I found this hello world software https://github.com/girish2k44/drmmodeset

<azert>Anything more advanced would probably use EGL, such as https://gitlab.freedesktop.org/mesa/kmscube

<solid_black>ok; but how does it actually work? how is scanout implemented kernel-side?

<solid_black>is it just lots and lots of drivers for specific hardware? (GPUs? connectors?)

<solid_black>or is there some common framework that handles a lot of the details?

<solid_black>actually the latter is almost certainly true

<azert>There is a tons of helper functions

<azert>Kernel side

<azert>I understood that the plan is not to port drm, but to emulate it

<solid_black>I don't think we exactly have a plan yet

<solid_black>Damien's trying to make a drm stub that exposes the drm api on top of the existing fb

<solid_black>I'm asking questions, trying to get some understanding of how things fit together on freedesktop/linux

<azert>I think yours are excellent questions

<azert>Let’s discuss this sharing the user space pointer issue. It means that the only place you could implement Linux drm is inside gnumach

<azert>And since that sucks, it’s not gonna happen

<solid_black>what's the actual issue? the thing about drm_get_version ioctl returning some strings?

<azert>No, the thing about the whole api designed around passing user space pointers to kernel space, if I understood it correctly

<solid_black>could you point me to some examples? -- not of generic drm api usage, but of the cases where a pointer is being passed in a way that you think is problematic

<solid_black>maybe we should pick some simple device (GPU?) that Linux has a driver for, and see what it would take to implement drm APIs for it properly for the Hurd

<solid_black>like what kinds of abstractions we'd need

<azert>Why not starting with the dummy framebuffer? simpledrm

<azert>This have the advantage that we know what they are abpit

<solid_black>isn't that what Damien is doing?

<azert>Yes, but do you have another kind of gpu?

<azert>Something else in mind?

<solid_black>I don't fully understand where the boundaries between GPUs and framebuffers and displays lie

<solid_black>is a framebuffer just a buffer in CPU memory that *something* scans out of?

<solid_black>there are all these abstractions of CRTCs, encoders, and connectors

<solid_black>connectors seem to actually represent physical connectors, as in HDMI?

<azert>I guess there are buffers in cpu memory and buffers in gpu memory, as well as buffers in gpu memory that are cached on the cpu at different level of coherency

<solid_black>sure, so what needs to happen for a bitmap in the buffer to get displayed on my screen?

<solid_black>do I need a GPU to encode it somehow?

<solid_black>does a driver drive the GPU? the HDMI? both? are thse two spearate drivers?

<azert>I think hdmi is just a cable

<azert> https://www.kernel.org/doc/html/v4.13/gpu/drm-kms.html Explains it a bit

<azert>I think a crtc is a pipeline, that is a software

<azert>Encoders and connectors are what make it up

<azert>Planes are the buffers, that is the data fed in the pipeline

<gnu_srs1>/hurd/pfinet --interface=/dev/eth0 --address=10.0.2.15 --netmask=255.255.255.0 --gateway=10.0.2.2 -6 /servers/socket/26

<gnu_srs1>/hurd/pfinet: device_open on /dev/eth0: (ipc/mig) bad request message

<gnu_srs1>any ideas?

<gnu_srs1>and su; su: module is unknown

<solid_black> /dev/eth0 is not set up properly?

<gnu_srs1>And ifup /dev/eth0

<gnu_srs1>fsysopts: /servers/socket/2: -i /dev/eth0: (ipc mig) server died

<gnu_srs1>Error getting hardware address for "dev/eth0": No such device

<gnu_srs1>Is hurd creating /dev/eth0?

<solid_black>showtrans /dev/eth0

<gnu_srs1>/hurd/devnode -M /dev/netdde eth0

<solid_black>okay; is /dev/netdde up/working?

<gnu_srs1>netdde is probably no longer installed. bbl

<gnu_srs1>tks!

<gnu_srs1>Internet works :)

<gnu_srs1>but openssh not :(

<gnu_srs1>From the hurd box: ssh 10.0.2.2

<gnu_srs1>OpenSSL version mismatch. Built against 30000050, you have 30100010

<gnucode>sneek later tell librehawk I use the Hurd on bare metal on a T43 with 1.5 GB of RAM. It works really well. crashes once or twice a week. Sometimes lots in one day, if I am trying to abuse it.

<sneek>Will do.

<ThinkT510> https://fosdem.microkernel.info/

IRC channel logs

2024-11-08.log