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/dr= ivers/gpu/drm/ast=20 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. >=20 > If that is the case, does anyone know difficult it would be to port = the Linux DRM driver? >=20 > 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>