***Server sets mode: +nt
<damo22>irq handling is a mess in gnumach <damo22>it doesnt help that the linux/ code reimplements irq handling and has separate structs for them <damo22>how do i test the userspace RPCs? <damo22>the in-kernel drivers still work but that doesnt exercise the device RPCs <janneke>i pinpointed the sqlite3 "unable to open database file" problem <janneke>(together with using the 20-hurd-locking-style.patch patch) <damo22>does libddekit come with netdde? <damo22>or do i need to build it in hurd first <azeem>janneke: since when is GNU using debbugs? ***AliciaC_ is now known as AliciaC
<damo22>build/libddekit/../../libddekit/memory.c:222: undefined reference to `vm_allocate_contiguous'.... damn forgot to add that <almuhs>youpi: do you know if is possible to copy Xorg's Linux modules in Hurd? <youpi>damo22: apparently netdde is using the static library from the hurd package, I don't know why it doesn't use the shared library, which would allow to just rebuild the hurd package <youpi>azeem: IIRC at ghm 2010 they were talking about it, yes <youpi>damo22: see the mmap implementation, it uses vm_allocate(), precisely. The _contiguous variant is a different beast: by "contiguous" it means physically-contiguous <youpi>almuhs: the Hurd already has the Xorg modules built, at least for those that build. For those that don't, check what made the build to fail. Just copying binaries over from another OS will never "just work" <almuhs>youpi: in my installation, I only have vesa and fbdev. My video card needs intel. fbdev works in Linux, but not in Hurd (I don't know the reason) <youpi>fbdev is for using the linux fb interface <youpi>to be able to work on the hurd, the hurd would need an fb interface <youpi>and consequently, graphics drivers <youpi>better just use the xorg-provided graphics drivers <youpi>usually they need drm support though <youpi>so that's drm that would be needed <almuhs>does the fbdev offered by Hurd packages needs Linux drivers? <youpi>but it needs an fb interface <youpi>and to actually provide the interface you need drivers <youpi>in the end you need drivers anyway <youpi>better just use the xorg drivers, then, since they can build on the hurd <almuhs>yes, I'm trying to use xorg drivers, but It doesn't works <almuhs>my video card is not compatible with vesa <almuhs>even in Linux, the only options are intel or fbdev. so, I don't know if there any solution for this <youpi>then you'll get intel working <almuhs>but intel xorg driver is not offered as Hurd package <youpi>can't you just read what I write ? <almuhs>yes, but I didn't understand what do you refers exactly <youpi>I don't know how else I can call it <almuhs>oh, ok. drm if offered in a library <youpi>not only, you need the actual implementation in the kernel <almuhs>I thank that this was a signature or similar <youpi>3-letter acronyms just tend to collide easily <kilobug>almuhs: drm is a kernel module (with a userspace library to call it) that handles things like memory management (and also usually stuff like reclocking, power management, ...) for GPUs <almuhs>kilobug: thanks, now I understand <kilobug>almuhs: without that, most Xorg drivers will not work <almuhs>and drm is not implemented in Hurd? <almuhs>ok. Them, there are not drm in Hurd, and It needs to be implemented, is not? <kilobug>well, yes, it would be nice to port the drm modules from Linux to Hurd, but it's probably not that easy, since there are ties to (at least) the memory management and ACPI systems... <almuhs>I/O configurations are excessive to my knowledge. Not I'm busy with SMP <almuhs>but we can find volunteers to solve this <almuhs>It's necessary to find volunteers to solve these problems. The graphical environment is very important to attract new users <almuhs>and, a curiosity: I read about hurd-console allows copy-paste. Is It real?