IRC channel logs
2024-10-29.log
back to list of logs
<damo22>Xorg +iglx +extension GLX is broken <damo22>LIBGL_ALWAYS_SOFTWARE=true LIBGL_ALWAYS_INDIRECT=true glxinfo -display :0 does not work <damo22>youpi: what is needed to make wayland work on hurd with no X? <damo22>can it use the framebuffer from multiboot? <youpi>what I know is that building wayland currently chokes on missing SFD_CLOEXEC <youpi>possibly it uses signalfd, timerfd and others like that <solid_black>I have the Wayland libraries, clients (sample ones, and full gtk 4), and my own compositor working on the Hurd <solid_black>but IIUC damo22's question is not about libwayland, but rather about what kind of hardware API various Wayland compositors need to display things on the screen <solid_black>the answer to that is "DRM", but I have no knowledge about it other than it's a Linux API set to control displays and GPUs <youpi>there used to be some drm research in the past (like a decade ago), I hadn't looked at it myself <youpi>but the list archives probably know <solid_black>I know the BSDs have ported DRM (as I understand it, the implementation, not just the API) from Linux, so maybe we could too? <youpi>then it'll be a pain to maintain <solid_black>Ludo asked me for signalfd as while back, I think it should be doable; though his actual use case is better solved with ppoll <solid_black>my Wayland port works by just disabling the part of the functionality that uses signalfd and timerfd; fortunately my compositor doesn't use it (it would use Cocoa's native timers if there was a need) <solid_black>"This task will require obtaining a considerable amount of knowledge about the Hurd and Mach (especially things like virtual memory management)" <solid_black>I suppose I have an understanding of the VM subsystem <solid_black>but I lack any understanding of the graphics stack or DRM <damo22>i thought libgbm was the interface for EGL <damo22>using that we could get a display surface <damo22>we dont need libdrm if we arent using the gpu drivers <damo22>im pretty sure we can make a generic framebuffer shim that implements the generic buffer management (gbm) interface, then EGL and everything else like wayland can run on top of that <damo22>it wont be accelerated but it should give a display <solid_black>EGL is a part of / extension of the OpenGL spec that describes the API for you to basically get an OpenGL context to render to a Wayland surface (or elsewhere) <solid_black>but to actually render things, Mesa would need access to a GPU device, and actual kernel API to control it <solid_black>software rendering could work without a GPU device, yes <solid_black>my impression was that DRM does not use the FB abstraction at all, and it's structured entirely differently <damo22>(09:40:56 PM) solid_black: but to actually render things, Mesa would need access to a GPU device, and actual kernel API to control it <<< not quite, if we already have a framebuffer we can write a dummy driver for it <damo22>gbm gives a way to allocate buffer objects that would normally be in GPU memory, but we can do dumb things like mmap cpu memory to store it <solid_black>I have the impression that the framebuffers you're dealing with and the way that the freedesktop/Linux modern graphics stack display things on the screen are very different <damo22>yes but we can add a simple driver that will just write pixels to the screen <solid_black>apparently Linux these days implements the "legacy" fb device on top the the drm abstractions too? <damo22>i dont think we need drm... below EGL is gbm <damo22>drm gives you access to kernel's accelerated gpus <damo22>yes, but we already have that with device(mbinfo) <solid_black>but that is again the legacy framebuffer, and we're talking about porting the modern graphics stack <damo22>i am suggesting we pass the multiboot framebuffer as a dumb gbm surface and swap out the mesa's DRI with our own dumb driver <damo22>it will work on any hardware that has grub framebuffer support <damo22>in the long term we probably want hardware acceleration but i dont have time to do that right now <damo22>it should be trivial to implement <damo22>mesa/src/gbm/main/gbm_backend_abi.h <damo22>it looks like a lot to implement, but most of those calls will be returning constants <damo22>GL usually allocates video memory for buffer objects etc, but we can cheat and use cpu memory instead <damo22>and writing to the screen will be just setting the framebuffer address + offset <azert>The problem is that it probably calls in the Linux vm and timer/clock functions <azert>So perhaps a reimplementation is easier <azert>Do you think you could port your Wayland compositor to the Hurd? What api would be missing? <azert>I mean the Hurd without any X11, just the current Hurd servers <gnu_srs>Unfortunately the patches were not accepted due to #975658. Updated patches were sent: <gnu_srs>After that I gave up, but probably the patch is easily fixed to not affect <gnu_srs>Nothing happened due to a missing MR?? <solid_black>azert: I *have* ported Owl (my Wayland compositor) the the Hurd, years ago <solid_black>but Owl is different from most compositors in that it doesn't actually composite, it lives inside Cocoa <solid_black>so there is still an X server, GNUstep running on top of it, then Owl, then a Wayland app <azert>solid_black: I understand that about owl <azert>but can you explain to me what does it really needs Cocoa and X11 for? <azert>sneek: later tell solid_black 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 <azert>I think that drm is a gigantic mess and the Hurd will never support it