> > 3) cursor keys in dga seem to be malfunctioning
> > Actually, display-dga as a whole seems nonfunctional,
> Haven't looked at this yet.
Hmm - got to recheck, bvut it worked like a charm for me last time I tried.
However that was with ancient sources - will try at the univ tomorrow.
> > 4) Remove KGIcon to an attic, disable fbdev-mga on MGA1064
> Not removed yet. Andy did commit changes to fix fbdev-mga on G400, though.
Yeah - anyone to test that on the other matrox cards ?
Slight hack to fbdev/visual.c might be needed to enable it on other cards.
I suppose the G400 code should run generically on all Matrox boards.
> smoke says this just isn't implemented as far as he can see, and would
> be a chore to implement; we should ensure that mode requests with
> frames > 1 actually fail, rather than pretending to work.
Hmm - does scrolling work (setorigin) ? If so I'd say emulate frames with
it, just as we do with fbdev.
> > 6) Running -inroot under 8bpp X stops other apps from running
> The above problem can be fixed by adding an XSetWindowColormap to put the
> value gotten from XDefaultColormap back into the root window when done,
> but raises the question -- is it the right thing to do to entirely change
> the ID of the root window's colormap as we now do, or should we instead
> add our colors to the default colormap and then delete them back out when
> we are done? This I ask considering the effect on other X apps including
> GGI apps. Opinions?
Hmm - I'd say yes - the problem might be, if someone has a strange colormap
for the root window (say form a gradient ...), the GGI app might have
problems to alloc its own colors.
> backbuffering would be needed if we wanted to restore the image;
> and that would be prohibitively expensive.
Not really, but linux vc switching doesn't facilitate that nicely. The old
scrdrv patches did it ... though it was a bit umm strange *g*
CU, Andy
--
= Andreas Beck | Email : <[EMAIL PROTECTED]> =
