> Date: Mon, 18 Nov 2013 11:26:31 +0100 > From: Stefan Sperling <s...@openbsd.org> > > On Mon, Nov 18, 2013 at 01:22:20AM +0200, ja...@cieti.lv wrote: > > I tried this diff and at least one thing changed -- neverball now works > > (previously it immediately hung the GPU on start). There is still corruption > > and GPU hanging in chromium. There is corruption in mplayer -vo gl too (and > > it is still much slower than it is on 5.4). > > > > With a lot of help from Stefan Sperling I tried to do experiments. > > > > Since I am too unskilled I was not able to do it properly and build xenocara > > from the same point in time (date-based CVS checkouts do not compile for me) > > It's unfortunate that CVS messes up like this :( > I just tested date-based checkouts with opencvs and it's also broken. > > > but I built kernel on 5.3 from 2013-07-06 with just this patch applied: > > http://freshbsd.org/commit/openbsd/304417ea27d0874895cc4e65c30324b7bd14ac22 > > (as I am 80% sure it's when problems started) and the screen became totally > > corrupted in X but computer did not hang. It looked very similar to what is > > seen now. If that helps that is all I could find out. > > Well, that is the patch that requires a newer libdrm to work. > It changes the userland<->kernel interface that libdrm is using > to talk to the kernel to configure graphics. So unless you also > updated libdrm I don't think that it is surprising that graphics > stopped working in this configuration. > > You could try updating libdrm (/usr/xenocara/lib/libdrm) to the same > time frame.
At this point it is probably pointless to figure out what broke things. Too many things have been piled on top of each otjher in the last 5 months. Even if you manage to figure out what broke things, we almost certainly can't revert the change now without breaking a lot of other stuff. Some of the problems you're seeing are simply caused by the fact that ports like chrome and firefox are now using graphics acceleration much more aggressively than they used to. You'll just have to hope that the changes I'm currently working on fix things eventually. Meanwhile the best you can do is avoiding the use of "3D" acceleration, either by removing /usr/X11R6/lib/modules/dri/i965_dri.so from your system, changing permissions on /dev/drm0 such that only root can access it, or creating a /etc/drirc with the appropriate options. It's not really surprising that your GM45-based system has a lot of these issues. Neither jsg@ nor I have access to this hardware. If somebody has a laptop with this chipset that they're willing to donate and ship to Australia or the Netherlands, please contact us.
