IRC channel logs

<damo22>im curious if you think porting the ioctl interface is a good idea or not, or should we focus on implementing kms subsystem first and then transplant the drm driver as is?

<youpi>I don't know how kms/drm/wayland interact

<damo22>ok

<youpi>I just have a vague idea, so can't really have an opinion

<damo22>i think kms is the lowest level to the hardware and is pretty standalone, it is responsible for setting the modelines

<damo22>setting up crtcs and encoders/connectors

<damo22>reading the EDID from the monitor

<azert>solid_black: I think your answer to damo22 is naive, there is no backend for libdrm, it is all based on the ioctl api

<azert>if you change that, you need to reimplement libdrm

<azert>maybe the Hurd/glibc needs to support complex ioctl with nested data types. Since Linux emulation is the goal

<azert>the mig matchmaker grammar can be expanded for that

<azert>the alternative would be to not use drm at all, but implement a drm-like graphical accelleration subsystem.

<crupest>azert: Then we have to reimplement mesa. 😂

<crupest>This a super long story anyway.

<damo22>i replied on the list, crupest your idea is good

<damo22>since drmIoctl() has the ioctl number, we can use that to determine which RPC to call

<crupest>damo22: I see that.

<crupest>Hope it is easy.

<crupest>Once my company asked me to migrate new Intel GPU to an old Linux version. And after our group's disscution, we decide to persvade our boss that it is impossible before we give products to customer.

<crupest>The drm framework leeps change. Very fluently.

<damo22>yes i think we should base our code on latest linux

<crupest>You can compare the old version and the new verison. Most of them are different. But I think PCI, Network should be stabler. But I was not working on them.

<damo22>otherwise we have no chance to migrate newer cards

<crupest>damo22: No need to hurry on that. I think a software OpenGL means a lot already.

<crupest>I'm trying reading Hurd docs and codes hard recently. It is much harder than contributing to a high-level App.

<crupest>Hope I can write some codes that indeed makes sense. Rather than only TALK.

<damo22>+S_drm_get_sarea_ctx (

<damo22>+ drm_t drm,

<damo22>+ uint32_t ctx_id, uint64_t *handle) does this make sense as an OUT parameter? the handle will be set by the drm server but will it be accessible in the client?

<damo22>the server implementation will do something like *handle = value;

<damo22>although i have no idea what the value means in the context of the client

<damo22>i guess as long as the value required is just a single uint64_t

<youpi>that won't work as it is

<youpi>since when writing *handle, you need it to be a virtual address

<youpi>which the server can't fabric

<damo22>how does that work in linux?

<youpi>the kernel can fabric virtual addresses

<damo22>:|

<damo22>so anything that generates (__user) pointers will be broken

<youpi>about complex ioctls, note that glibc implements ioctl handlers

<youpi>see _hurd_lookup_ioctl_handler

<youpi>to handle it differently than the usual encoding with IOT

<youpi>then you can have a different RPC protocol, to e.g. make the server return a memory object or such that can be mapped on the client side

<youpi>(see e.g. hurd/hurdioctl.c

<youpi>it's used by glibc for fully-client-side ioctls, but it can also be used for managing arbitrary requests

<damo22># define __user __attribute__((noderef, address_space(__user)))

<damo22>found that in linux kernel

<youpi>it's just an annotation for the sparse static-analysis checker

<youpi>it doesn't actually have any semantic while compiling C

<azert>that’s the thing, I think Mach was _designed_ for the kind of memory sharing and caching that drm does provide, and probably the drm Hurd api should be defined around memory objects and extensions to that concept

<janneke>in what gcc version was 64bit support for hurd added, or which version should i best use?

<youpi>that's memory objects, yes

<youpi>janneke: I don't remember exactly, but gcc-14 has it apparently

<janneke>youpi: right, okay -- using 14.2 now

<crupest>janneke: I'm running a 64bit one on VirtualBox. From debian provided image. And works well.

<janneke>it's apparent new strictness seems not to be handled by all softwares yet so i wondered if downgroading would be smarter atm

<janneke>crupest: nice

<crupest> https://cdimage.debian.org/cdimage/ports/latest/hurd-amd64/

<crupest>I download from this.

<janneke>ACTION works on 64bit support for guix

<crupest>But I only run console mode.

<crupest>I haven't try X

<youpi>mach console, even

<youpi>the hurd console is still buggy, see todo-list

<damo22>janneke: i have problems with AHCI that seems similar to you but i run 32 bit on x230

<crupest>youpi: Actually I use a ssh.

<crupest>Typing directly in VirtualBox is very inconvenient.

<janneke>damo22: ah, my problem was also on 32bit

<janneke>(i haven't enabled the ahci server, because that didn't work before)

<youpi>crupest: without hurd console, you can't have X, since it provides access to keyboard & mouse to X

<janneke>damo22: is ahci required now?

<crupest>youpi: Virtual Box can capture your mouse and keyboard to VM, but if you want to jump out, you need to press special key. Other systems with X just get VM guest additions, so the mouse and keyboard can move in and out VM directly.

<crupest>But actually I think it's not about X, but special drivers for VM. Without those drivers, they behave just like Hurd.

<youpi>that'd need implementing those vm guest additions in hurd

<crupest>youpi: Sorry I might misunderstand you. Your are right.

<crupest>youpi: Yes.

<crupest>The problem is not I can't use mouse and keyboard in VM. It's just without guest additions. It is inconvenient. And ssh is much better.

<damo22>janneke: i think you can use gnumach disk driver but it has limitations

<damo22>janneke: i cant boot hurd on x230 yet

<damo22>haha, microsoft.com has a linux subdomain with emails on it

<crupest>damo22: 🤣

<janneke>damo22: i'm using rumpdisk, just not the ahci service

<anatoly>interesting, why X uses hurd console for keyboard and mouse? Assuming it's because nothing else does that on hurd?

<anatoly>s/does/provides

<youpi>I guess that was simpler than designing sharing between hurd console and X

<youpi>when implementing switching between the console and X, probably that keyboard/mouse switching could be implemented too, and thus avoid that situation

<anatoly>Are mouse and keyboard devices exposed via /dev/? Or do you I miss something here?

<youpi>anatoly: not currently

<youpi>it's just a mach device

<youpi>and then you have it repeated by the console on /dev/cons/kbd

<azert>solid_black: to reply to your mail, you are right at the end in that’s not what libdrm is doing. What it is doing is to have a function called drmIoctl that just calls ioctl

<azert>youpi gave the good answer to damo22, to use the _HURD_HANDLE_IOCTL mechanism

<azert>that is the solution to this issue, then damo22 can move into more complex issues :)

<gnucode>well that's annoying...

<gnucode>I was updating my hurd machine...It was a big update. I had not updated it in a week or so...

<gnucode>well half way through the update...my mouse stopped moving.

<gnucode>Enter did not do anything on the X terminal

<gnucode>and then the screen turned off. I disabled the X login screen, so the lock screeen did not turn on.

<gnucode>so now I am hoping that the update finishes, and I will do a hard shutoff once again.

<janneke>okay, using the latest gnumach tag is fine, it's the latest hurd tag that doesn't boot

<janneke>ACTION goes on to bisect...

IRC channel logs

2024-11-05.log