On Sun, Jan 27, 2013 at 10:09:05AM -0800, Paul Rogers wrote: > > > > > Looks as if FB_ATY (and perhaps some of its options) really is what > > you need. I would try rebuilding with that. > > OK, answer me this, I got the impression the frame-buffer abstraction is > something to be avoided if possible--though if I'm interpreting what I > see right when the popular "kitchen-sink" distros boot and the console > font changes, that's what they're doing. It provides some extended > "compatibility" but at the cost of some native capabilities. I'm not > building this system to run on everything in the world, as they are, but > I would like to be able to drop it onto what I might put together from > the i686 era up, and have it usable. Should I be going the frame-buffer > route to make that happen? > I've been using framebuffers for almost as long as I've been using BLFS (and longer than I've been using LFS), because on ppc mac it was the only way to go. For current hardware, kms (kernel mode setting) uses a framebuffer, in the hope that oops messages would appear on my desktop when kernels oopsed. So far, the only oopses I've seen have been during a failure to boot, so the case is not proven. But I happen to prefer a 512-character console font, so even on my server I use a framebuffer.
For you, I guess you should avoid it until you need it (e.g. recent hardware with recent intel or ati video chipsets). > > Or not. Further down my list of google results was a link to an old > > debian problem, which mentioned that Mach64 is not built because of > > security issues, and referenced > > http://dri.freedesktop.org/wiki/ATIMach64 > > > > See 'Why isn't Mach64 built by default?' on that page. I would guess > > that the separate mach64 driver in more recent xorg probably works, > > and that this page is obsolete but relevant to xorg-7.2. The link to > > the mini-HOWTO is dead. > > As it happens, my own searches yesterday took me through that page too. > > > If you agree with my analysis of what that page might mean, I guess > > you could try to build the oldest release of xf86-video-mach64 > > (6.8.0, or 6.8.2 which probably has more fixes but might have newer > > dependencies). I suspect that they will need newer dependencies, > > but it is probably worth trying to build them in case they work for > > you. The alternatives are to do without dri, or to use a newer > > version of xorg. > > Tried xorg-7.5, that's why I'm now trying 7.2. ;-) But, yes, I think > I've been thinking along those lines too. I happened to have 6.12.4, > ran a diff and grepped for mach64. Saw the call to the kernel module > had been removed. I was thinking of doing a binary search between 6.6.3 > and 6.12.4 looking for where the mach64 module was first removed and > checking into that. Gives me something to try today, pending answers > for above. For 7.5, I repeat my assertion that it probably works adequately for you - you got an error message nobody else has noted (probably because of your uncommon video card), but AFAICS you didn't have any evidence of an actual problem (in the sense of a program failing to work). It's your time, so I don't want to discourage you from looking at this, but I still think that building your desktop applications (on current xorg, since your present build doesn't work) is probably your best way forward. ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
