IRC channel logs

<nexussfan>how do I get libinput on debian gnu/hurd? i'm trying to compile xlibre for hurd and everything compiles except the input stuff, because of a missing build-dep on libinput

<youpi>it'd probably need to get some fixes to be able to build on a non-linux system

<nexussfan>xlibre? or libinput?

<youpi>both, actually

<nexussfan>xlibre is fork of xorg, and they have debian source pkgs based on the xorg ones.

<youpi>(as I guess nobody tried to build xlibre on GNU/Hurd, so it most probably doesn't build)

<nexussfan>everything builds except x libinput input

<nexussfan>which is because it has a libinput dependency

<nexussfan>which for some reason you can't install on hurd

<youpi>see https://buildd.debian.org/libinput

<youpi>i.e. mtdev is missing

<youpi>probably it can be worked around by disabling multi-touch

<youpi>but still most probably libinput needs some linuxism fixes

<nexussfan>xorg has same dependency for some package, and there is a hurd bin but you can't get the build deps from hurd

<nexussfan>hmm, for xserver-xorg-input-libinput on buildd it's disabled for hurd

<nexussfan>so probably the maintainers have to manually compile it (probably from a non-hurd machine)

<youpi>better just work with upstream to fix the hurd build

<youpi>building on a non-hurd machine won't produce a hurd-usable library anyway

<nexussfan>that's true, but then how did xorg get on hurd with these dependency issues?

<youpi>it just disables it

<nexussfan>i'll see if i can run xlibre without input first

<damo22>why not focus on wayland?

<damo22>X is dead

<nexussfan>well, that's the whole point of the fork

<damo22>people who wrote X want it to die because they have a better alternative now

<damo22>the fork is there because obviously not everyone agrees

<nexussfan>same thing people said about systemd

<damo22>but wayland isnt a system that eats all the unix tools

<damo22>its a protocol for doing graphics and audio (?) properly

<youpi>(not audio)

<nexussfan>wayland doesn't handle audio, afaik

<youpi>(pipewire is that)

<nexussfan>wayland adds challenges of it's own,

<damo22>ok but it can combine audio with the streams?

<youpi>I don't think it does much about audio

<nexussfan>such as how different compositors have are incompatible

<damo22>ok

<nexussfan>and I haven't heard much about wayland on non-linux kernel

<damo22>if you dont put the compositor in charge of the screen you have a problem

<damo22>thats what wayland can solve

<nexussfan>portals as well are also wayland issue

<nexussfan>:O xlibre started!

<nexussfan>no input as expected

<nexussfan>but it actually worked :D

<youpi>you're probably just missing the kbd and mouse drivers

<youpi>see them in Xorg

<nexussfan>yeah, i purposefully disabled them because i couldn't get them to compile (yet)

<youpi>xf86-input-keyboard/ and xf86-input-mouse/

<youpi>should be working fine

<youpi>(they do in Xorg)

<damo22>we need drm server

<nexussfan>yeah, but as i mentioned before the libinput (which is a build-dep) doesn't exist for hurd

<damo22>and kernel mode setting is a dependency

<youpi>is it really a dependency for the kbd and mouse drivers?

<youpi>they aren't on xorg

<youpi>see the xserver-xorg-input-mouse and xserver-xorg-input-keyboard debian packages

<nexussfan>yes but xorg != xlibre

<youpi>yes but xlibre is a fork

<nexussfan>oh wait

<damo22>you can borrow the ideas from xorg of how they ported it

<nexussfan>xlibre doesn't have kbd and mouse deb pkgs

<youpi>then it's up to it to keep the existing compatibility code...

<nexussfan>better make those pkgs real quick

<damo22>nobody seems to be interested in diving into driver code except me

<damo22>what is the use of a Xorg clone with no gfx drivers?

<damo22>what are we going to do when we have ported drm with kms but the hardware requires firmware blobs to init the display?

<damo22>are we going to have a policy that says no firmware blobs?

<youpi>that question is up to distributions

<nexussfan>^, but you should also put in policies to make sure that it doesn't end up like openbsd with proprietary blobs in the source

<youpi>they don't need to be in the hurd source

<damo22>base64 encoded blobs in source are a horrible practice

<youpi>that's one of the whole ponits of the hurd, to be flexible

<nexussfan>what i mean is that make the free parts and non-free parts seperated, having proprietary and libre in the same codebase is not good

<damo22>the drm server will be linked to a library that loads firmware blobs

<damo22>without the blobs present, its likely the displays wont work

<damo22>so you can still include the drm server and library in the hurd source, but only redistribute the blobs when your distro says you can

<nexussfan>damo22: that's good

<damo22>no i dont think its that good

<damo22>i hate binary blobs

<nexussfan>as long as the proprietary and libre are seperated then that's ok

<nexussfan>also

<nexussfan>mouse works now on xlibre

<nexussfan>but keyboard is still broken

<nexussfan>uploaded a tutorial on how to get xlibre for hurd, https://github.com/NexusSfan/xlibre-hurd

<damo22>nexussfan: why not create something you can upstream instead of a github readme

<damo22>seems like xlibre already compiles with dpkg

<damo22>if its just the mouse and keybd packages that are missing, file that as a merge request with upstream?

<damo22>then the instructions can be, youpi please dpkg-buildpackage xlibre

<nexussfan>damo22: It's a guide on how to compile the debian packages for xlibre on hurd, and the mouse/kbd packages are missing from upstream xlibre, so i made my own half-working versions

<nexussfan>this is very uncomplete. just a starting point for a real port

<nexussfan>*a guide with scripts

<damo22>we dont need separate guides for single packages, for the amount of work you already did you could have filed a merge request upstream and have it fixed and included in debian hurd

<nexussfan>the tool they use for building debian packages (ruby+thor and some more deps) doesn't work on hurd, so that's why i had to make my own small building systems, since there are multiple packages

<nexussfan>xlibre is not a single package, just like how xorg is not a single package

<nexussfan>there's a similar thing for bsd, it's also a seperate repo with some scripts to build the xlibre afaik

<damo22>look at the xlibre debian/ directory and figure out how to include the mouse and keybd packages

<damo22>then you can upstream a working port

<nexussfan>well yes, i could just use the ones from xorg, but afaik the kbd and mouse packages are modified in xlibre so that would need a new package

<damo22>it shouldnt be that difficult considering the scripts you already wrote

<nexussfan>Well currently i am just copying xorg's drivers for that

<nexussfan>but repackaging it under the name of xlibre instead of xorg so it "works"

<azert>I hope that x11 doesn’t die, I’m afraid that wayland provides less reasons to its survival then x11

<azert>there is a bunch of old software that is really high quality and will never be ported to waylands

<azert>I’m sure distros will start to replace x11 with xlibre

<kilobug>most "normal" software can run with xwayland, it's "special" software like window managers or usecases relying on X networking that will break... to me the main issue with wayland is having to relearn all the tools and config (xrandr, xmodmap, ...) and change window managers, I really don't want to do that for no real reason

<kilobug>but xlibre has its hosts of issues, the main developer is a nazi apologist that has been kicked from xorg for the low quality of his work... not a project I would touch even with gloves

<azert>also xwayland is x11..

<kilobug>(and xlibre is mainly a one-person project, due to the toxicity of that person, very few want to work with him)

<azert>I noticed that in the logs, and also it’s the kind of developer that keep changing stuff for no reason

<azert>more than four commits a day, and most of them are very dull

<azert>I’m 100% sure he is breaking stuff

<azert>kilobug: I know that I can use old stuff on xwayland. I’m worried that Wayland might die faster than x11

<azert>because of the way the Americans work nowadays, they might decide to stop working on x and start working on y feom

<azert>from day one to two

<azert>they are totally fine in dropping billions into the void

<azert>I wouldn’t be surprised if 75% of Wayland team is nocoder

<azert>whole team of people doing nothing getting fired every day and making the news

<azert>banks financing fake people at 0% interest rate

<azert>I would t be surprised if Wayland dies then we need a working x11

<azert>maybe xlibre is part of the conspiracy in the sense that you need a freak breaking working code

<azert>I’m pretty sure that new compilers breaking old code are part of a conspiracy

<azert>at least C compilers

<damo22>theres no conspiracy, just people getting paid to work on stuff and they probably have to make commits to prove their worth

<kilobug>conspiracies do occasionally exist, but they are very rare, very often something that looks like a conspiracy at a glance is more the result of people individually following the incentive they have in a given system

<damo22>wayland isnt a program, its a protocol

<damo22>if free software community agrees on a common protocol for doing compositing and window management (such as wayland), we can build any desktop system that interoperates with all the guis. the screen needs to be controlled by the compositor and that design is encapsulated in wayland protocol, but the design of X never worked that way which is why you have graphic drivers baked into X and in the kernel as well

<damo22>in X, the compositor is another X client

<kilobug>I never really got the point of a "compositor", I don't use any in X, a window manager yes, but those are different

<Arsen>you do use a compositor lol

<azert>damo22: x11 is a protocol too, it is just that there is only one implementation

<azert>Wayland is not very different

<Arsen>X11 does composition out of the box, obviously. compositing *is* putting together multiple pictures as one

<Arsen>wrt the "wayland team", it is the same as the "X team"

<damo22>for example if you have 4 windows that overlap and only one is partially visible on the screen because it is too big to fit, you want the compositor to discard all the pixel rendering for things that are not visible on the screen

<azert>the gpu does that

<damo22>not draw it all, and then clip to the screen

<azert>what a protocol like x11 and Wayland doesn’t do is writing drivers

<damo22>or layer them on top of each other and then clip to fit

<kilobug>my windows rarely overlap since I use tiling, but sure, occassionally that can happen... I guess X handles basic compositing internally, and you only need a specific compositor if you want fancy stuff like tansparency which are useless to me

<Arsen>the term "compositor" also can mean different things

<Arsen>it's used for wayland display servers for instance

<Arsen>I don't know what the reason for that is, but it isn't the same work as xcompmgr is doing

<damo22>azert: X has graphic drivers built into itself

<Arsen>not for a very long time now

<azert>same for wayland/drm

<Arsen>for at least 10 years X hasn't been driving stuff and has been using linux apis (KMS, DRM, GBM, ...) for graphical devices on linux

<azert>it’s the same people writing the p and the drivers

<kilobug>yeah, might be a vocabulary issue, it's the xcompmgr-like compositing that I don't see the point of

<azert>while all other os were bringing drivers out of kernel space, Linux was doing the opposite

<Arsen>hm, did other kernels do that?

<Arsen>(also, fwiw, the linux APIs can be implemented in userspace, managarm does so for instance)

<kilobug>linux graphical drivers are hybrid, a small part (modesettings and memory management) is in kernel space, but the bulk of them is in userspace (ie, mesa)

<Arsen>that's also true yeah

<Arsen>but amdgpus kernel component is quite large for instance

<damo22>mesa is in userspace yes

<damo22>we should implement kms and drm in hurd as a server

<kilobug>reclocking / power management is in kernelspace too, and from what I've understood that part is quite complicated yeah

<damo22>then libdrm can call our hurd api

<damo22>and the rest is plug n play

<Arsen>IIRC managarm runs unmodified weston currently and someone is porting plasma 6

<damo22>i wonder how many of the ~200 ioctls are required for drm to work

<azert>what is managram approach api wise?

<azert>how did they implement the ioctl?

<damo22>if libdrm asks for an accelerated buffer, there are card specific implmentations of all the ioctls

<azert>damo22: if I recall correctly the main issue was that some ioctl required virtual address as input values

<damo22>we basically need the linux gpu/drm folder ported to hurd and kms as well, its a huge subsystem

<azert>that is of course a no go in microkernels os

<azert>but what about the virtual addresses in kernel apis?

<damo22>yes, i dont know how to handle virtual addresses in kernel apis

<azert>Instead of handles/files like things are normally so e

<Arsen> 11:03:07 <azert> how did they implement the ioctl?

<Arsen>they work the same as in linux from the perspective of the program

<Arsen> 11:06:39 <azert> that is of course a no go in microkernels os

<Arsen>well not necessarily

<azert>damo22: it’s just impossible, requires an api redesign

<azert>userspace servers cannot resolve virtual addresses of other processes

<Arsen>an ioctl taking a VA is no different to sendto() for instance

<Arsen>yeah, of course

<Arsen>IIRC we ran into that issue eat some point (but I haven't touched the graphics stuff really), if we did it'd be solved in here: https://github.com/managarm/mlibc/blob/master/sysdeps/managarm/generic/drm.cpp

<Arsen>the devs who actually did do that would prob answer if asked in #managarm-dev or #managarm

<azert>possibly if we pass the client task port to the drm server he can resolve the virtual addresses

<azert>but that requires privileges and sucks

<Arsen>not sure how mach works so I don't know what that means ;^)

<Arsen>I think we just resolve the ioctl in libc and send from/receive into the relevant VAs

<azert>Yes, we discussed implementing drm in glibc

<azert>that’s the right place to emulate unix

<Arsen>managarm is in the easier position of not having to coordinate about libc modifications with other people so we essentially have a rolling libc release for managarm, not sure how doable that is for hurd (especially when debian gets involved)

<azert>we would need to teach glibc all drm ioctl so that it can do the right translation in send or receive

<Arsen>you might find it easier to add functionality to glibc-hurd to "register" ioctl handlers

<Arsen>then DRM programs could load the ioctl handlers separately

<damo22>we are on upstream glibc

<Arsen>I know

<azert>glibc allows ioctls to be plugged I

<azert>plugged in

<Arsen>(btw, I was also somewhat interested in writing a glibc port for managarm, is there any porting documentation?)

<damo22>you-pi already suggested how to plug ioctls for drm into glibc

<damo22>we just bypass the normal ioctl server

<damo22>and put our own definitions in or something

<Arsen>ah well that's solved then

<Arsen>(sorry, I don't follow hurd development very closely)

<azert>yes that’s the way to solve this

<damo22>Arsen: no that is good to discuss thanks

<Arsen>:)

<damo22>i didnt quite understand how that solves it

<Arsen>last time I tried brute-forcing that managarm port btw, I ran into the fact that the thread libraries aren't portable

<Arsen>s/managarm/managarm-glibc/

<Arsen>I didn't quite figure out what I needed to implement in one before I ran out of time

<damo22>my naive attempt at doing drm server is here https://git.zammit.org/hurd-sv.git/commit/?h=drm-server-ioctl

<damo22>its just stubs for now

<azert>damo22: the way using glibc solves this is that glibc lives in the same address space as the client, as such it can do as much drm ioctl as possible right there. If it needs to modify the shared state in the drm server (can be the console client) it can communicate with that using its own rpcs that don’t involve virtual addresses

<azert>I’d basically start implementing drm by plugging its ioctls in glibc

<azert>short cutting them to functions running in the client address space

<Arsen>thats p much what mlibc does in managarm iiuc

<damo22>theres only a handful of rpcs that require VAs

<azert>damo22: then it’s a design choice either you implement just those in glibc, or most of the api

<damo22>but the question is what does that even mean

<damo22>if the api i call needs to pass in the virtual address of some object

<damo22>that only resolves in the client

<damo22>the server cannot use that right

<azert>Nope, for that you need a function in glibc

<damo22>but the memory associated with gpu cannot live all in glibc

<azert>the memory associated with gpu should probably live in a gpu server

<Arsen>well presumably you can share memory, no?

<damo22>part of the memory actually lives on the card itself

<damo22>but the metadata about accellerated buffers could get large

<azert>You can share memory

<azert>gnumach is great at sharing memory

<Arsen>yeah, so the GPU-owned memory shouldn't pose a real issue

<damo22>if the drm server holds all the buffer objects, maybe the VA can be passed in from the client that resolves to a valid address of an object in the drm server

<azert>Then it’s not a va, it’s what is called an handle.

<damo22>yes

<azert>looks different to me

<damo22>like, are we sure the addresses being passed in need to resolve in the client at all?

<damo22>my loose understanding was that lots of handles are passed around

<azert>I don’t know the answer to this question

<azert>what I think, sometimes, is that the Hurd could have a great native gpu api considering how advanced is gnumach in the memory sharing area

<damo22>thats what drm is

<damo22>but we are moving it from kernel to userspace

<azert>yes but Linux is a traditional unix kernel developed for x86 with drm plugged in

<azert>while gnumach is a microkernel specifically developed for heterogeneous architectures

<damo22>sure we could invent a new api for everything

<damo22>it would be a better design

<damo22>but maybe we want something that interoperates with existing free software

<azert>damo22: but we clearly cannot implement drm since it’s too big for anyone of us

<damo22>maybe we can implement a subset of drm properly

<azert>Yes

<azert>starting from a subset of possible have a chance to work

<azert>if possible

<azert>What about starting from kms? Can we implement kms in the console client ?

<azert>can x11 use that?

<damo22>yes i think kms is a good starting point because its standalone

<damo22>once you have kms you have a screen and crtc

<damo22>and possibly a fb

<damo22>i think we could write a kms server that exposes a fb and then have the console client fire up the screen in maximum resolution supported by the monitor(s)

<damo22>and use that

<damo22>but it wont run mesa without drm

<damo22>kms and drm are well documented in linux

<damo22> https://www.kernel.org/doc/html/latest/gpu/drm-kms.html

<Arsen>so I don't wanna bore with off-topic stuff, but hopefully you'd know the answer to this question (and the glibc channels were empty when I last tried, though that was a while ago):

<Arsen> 11:16:16 <Arsen> (btw, I was also somewhat interested in writing a glibc port for managarm, is there any porting documentation?)

<Arsen>last time, the wall I ran into was that it appeared like the threading libraries aren't portable at all and need full reimplementation each time

<azert>Arsen: I think glibc is really portable. At some point it was ported to the FreeBSD kernel

<azert>I would check that one

<Arsen>oh true, I forgot about that port

<Arsen>but it's quite old, I figured hurd was more recently updated and so people here would have a fresh understanding of how that works

<azert>damo22: that kind of documentation hits me. It looks like a part (the definition of the primitives) is missing

<azert>Arsen I think your understanding about the threading library is correct

<azert>if you reimplement the Linux kernel api then it will be more portable for you

<azert>but the Hurd is quite different in that area

<azert>I wouldn’t call it “not portable” but tied to the kernel implementation

<azert>it is surely very portable

<Arsen>;) for something like a libc, "able to be untied from a kernel implementation" is usually what portable means

<Arsen>hence my usage

<Arsen>my initial attempt was to try to wrangle NPTL (the Linux one) by adding appropriate sysdeps and definitions, but that turned out to be a huge effort

<Arsen>HTL is only about 2.2kLOC, so perhaps just reimplementing it is good enough?

<azert70>btw, maybe managarm can use the Hurd threading library

<Arsen>it isn't mach-based so it is quite different, but I admit I didn't look at HTL code so I can't discount the possibility

<Arsen>ah, is it only 2.2kLOC because it delegates to a separate implementation somewhere else?

<azert70>maybe check gnumach first?

<azert70>the kernel side is small

<azert70>no the implementation is all in the glibc repo

<Arsen>ah I found it, it's in sysdeps/mach/htl

<Arsen>hm, perhaps then sysdeps/managarm/htl could exist

<azert70>are you going to port the Hurd to managaem?

<azert70>you are on a slippery slope

<Arsen>no, my intention was to port glibc to managarm

<azert70>that’s what I call a slippery slope to end up porting the whole hurd

<Arsen>ah ;)

