Comments on: Xorg update https://www.dragonflydigest.com/2004/08/16/xorg-update/ A running description of activity related to DragonFly BSD. Sat, 21 Aug 2004 23:22:25 +0000 hourly 1 https://wordpress.org/?v=6.9.4 By: Joe "Floid" Kanowitz https://www.dragonflydigest.com/2004/08/16/xorg-update/comment-page-1/#comment-365 Sat, 21 Aug 2004 23:22:25 +0000 http://www.shiningsilence.com/dbsdlog/?p=595#comment-365 As followup for anyone who manages to search across this ‘good’ advice, I lied. Or at least, I’m hitting some ridiculous, confusing bug that seems to be preventing direct rendering from working with AGP 2x (this is, again, FBSD 5.2.1, so applicability to DFly may be low), and I think I’ve already hit a case where InitPrimary failed to do anything useful; it’s now departed my config, since I had to remove it to confirm it wasn’t the culprit with the AGPMode problem.

YMMV.

]]> By: Joe "Floid" Kanowitz https://www.dragonflydigest.com/2004/08/16/xorg-update/comment-page-1/#comment-364 Fri, 20 Aug 2004 09:33:22 +0000 http://www.shiningsilence.com/dbsdlog/?p=595#comment-364 After resetting a 170 day uptime moving my FreeBSD box to X.org, I’m punch-drunk enough to share a few half-posteriored “ways not to be Floid:”

-If, like me, you’re cursed to have direct rendering break every time you upgrade, keep an eye on your modes. This time around, it turns out I had some modelines in XF86Config that… really shouldn’t have been there, and letting it use the built-in defaults cured my G200’s perennial need for the MGA HAL. (No, this isn’t ‘need’-as-in-avoid-the-warning, this is need-as-in-avoid-locking-the-keyboard and never getting a window onscreen when running GL apps…)

The strange thing is, I thought removing those modelines were what cured it *last time*…

-I can’t remember if this is already fixed in DragonFly or FreeBSD past 5.2, but if you tend to get into situations that corrupt your console and leave your graphics card in a nondeterministic state (similar to the nVidia fading-console bug, IIRC, but crashing the X server for OOM or direct-rendering madness often leaves things in a much, um, ‘prettier’ and even less-usable state for me), I’ve stumbled across two ghetto fixes that may work when you’ve got nothing left to lose.* The first one is a suggestion from a FreeBSD list to try putting the system into suspend [zzz(8)] and waking it up… but it figures my desktop supports every ACPI state save the needed ‘S3.’ The second is to insert ‘Option “InitPrimary” “true”‘ in your Screen section, which looks like it might force the card to reinitialize every time you start the X server; I’ve yet to ‘prove’ whether that works, but I’m experiencing no ill effects from it,** and it sounds like it might’ve saved my uptime had I noticed it before loading and killing X enough times to get into a hard lock.***

*As in: Not only is the text console corrupt, but you’ve got things so hosed that the X server hangs trying to talk to the card.
**If you use a ‘custom’ console font, you might want to test or research whether this will effect it.
***In my case, it took about ten vain startx/kill -9 pairs before I got the card confused enough to *completely* freeze the system, so there still would’ve been a chance to try injecting that. Oh well. ;)

]]>