Date: Sun, 17 Aug 2008 16:53:57 -0400 From: Coleman Kane <cokane@FreeBSD.org> To: vehemens <vehemens@verizon.net> Cc: freebsd-x11@freebsd.org Subject: Re: [CFT] drm updates Message-ID: <1219006437.21310.12.camel@localhost> In-Reply-To: <200808161635.32540.vehemens@verizon.net> References: <200808142307.32015.vehemens@verizon.net> <200808151705.12296.vehemens@verizon.net> <1218848713.2308.0.camel@localhost> <200808161635.32540.vehemens@verizon.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--=-oqAmaI1YQpc0J1TiL2cV Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sat, 2008-08-16 at 16:35 -0700, vehemens wrote: > On Friday 15 August 2008 06:05:13 pm Coleman Kane wrote: > > On Fri, 2008-08-15 at 17:05 -0700, vehemens wrote: > > > On Friday 15 August 2008 04:13:31 pm Coleman Kane wrote: > > > > On Fri, 2008-08-15 at 16:12 -0700, vehemens wrote: > > > > > On Friday 15 August 2008 07:41:27 am Coleman Kane wrote: > > > > > > ... > > > > > > Do you host any of the patches publicly right now? I'd be more = than > > > > > > happy to test them out and see how well they work with my RS690= . > > > > > > Right now my GPU is unusable for EXA or DRI using xf86-video-at= i > > > > > > (intermittently works) or xf86-video-radeonhd (never works, > > > > > > displays artifacts, then screeches to a halt). > > > > > > ... > > > > > > > > > > After thinking about your stability problems a bit more, xserver = has > > > > > recently received a number of EXA improvements, R500 MESA/DRM sup= port > > > > > is fairly recent, and the drivers are a moving target a well. Fe= w > > > > > (none?) of these improvements are in the official FreeBSD src/por= ts > > > > > trees. > > > > > > > > > > I'll send you a xf86-video-radeonhd tarball that I just created a= nd > > > > > tested with my HD 2660 PRO. It may help, but I suspect that othe= r > > > > > parts of the X tree will need to be updated as well. > > > > > > > > I've been tracking the following masters from fd.o git: > > > > > > > > mesa/drm dri2proto fontsproto glproto inputproto kbproto libX11 > > > > libXdamage libXfont libXtst libxcb libxtrans mesa/mesa xorg-server > > > > x11proto randrproto xcb-proto xextproto xf86driproto xproto libXext > > > > libXi libXrandr libpciaccess libxkbfile libxkbui xf86-video-ati > > > > xf86-video-radeonhd xf86-input-keyboard xf86-input-mouse > > > > > > Interesting. The list is a bit shorter then mine. I don't see pixma= n as > > > well as a few others. Not sure if it matters all that much. > > > > > > When you update mesa, do you update both the dri and libGL ports? Di= tto > > > for libdrm and kernel drm? > > > > > > Guess I'll checkout my builds on a RS690 and see what happens. > > > > D'oh! Yeah, pixman should be included in that list too. I am tracking i= t > > as well. I can't get very far on the latest X.org without it! >=20 > Almost all combinations of ddx/dri/drm drivers hangs my am64 box. >=20 > Did get X running by using the radeonhd and dri swrast drivers, as well a= s=20 > removing the other drivers. >=20 > System reports it has dri, but compiz or glgears doesn't run. >=20 > What combinations worked for you? Basically, I can use radeonhd or ati from git master without trouble as long as I am not using DRI. The radeonhd driver also freezes my system when I try to use EXA. When I use EXA+DRI in the radeonhd driver, I get an X root window that has a bunch of artifacts displayed on it. Interestingly enough, it seems like it dumps a bitmap of the last image of the text console to the root window, the one I would see before the video mode switched after running startx. The mouse cursor works for a little while, as it seems compiz is beginning to load from the gnome-session manager. I never actually see any screen updates occur while it is starting up. Then, at some point the system just freezes and I need to hard-power-off the laptop, by holding down the power button until it is forced off. With the ati driver and DRI+EXA, running startx causes the X server to begin to load, then changes the video mode and blanks the screen. Once the screen has been cleared, the server freezes and no loading proceeds. I can reset the system by doing an ALT-CTRL-DELETE or by doing soft-power-off by pressing, then releasing the power button (which FreeBSD-ACPI catches and gracefully shuts the machine down). The shutdown process must be held up by something in bufdaemon or other kernel service that typically counts down the "remaining" during a normal shutdown, of course I can't see which with the X server owning the display. Eventually the system is shutdown or restarted. At some point back in early June, it all started to work for me sometimes. Robert Noland threw a bunch of patches my way that fixed numerous locking issues in the kernel, which gradually made things more reliable for me. At some point in July, some commits to the sources resulted in intermittent crashing in the EXA code, which I was able to reproduce with/without DRI enabled (always with EXA), when browsing various websites with firefox. Eventually, later on in July, I began to get the results that I currently get with DRI enabled. That is to say, it no longer ever works for me under the ati driver (freezes X server at startup). I've never been able to get radeonhd to give me operational DRI support. If I am not using EXA, but have DRI enabled, radeonhd will start up properly, but will not display any DRI output (instead just displaying black where the DRI stuff should be rendered). --=20 Coleman Kane --=-oqAmaI1YQpc0J1TiL2cV Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAkioj+EACgkQcMSxQcXat5f6NACeNiholDoAaeV1HYR8gupdkmCi EtUAmwbItpJOo4gBIIqnFeBF57VMTnJ9 =CoEi -----END PGP SIGNATURE----- --=-oqAmaI1YQpc0J1TiL2cV--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1219006437.21310.12.camel>