Hi,
I am not been able to contact with mentor of this project.
Can someone else from the community help me with this ?
Regards,
Anusha Srivastava
On 3 March 2018 at 11:16, Anusha Srivastava wrote:
> Hi Martin,
>
> Any update on this ?
> Regards,
> Anusha Srivastava
>
>
> On 28 February 2018 a
https://bugs.freedesktop.org/show_bug.cgi?id=75985
--- Comment #58 from Ilia Mirkin ---
OK, well, I've seen this both ways -- 3D controllers with outputs as well as
VGA display adapters with the display function actually fused off. The only
reliable thing is the DCB block, but like you said, it's
https://bugs.freedesktop.org/show_bug.cgi?id=75985
--- Comment #57 from Maik Freudenberg ---
(In reply to Ilia Mirkin from comment #55)
> What's the downside for doing this always btw
By 'this', you mean, always turning it on?
This generates the errors from comment #42 since those devices are no
https://bugs.freedesktop.org/show_bug.cgi?id=75985
--- Comment #56 from Lukas Wunner ---
(In reply to Ilia Mirkin from comment #53)
> (In reply to Lukas Wunner from comment #52)
> > Ilia, do you have definitive knowledge of GPUs which
> > a) have a different class than PCI_CLASS_DISPLAY_VGA and
>
https://bugs.freedesktop.org/show_bug.cgi?id=99464
--- Comment #3 from Greg V ---
(In reply to Greg V from comment #2)
UPDATE! The issue was in our DRM port, specifically with ioctl
authentication/permissions.
If nouveau still has this problem, try looking into that…
--
You are receiving this
https://bugs.freedesktop.org/show_bug.cgi?id=75985
--- Comment #55 from Ilia Mirkin ---
(In reply to Maik Freudenberg from comment #54)
> (In reply to Ilia Mirkin from comment #44)
> > One can check if the DCB table has any outputs, and only do
> > stuff if there are none.
> I don't see how that'
https://bugs.freedesktop.org/show_bug.cgi?id=75985
--- Comment #54 from Maik Freudenberg ---
(In reply to Ilia Mirkin from comment #44)
> One can check if the DCB table has any outputs, and only do
> stuff if there are none.
I don't see how that's feasible since this would require to load the ROM
https://bugs.freedesktop.org/show_bug.cgi?id=99464
--- Comment #2 from Greg V ---
I'm currently also experiencing a crash with OpenMW in update_framebuffer_size
(surface is NULL).
But with RadeonSI on Wayland! (SDL_VIDEODRIVER=wayland)
Radeon RX 480, FreeBSD 12-CURRENT + drm-next-kmod 4.11, Mes
https://bugs.freedesktop.org/show_bug.cgi?id=105344
--- Comment #7 from Yuri Gelsleichter ---
Dear all,
thanks for the points.
(In reply to Ilia Mirkin from comment #5)
> (In reply to Emil Velikov from comment #4)
> > Considering that nouveau.modeset=0 helps, I'm flipping this to component
> >
https://bugs.freedesktop.org/show_bug.cgi?id=105344
--- Comment #6 from Yuri Gelsleichter ---
Dear all,
thanks for the points.
(In reply to Emil Velikov from comment #4)
> Considering that nouveau.modeset=0 helps, I'm flipping this to component
> nouveau. Feel free to revert.
>
Flipping fits g
On Sat, Mar 03, 2018 at 10:53:24AM +0100, Lukas Wunner wrote:
> Modernize vga_switcheroo by using a device link to enforce a runtime PM
> dependency from an HDA controller to the GPU it's integrated into, v2.
>
> Changes since v1:
>
> - Replace patch [1/7] to use pci_save_state() / pci_restore_st
On Tue, Feb 27, 2018 at 01:07:06PM +0100, Christian König wrote:
> Hi guys,
>
> at least on amdgpu and radeon the page array allocated by ttm_dma_tt_init is
> completely unused in the case of DMA-buf sharing. So I'm trying to get rid
> of that by only allocating the DMA address array.
>
> Now the
12 matches
Mail list logo