<Arsen>hm, fwiw, the servers managarm already has are fairly complete

<Arsen>so maybe I won't slip that fall

<Arsen>s/fall/far/

<Arsen>(mlibc is also quite large at this point, but nowhere near complete, plus I don't like the expat license)

<azert70>Arsen: is managarm self hosting?

<Arsen>no, still missing a few things (we weren't picky with dependencies in the build process)

<azert>Arsen: who did the drm part in managram? Do you know the hacker that coded that?

<azert>it looks surprisingly complete

<azert>does no92 hangs out on libera chat?

<jab>sneek later tell nexussfan I would love to run Xlibre on the Hurd. However, I think some debian developers may not allow it. https://rumble.com/v6ztoh2-debian-xlibre-is-not-allowed-devs-are-nazis.html?e9s=src_v1_cbl%2Csrc_v1_ucp_a https://lists.debian.org/debian-project/2025/10/msg00017.html Samuel seemed to be ok with it, hopefully you get it working.

<sneek>Okay.

<youpi>jab: what's said in that video is extremely amplified

<youpi>notably jbicha's part

<youpi>making jbicha like a serial criminal, which he isn't

<youpi>he is not blank indeed

<youpi>but that doesn't make a criminal for eterity...

<youpi>eternity*

<youpi>and way other kind of such bs which is just over-over-amplified pieces

<youpi>(about outreachy etc.)

<youpi>I'll just stop watching this

<youpi>it's just the same bogus argumemnts repeated over and over, from Pocock

<Arsen>azert: everyone is available on irc

<Arsen>try #managarm-dev

<Arsen>and there isn't really a single responsible person for it but afaik Leo has been working on it most lately

<Arsen>(no92)

<Arsen>there's other managarm channels too, discoverable via Alis

<jab>youpi: I wasn't trying to stir up drama. I'm genuinely concerned that Debian won't let Xlibre in their package repos.

<jab>I personally feel that Xlibre is probably better to use (if we are stuck on X).

<Arsen>I doubt it

<Arsen>IMO it's a grift by a reactionary that showed themselves as incompetent

IRC channel logs

2025-10-20.log