On 13 August 2015 at 16:42, Alex Deucher <alexdeuc...@gmail.com> wrote: > On Thu, Aug 13, 2015 at 11:11 AM, Emil Velikov <emil.l.veli...@gmail.com> > wrote: >> Hi Alex, >> >> On 10 August 2015 at 20:36, Alex Deucher <alexdeuc...@gmail.com> wrote: >>> Signed-off-by: Alex Deucher <alexander.deuc...@amd.com> >>> Cc: mesa-sta...@lists.freedesktop.org >>> --- >>> include/pci_ids/radeonsi_pci_ids.h | 1 + >>> 1 file changed, 1 insertion(+) >>> >>> diff --git a/include/pci_ids/radeonsi_pci_ids.h >>> b/include/pci_ids/radeonsi_pci_ids.h >>> index c01ee20..52eada1 100644 >>> --- a/include/pci_ids/radeonsi_pci_ids.h >>> +++ b/include/pci_ids/radeonsi_pci_ids.h >>> @@ -63,6 +63,7 @@ CHIPSET(0x6608, OLAND_6608, OLAND) >>> CHIPSET(0x6610, OLAND_6610, OLAND) >>> CHIPSET(0x6611, OLAND_6611, OLAND) >>> CHIPSET(0x6613, OLAND_6613, OLAND) >>> +CHIPSET(0x6617, OLAND_6617, OLAND) >> Has there been any ideas/plans on getting this information >> consolidated in a single place ? >> >> It feels a bit "dirty" having the same information in four places - >> kernel, libdrm, ddx, mesa. > > There's not really a good solution that I know of due to the way X > works. If I have to guess, obtaining OLAND via DRM_IOCTL_RADEON_INFO won't be impacted by (nor have any impact on) how X works. Shouldn't this "just work" or there is something subtly off with the idea ? Can you elaborate what part of X might be an obstacle ?
> Using xf86-video-modesetting saves one at least. And for > amdgpu, we merged the surface manager into mesa rather than having it > on libdrm since we always use glamor so we didn't need access to it in > the ddx to support EXA. > True. Even if one day you want/have to do EXA xf86-video-amdgpu one can always re-factor it out into libdrm_amdgpu. So the surface manager is a win-win atm :) Thanks Emil _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
