[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: working xorg.conf i promised



On 7/28/07, Finn Thain <fthain@telegraphics.com.au> wrote:
>
> On Thu, 26 Jul 2007, Brian Morris wrote:
>
> > > But if you find that Linux 2.6 lacks functionality in 2.2 or in BSD,
> > > please tell us because then (time permitting) we could feasibly
> > > improve the drivers.
> >
> > well I don't know what 2.2 did, but on my quadra475/605 (w/CPU replace
> > w/FPU). I could not start X because framebuffer not recognizing the mode
> > 640x480 or 800x600 in 8 bit.
>
> I don't know what 2.2 did either. Looking at the 2.6 code tells me that
> only the valkyrie driver can switch modes, which seems to agree with the
> FAQ.

I am not trying to switch modes, I am simply trying to start the X server,
from the mode I booted in ! Referring to the modes I meant trying to
boot in that mode and start the server in the same mode !!
>
> > I think I could hard code the resolution to what I want, but that
> > obviously is not what you all want. But that was one reason I wanted to
> > try built me a kernel.
>
> There are no compile-time options for video modes that I know of. Skimming
> the code I can see that there are some boot-time options for both the
> valkyrie driver (vmode and cmode) and for the macfb driver (vidtest and
> inverse).

I mean in the framebuffer code where it supposedly reads the mode from
the system and sets the framebuffer up, that is apparently where the error
is. IF IRC, the xserver is getting passed a fixed mode which the framebuffer
driver in the kernel has judged incorrecty as the mode the system is in,

That is, the modes of the 475/605 are  probably in compatible in a formal
sense with what some other model uses. when the framebuffer code has
to resort to guessing, it uses a list of models and fixed or default modes.

So I would just cut that piece of code out and put in 800x600x8@56hz and
recompile the kernel --- that would at least test that this is indeed
the problem.
But other machines probably would then hang just like mine did,
if that is the guessing mode,
so I could not give you a patch, only a confirmation if it does work for me.



>
> > I think also it would work if I upgraded the VRAM to 1MB which is
> > currently 512k. the reason is that that would let me get a more standard
> > setting from the macos which the framebuffer driver then could
> > recognize.
> >
> > I just looked at this very quickly like a month ago, but i think there
> > was a list of possible resolutions hard coded already which assumes that
> > the one i have is not. maybe it is a question though of supporting more
> > machines when you can not support them all ??

please refer to above as to what I meant ...
>
> I'm afraid so. My to-do list (ordered chronologically, as I've added to it
> over the years):
>
> - fix serial driver
> - fix real time clock driver
> - fix/replace NCR5380 SCSI driver
> - fix Egret & PMU ADB drivers
> - replace mac_esp SCSI driver with the new one
> - attend to sourceforge tracker issues
>
> ...and that is just fixing or preventing regressions against 2.2.

I think it is really good that you both take responsibility and include your
limits in it. I wish everyone did that.

I only responded because you ask, and I did not ask you to take care of it,
but I thought people should hear about it.

I had read that the 605 was the second most popular '040 mac after the
630, so I am surprised if no one tried X on a 605 before.


>
> BTW, I've almost finished updating the mac68k web site (I think). The FTP
> archive should be back online soon (as HTTP). The mailing list won't be
> coming back though, because whoever hosted it can't be contacted or even
> confirmed as the host.

Is this someplace we could stick custom packages such as cross compilers
or kernels tailored for specific machines ? or even emile cd images ?

>
> -f
>



Reply to: