Svante Signell, le mar. 17 nov. 2020 14:53:56 +0100, a ecrit: > On Tue, 2020-11-17 at 14:22 +0100, Samuel Thibault wrote: > > Svante Signell, le mar. 17 nov. 2020 11:41:52 +0100, a ecrit: > > > I managed to build more packages from mesa based on that libdrm is > > > now available. Is there any way to test these packages with qemu? > > > > Which packages? Those mentioned below in your mail? They don't depend > > that much on the emulated hardware, and rather on the software being > > used. > > Testing xorg with the other drivers than default?
But you need hardware (virtual or physical) to run these drivers again. > > > qemu-system-x86_64 --help shows > > > -vga [std|cirrus|vmware|qxl|xenfb|tcx|cg3|virtio|none] > > > select video card type > > > > Yes, that's basically all. Apart from the virtual devices meant for > > virtualization, qemu doesn't propose many virtual cards. > > Not emulating any of the radeon/nvidia/etc graphics cards then. So Hurd > has to run on real hardware? ? No The std and cirrus drivers work just fine with qemu. > That can maybe be possible when rumpdisk is working properly!? That has nothing to do at all with disks. > > > Which of these (and xorg* packages) are needed? > > > > Needed for what? > > For testing if some of the dri/drv drivers work on Hurd: e.g. r200, > r300 etc. dri cannot work. You changes in libdrm only introduced some stub interface. Actual drm implementation is needed to get any kind of direct rendering working > > (In general, relying on gettid() to provide non-reusable thread ids > > is nonsense: tids do wrap around as well). > > So you mean that all calls to gettid() can be replaced with > pthread_self() for non-linux systems? Even for Linux system that should just work well enough. And theorically not worse that gettid(), actually. Samuel
