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

Re: working xorg.conf i promised



On 6/4/07, Eugen Paiuc <e.paiuc@gmail.com> wrote:


2007/6/2, Brian Morris <cymraegish@gmail.com>:
> On 6/1/07, Eugen Paiuc <e.paiuc@gmail.com> wrote:
> > # xorg.conf (xorg X Window System server configuration file)
> > #

> > # This file was generated by dexconf, the Debian X Configuration tool,
using
> > # values from the debconf database.
> > # Then it was modified by hand merging with ppc
> > xorg.conf that worked and
> > # further editing to include framebuffer modes (output of fbset -x).
> > # so far it only works on my q630 and FAILS on my q605
> > # also only tested with unstable/xorg7.2 (etch is 7.1) .... BCM 5/29/07
> >
> >
> >
> > I tested your xorg.conf on etch and is ok. Thank for your work.
> >
> > Funy, now, even the "standard" xorg.conf , in depth 16 is working.
>
> you mean just what dexconf made when you installed xorg ??

 yes , I use xorg.conf  instaled by debconf.


> what do you mean,
> "now" ?

"Now", mean nothing special . Only after I see that  your xorg.conf
is "working", I tryed the debconf 's  xorg.conf.

> >
> > There is a little issue with flushing the video_ram before doing startx.
>
> my problem in 16bit was maybe that (besides just tired). well if I were
> not careful the Xserver only sees 300k of my 600k of vram and then
> when I startx I see on the bottom half of the screen "leftovers" of macos
> desktop. I think it is necessary to set the video to 640x480-16 in macos
> or/and to use kernel options vmode=x, cmode=y (x and y are numbers
> which are 10 and 8 for 800x600-8, but what is the first number for
640x480-16
> i would have to experiment and it depends on the model what sync freq
> is supported)

 Put  Defaut depth 16, - in debconf 's  xorg.conf, than startx , you will
have
only half a screen-, stop it, change to depth 8, - in debconf 's  xorg.conf,
than startx , will see errors, -ignore it,  rechange  to  depth 16 (or
better 15)
re startx, resolve issue.

thanks, I will try this out on my system.

>
> It really is more important
> to me to have the 800x600 screen space.


Sadly, only 640x480 is available . (  using packages from debian archive).

OK, so what we have is dexconf auto generated xorg.conf does do 16 bit
(or 15) in 640x480, but not 800x600 even in 8 bit.

on the other hand, my hand fixed xorg.conf *will* do 800x600 8 bit.
it may do 640x480 16 bit too with a little more patience, I think.

there is some issue about whatever mode you boot from too,
there is trouble switching if you change your mind.




> (some of the old pmacs with
> framebuffer graphics i have have the same issue)
>
> again with 605 i am not sure i wasn't just tired. I am trying again soon.
>
>
> both my 650 and 630 have full real fpu. however i do have an extra pb520
> I would like to try if you have '040lc built stuff to test --

I use only  packages from debian archive...  sorry
you have a hardware problem there if your LC chip mostl likely.
unless you have a later model perhaps they fixed it. the "mask revision
bug" was fixed on motorola 68040LC processors made after september
'94 i believe.

My 630 has a manufacturing date of August 1994. I have seen a 631
(same except for an additional RAM slot) that had a date of July '95.

if you have a "defective" chip you have a problem to run linux no
body has solved, unless you custom compile everything that uses the
FPU. this is a long story I should not repeat here, but you can look it
up in mailing list archives and on the web.

there is a certain way to read the mask revisions from the serial number
on your CPU, but one "sufficient but not necessary" condition I know
of that is easy is if the first two letters on the chip are MC rather than XC
(MC always indicates final version). but somewhere it was fix before that.

the other thing the other guys were discussing I guess was about that
the FPU of '040 even when present is not complete as the '030 coprocessor
(68881/2) was, so a few FPU functions are emulated still, but this is
supposed to be handle by the kernel. I don't know what that
business was about a bug in Xorg (i guess it can be looked up though).




> >
> > Playing with  depth 8, startx and then depth 16 startx, resolve issue.
> >
> > Xorg has a bug on processor (>68020) with out native fpu.
> >
> > {You just hit an inplemented fpu instruction (flogn) and (fetox)
> >
> > Backtrace:
> > 0: /usr/bin/X11/X(xf86 SigHandler+0x6e)[0x8007b7de]
> > 1:[0xefce6a38] or [0xefa28a38]}
> >
> > Maybe that is why xorg don't work on q605

when i tried on mine i did not realize that (appears) the framebuffer
is named "MAC" (so kernel indicates choices of either that or "Valkyrie"
which is correct for 630 but not for 650, but the name that the system
provides is *not* "Mac" rather some obscure four letter acronym starting
with "D"
> >
> > (or a q630 with out native fpu, my case)
> >
> > Tests made on q630 with
> >
> >
> > 1. processor 040 with fpu
> > 2. processor 040 without fpu
> >
> well glad to see you are working on this.

my too.

> would get a battery recycled
> for the old 520 if i was not too discourage of having too much
> stuff to build. also hear the pb was subject to comas in 2.4 falling so
> it would be a test for 2.6...

 For moment I try to install four p630, and just that is very "difficult"
-for me -,
well if you have four you could put one to work building your fpu emulated
system. it is probably not to difficult once set up, just time consuming (and
helps plenty of disk space)

btw,  what configuration  of disk(s) ( on ide and/or scsi) do  you use on
p630 ?

I have a 4GB ide and a 4GB scsi now for backup of 630 and testings.
Both support basic SMART package "Health OK" checks. formatting
the ide with apple formatter from 0S8.6 (works with 8.1 too I think and
can download). formatting scsi disks with APS power tools version4.

i believe both disks are Seagate brand.  they were both salvaged from
old intel pc circa 1999... (owners upgraded and local shop resells trade-in)


and can you format a ide disk for  p630 ?

Thank  you ,
 --
> ee
>




Reply to: