Date: Fri, 18 Sep 2020 13:58:31 +0930 From: "O'Connor, Daniel" <darius@dons.net.au> To: "Daniel O'Connor" <darius@dons.net.au> Cc: FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: ASPEED video driver Message-ID: <A8F204AF-D3E3-400C-A0C4-C62B160CD90A@dons.net.au> In-Reply-To: <8851FC7F-979D-4CDC-8513-CE893B2EF269@dons.net.au> References: <8851FC7F-979D-4CDC-8513-CE893B2EF269@dons.net.au>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 7 Sep 2020, at 13:02, O'Connor, Daniel via freebsd-hackers <freebsd-hackers@freebsd.org> wrote: > Performance used to be tolerable but it seems to have gotten significantly worse in newer BIOS versions. It turns out this is likely due to compositing being turned on for newer systems, although even with it disabled it's not a great performer (but usable) > I note that Linux has a DRM driver for these https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/ast An attempt was made to get the FreeBSD DRM port of this running but failed because the version in that tree is too old to support the atomic modset (but hopefully it can be picked up later..) > However I'm not sure how that integrates with X.. If Linux doesn't actually use the Xorg driver then I suppose that would explain why it's rotted and useless. > > If that is the case, does anyone know difficult it would be to port the Linux DRM driver? > > I did try contacting ASPEED and Supermicro but they pointed the finger at each other and then blamed FreeBSD so I'm a bit stuck. Some more investigation in the Linux DRM code showed it has a work around because some systems disable a feature (for security reasons). I've ported this to the X driver and filed a PR for the port. -- Daniel O'Connor "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?A8F204AF-D3E3-400C-A0C4-C62B160CD90A>