On 17 Nov 2020, at 21:51, Samuel Thibault wrote:
>
> Svante Signell, le mar. 17 nov. 2020 22:47:04 +0100, a ecrit:
>> On Tue, 2020-11-17 at 21:59 +0100, Samuel Thibault wrote:
>>> Svante Signell, le mar. 17 nov. 2020 21:56:33 +0100, a ecrit:
>>
Got it. Can some of the drivers be tested with
Svante Signell, le mar. 17 nov. 2020 22:47:04 +0100, a ecrit:
> On Tue, 2020-11-17 at 21:59 +0100, Samuel Thibault wrote:
> > Svante Signell, le mar. 17 nov. 2020 21:56:33 +0100, a ecrit:
>
> > > Got it. Can some of the drivers be tested with software rendering,
> > > like swrast?
> >
> > softwar
On Tue, 2020-11-17 at 21:59 +0100, Samuel Thibault wrote:
> Svante Signell, le mar. 17 nov. 2020 21:56:33 +0100, a ecrit:
> > Got it. Can some of the drivers be tested with software rendering,
> > like swrast?
>
> software rendering does not use drm/dri. That's already what we are
> using (and ha
Svante Signell, le mar. 17 nov. 2020 21:56:33 +0100, a ecrit:
> On Tue, 2020-11-17 at 15:32 +0100, Samuel Thibault wrote:
> > Svante Signell, le mar. 17 nov. 2020 15:31:03 +0100, a ecrit:
>
> > > > > > dri cannot work. You changes in libdrm only introduced some
> > > > > > stub interface. Actual d
On Tue, 2020-11-17 at 15:32 +0100, Samuel Thibault wrote:
> Svante Signell, le mar. 17 nov. 2020 15:31:03 +0100, a ecrit:
> > > > > dri cannot work. You changes in libdrm only introduced some
> > > > > stub interface. Actual drm implementation is needed to get
> > > > > any kind of direct renderin
Svante Signell, le mar. 17 nov. 2020 15:31:03 +0100, a ecrit:
> On Tue, 2020-11-17 at 15:22 +0100, Samuel Thibault wrote:
> > Svante Signell, le mar. 17 nov. 2020 15:22:02 +0100, a ecrit:
> > > On Tue, 2020-11-17 at 14:57 +0100, Samuel Thibault wrote:
> > > > Svante Signell, le mar. 17 nov. 2020 14
On Tue, 2020-11-17 at 15:22 +0100, Samuel Thibault wrote:
> Svante Signell, le mar. 17 nov. 2020 15:22:02 +0100, a ecrit:
> > On Tue, 2020-11-17 at 14:57 +0100, Samuel Thibault wrote:
> > > Svante Signell, le mar. 17 nov. 2020 14:53:56 +0100, a ecrit:
> > > > > > Which of these (and xorg* packages)
On Tue, 2020-11-17 at 14:57 +0100, Samuel Thibault wrote:
> Svante Signell, le mar. 17 nov. 2020 14:53:56 +0100, a ecrit:
> > > > 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.
Svante Signell, le mar. 17 nov. 2020 15:22:02 +0100, a ecrit:
> On Tue, 2020-11-17 at 14:57 +0100, Samuel Thibault wrote:
> > Svante Signell, le mar. 17 nov. 2020 14:53:56 +0100, a ecrit:
> > > > > Which of these (and xorg* packages) are needed?
> > > >
> > > > Needed for what?
> > >
> > > For te
Samuel Thibault, le mar. 17 nov. 2020 14:57:06 +0100, a ecrit:
> The std and cirrus drivers work just fine with qemu.
(and yes, the cirrus driver has some dri capabilities. Apparently not
DRI2, but at least XFree86-DRI).
Samuel
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
Hi!
Samuel Thibault skribis:
> Ludovic Courtès, le mar. 17 nov. 2020 10:57:43 +0100, a ecrit:
>> I’ve noticed that I’d always get “broken” stack traces in GDB when (1)
>> attaching to a program suspended by /servers/crash-suspend, (2)
>> examining a core dump, or (3) spawning a program in GDB an
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
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 har
Ludovic Courtès, le mar. 17 nov. 2020 10:57:43 +0100, a ecrit:
> I’ve noticed that I’d always get “broken” stack traces in GDB when (1)
> attaching to a program suspended by /servers/crash-suspend, (2)
> examining a core dump, or (3) spawning a program in GDB and examining it
> after it’s received
Hello,
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?
qemu-system-x86_64 --help shows
-vga [std|cirrus|vmware|qxl|xenfb|tcx|cg3|virtio|none]
select video card type
(or is it only possible with r
Hello!
I’ve noticed that I’d always get “broken” stack traces in GDB when (1)
attaching to a program suspended by /servers/crash-suspend, (2)
examining a core dump, or (3) spawning a program in GDB and examining it
after it’s received an unhandled signal like SIGILL.
At best I can see the backtra
Somehow I was able to boot / via rumpdisk and then the arbiter
still worked afterwards, so networking via netdde started working.
This is the first time I've had a rumpdisk / with network access!
Alas, I cannot seem to make it work via the arbiter though.
My latest attempt looks like the arbiter s
18 matches
Mail list logo
