Compiling option for LinuxPPC

Compiling option for LinuxPPC

[Andreas]

Hi all,

does under LinuxPPC a compiler option /preprocessor symbol exist in the manner
as it does under FreeBSD?

i.e. __FreeBSD__ or in LinuxPPC __LinuxPPC__??

Thanks for any hints,

Andreas
-- 
------------------
| Andreas Tobler								
| CH-8004 Zuerich	
| E-mail: toa@pop.agri.ch		
------------------------------------------


[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Compiling option for LinuxPPC

[Geert Uytterhoeven]

On Thu, 4 Feb 1999, Andreas wrote:
> does under LinuxPPC a compiler option /preprocessor symbol exist in the manner
> as it does under FreeBSD?
> 
> i.e. __FreeBSD__ or in LinuxPPC __LinuxPPC__??

defined(__linux__) && defined(__powerpc__)

Greetings,

						Geert

--
Geert Uytterhoeven                     Geert.Uytterhoeven@cs.kuleuven.ac.be
Wavelets, Linux/{m68k~Amiga,PPC~CHRP}  http://www.cs.kuleuven.ac.be/~geert/
Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium


[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Compiling option for LinuxPPC

[David Edelsohn]

>>>>> Andreas  writes:

Andreas> does under LinuxPPC a compiler option /preprocessor symbol exist in the manner
Andreas> as it does under FreeBSD?

Andreas> i.e. __FreeBSD__ or in LinuxPPC __LinuxPPC__??

	No OS-specific macro for LinuxPPC is currently generated by EGCS. 

David

[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

modes "default" solutions

[Brad Midgley]

geert,

I have been experimenting to try to find out when and why modes "default"
doesn't work with Xfb.

1. modes default is incompatible with acceleration provided by Xfb.
problems range from messed up colormaps to a white screen pocked with
artifacts. if you need modes default, turn off acceleration:

Section "Device"
    Identifier "Linux Frame Buffer Device"
    Option "noaccel"
EndSection

2. if you run vmode and it reports something like "0 32" for the current
mode, Xfb will come up with an oversize virtual screen if it's run with
modes default. however, if vmode comes up with something like "15 32" then
the virtual screen size will match the real screen size. 

unfortunately, the os is not setting the first parameter correctly at
startup, so the only way to have vmode return something sensible is to use
it to set the value, eg by running vmode 15 32 at startup.

i am going to look into why the os isn't setting the first value properly.

i'm observing both these behaviors on an imac and on a 7500 with an ati
xclaim vr board.

Brad
brad@pht.com | http:/www.pht.com/~brad/


[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]