BootX enhancement request

BootX enhancement request

[brad allison]

I'm not sure how hard/not hard this would be to do, but right now in order
to change resolutions I have to boot into MacOS, set my resolution, launch
BootX, boot into init 3, run Xautoconfig, boot into init 5.

That's a lot of work to just change the resolution for X.

It would be nice if you could set the resolution and color from BootX on
boot up.

If there's a easier way to change pixel depth and resolution from inside X
please let me know....

-b

--
AOL SAPI 		                        703.265.0908     AIM:jackal242
http://jackal.fudge.org        `I was never more certain of how far away I was
from my goal than when I was standing right beside it.' - Ethan Hawke, Gattaca


[[ 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. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: BootX enhancement request

[Kevin Puetz]

Does your machine not have a video driver? If you can avoid no video driver mode, this should not be needed (use Xconfigurator to setup multiple resolutions).

On the other hand, though, this would be nice for those who don't have supported video (like B&W G3's, or is the new 128 driver usable already?)

On Sun, 22 Aug 1999 13:45:27 brad allison wrote:
> 
> 
> I'm not sure how hard/not hard this would be to do, but right now in order
> to change resolutions I have to boot into MacOS, set my resolution, launch
> BootX, boot into init 3, run Xautoconfig, boot into init 5.
> 
> That's a lot of work to just change the resolution for X.
> 
> It would be nice if you could set the resolution and color from BootX on
> boot up.
> 
> If there's a easier way to change pixel depth and resolution from inside X
> please let me know....
> 
> -b
> 
> --
> AOL SAPI 		                        703.265.0908     AIM:jackal242
> http://jackal.fudge.org        `I was never more certain of how far away I was
> from my goal than when I was standing right beside it.' - Ethan Hawke, Gattaca
> 
> 


[[ 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. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: BootX enhancement request

[Mike Lambert]

brad allison wrote:
> 
> I'm not sure how hard/not hard this would be to do, but right now in order
> to change resolutions I have to boot into MacOS, set my resolution, launch
> BootX, boot into init 3, run Xautoconfig, boot into init 5.

One way would be to add a line to your rc.local file to check for and
run Xautoconfig automatically on startup.

> It would be nice if you could set the resolution and color from BootX on
> boot up.

This would require using  a video hw specific driver such as "atyfb" or "aty128fb".
 
-mike

[[ 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. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: BootX enhancement request

[Robert Shaw]

Brad,

Once again, you DO NOT NEED TO DO THIS! The B&W G3 now has video support.

If you've downloaded the latest kernel from my web-site, you can specify the
video mode you want from the kernel arguments of BootX. Add the following to you
kernel arguments:

video=aty128fb:vmode:17,cmode:32

That will give you 1024x768 @ 75Hz, w/32bpp. Piece of cake, no init'ing, no
rebooting, no running Xautoconfig.

The FAQ page at my site (http://www.inficad.com/~rshaw/g3_faq.shtml) also has the
reproduction of the vmode settings that are available. They work, and no running
of Xautoconfig is needed.

-Robert
rshaw@inficad.com
http://www.inficad.com/~rshaw/


brad allison wrote:

> I'm not sure how hard/not hard this would be to do, but right now in order
> to change resolutions I have to boot into MacOS, set my resolution, launch
> BootX, boot into init 3, run Xautoconfig, boot into init 5.
>
> That's a lot of work to just change the resolution for X.
>
> It would be nice if you could set the resolution and color from BootX on
> boot up.
>
> If there's a easier way to change pixel depth and resolution from inside X
> please let me know....
>
> -b
>
> --
> AOL SAPI                                        703.265.0908     AIM:jackal242
> http://jackal.fudge.org        `I was never more certain of how far away I was
> from my goal than when I was standing right beside it.' - Ethan Hawke, Gattaca


[[ 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. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: BootX enhancement request

[brad allison]

On Mon, 23 Aug 1999, Robert Shaw wrote:

> Brad,
> 
> Once again, you DO NOT NEED TO DO THIS! The B&W G3 now has video support.
> 
> If you've downloaded the latest kernel from my web-site, you can specify the
> video mode you want from the kernel arguments of BootX. Add the following to you
> kernel arguments:
> 
> video=aty128fb:vmode:17,cmode:32
> 
> That will give you 1024x768 @ 75Hz, w/32bpp. Piece of cake, no init'ing, no
> rebooting, no running Xautoconfig.
> 

I think you missed my point.  Don't get me wrong, that's cool to know.
But I was thinking more along the lines of a drop down menu to set the
resolution from BootX rather than cryptic kernel arguements.

It seems the 2.2.10 kernel will not sync to the video settings at all
without the kernel arguements.

> The FAQ page at my site (http://www.inficad.com/~rshaw/g3_faq.shtml) 
> also has the
> reproduction of the vmode settings that are available. They work, and
> no running of Xautoconfig is needed.

Well i think putting Xautoconfig in the rc.local file is still a good
idea.

-b


> 
> 
> brad allison wrote:
> 
> > I'm not sure how hard/not hard this would be to do, but right now in order
> > to change resolutions I have to boot into MacOS, set my resolution, launch
> > BootX, boot into init 3, run Xautoconfig, boot into init 5.
> >
> > That's a lot of work to just change the resolution for X.
> >
> > It would be nice if you could set the resolution and color from BootX on
> > boot up.
> >
> > If there's a easier way to change pixel depth and resolution from inside X
> > please let me know....
> >
> > -b
> >
> > --
> > AOL SAPI                                        703.265.0908     AIM:jackal242
> > http://jackal.fudge.org        `I was never more certain of how far away I was
> > from my goal than when I was standing right beside it.' - Ethan Hawke, Gattaca
> 

--
AOL SAPI 		                        703.265.0908     AIM:jackal242
http://jackal.fudge.org        `I was never more certain of how far away I was
from my goal than when I was standing right beside it.' - Ethan Hawke, Gattaca


[[ 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. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: BootX enhancement request

[Tom Rini]

On Mon, 23 Aug 1999, brad allison wrote:

> On Mon, 23 Aug 1999, Robert Shaw wrote:
> 
> > Brad,
> > 
> > Once again, you DO NOT NEED TO DO THIS! The B&W G3 now has video support.

This, BETA, driver. :)

> I think you missed my point.  Don't get me wrong, that's cool to know.
> But I was thinking more along the lines of a drop down menu to set the
> resolution from BootX rather than cryptic kernel arguements.

So you want BootX to be able to do what Monitors & Sound can do.  Either
pick a mode there and use BootX from MacOS, or once 2.4.0 rolls around,
specify video=aty128fb:1024x768@75 (or so).  There is no need for BootX to
do this.

> It seems the 2.2.10 kernel will not sync to the video settings at all
> without the kernel arguements.

What, aty128fb?  It's beta and not done.  You're prolly better off using
No Video Driver, unles you're gonna play w/ the source (Anthony, speak up
if i'm wrong). :)

> > The FAQ page at my site (http://www.inficad.com/~rshaw/g3_faq.shtml) 
> > also has the
> > reproduction of the vmode settings that are available. They work, and
> > no running of Xautoconfig is needed.
> 
> Well i think putting Xautoconfig in the rc.local file is still a good
> idea.

Xautoconfig is nice for monitors that don't work right w/ Xconfigurator.
It's not a tool for "No Video Driver" machines, it's a tool for wierd
monitors/easier to setup X.

---
Tom Rini (TR1265)
http://gate.crashing.org/~trini/


[[ 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. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: BootX enhancement request

[Robert Shaw]

> I think you missed my point.  Don't get me wrong, that's cool to know.
> But I was thinking more along the lines of a drop down menu to set the
> resolution from BootX rather than cryptic kernel arguements.

Ok, that's reasonable. Any thoughts Ben?

> It seems the 2.2.10 kernel will not sync to the video settings at all
> without the kernel arguements.

Strange, mine does. :|
Have you tried the latest 2.2.10 kernel I posted last night? Does it mess up also?

>
> Well i think putting Xautoconfig in the rc.local file is still a good
> idea.
>

Not if you make changes to the XF86Config file for the USB xkb stuff. Xautoconfig
will mess it all up and switch it back to PC settings. There is a warning in the
Kernel HOWTO about this when setting up the xkb settings.

-Robert
mailto:rshaw@inficad.com
http://www.inficad.com/~rshaw/


[[ 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. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: BootX enhancement request

[Robert Shaw]

> This, BETA, driver. :)

Yeah, but it works, and it's much faster than the plain frame buffer device. :)

> What, aty128fb?  It's beta and not done.  You're prolly better off using
> No Video Driver, unles you're gonna play w/ the source (Anthony, speak up
> if i'm wrong). :)

It may be beta, but it works just fine. I've had several users indicate it works
without any problems.

--
-Robert
mailto:rshaw@inficad.com
http://www.inficad.com/~rshaw/


[[ 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. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: BootX enhancement request

[Jerry Quinn]

>> "Tom" == Tom Rini <trini@disparity.net> writes:

 Tom> So you want BootX to be able to do what Monitors & Sound can do.  Either
 Tom> pick a mode there and use BootX from MacOS, or once 2.4.0 rolls around,
 Tom> specify video=aty128fb:1024x768@75 (or so).  There is no need for BootX
 Tom> to do this.

Probably more to the point, we should strive to provide some easy way of doing
it.  How do MacOS and Windows deal with the problem of different monitors and
resolutions?  I know on the Mac so far, I automatically get the available
resolutions, although Apple-style monitors have extra sense pins to provide
the info.

Ideally, I shouldn't have to ever think about my monitor or have to add
command line args to the kernel.  Such twiddling should be as rare as
possible. 

-- 
Jerry Quinn                             Tel: (514) 761-8737
jquinn@nortelnetworks.com               Fax: (514) 761-8505
Speech Recognition Research


[[ 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. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: BootX enhancement request

[David A. Gatwood]

On Mon, 23 Aug 1999, Jerry Quinn wrote:

> Probably more to the point, we should strive to provide some easy way of doing
> it.  How do MacOS and Windows deal with the problem of different monitors and
> resolutions?  I know on the Mac so far, I automatically get the available
> resolutions, although Apple-style monitors have extra sense pins to provide
> the info.
> 
> Ideally, I shouldn't have to ever think about my monitor or have to add
> command line args to the kernel.  Such twiddling should be as rare as
> possible. 

Feel free to look at the code MkLinux hass to read the sense pins.... 
Granted, it's not actually being _used_ for anything, since MkLinux
doesn't change resolution, but it's there in the original PDM video
driver.  There will obviously be differences for other video hardware, but
it _might_ at least provide some useful inspiration or something.


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. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: BootX enhancement request

[brad allison]

On Mon, 23 Aug 1999, Robert Shaw wrote:

> > This, BETA, driver. :)
> 
> 
> It may be beta, but it works just fine. I've had several users indicate it works
> without any problems.
> 

I'm using it. 

Works great.  I've got a G3 450mhz (rev2) and a SGI 21" monitor.  

I tested the precompiled 2.2.6 and the 2.2.10 off Shaw's site.

The 2.2.6 kernel worked without having to do anything special.  The 2.2.10
kernel needed the kernel arguements to synch to my monitor.

-b


--
AOL SAPI 		                        703.265.0908     AIM:jackal242
http://jackal.fudge.org        `I was never more certain of how far away I was
from my goal than when I was standing right beside it.' - Ethan Hawke, Gattaca


[[ 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. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: BootX enhancement request

[Peter Chang]

Note: I'm not really active on the linuxppc-dev list (read: lurker), 
but I assume that all of the people on the 'to' list are on the list 
so I've trimmed it back to just the list.

> >> "Tom" == Tom Rini <trini@disparity.net> writes:
>
> Tom> So you want BootX to be able to do what Monitors & Sound can do.  Either
> Tom> pick a mode there and use BootX from MacOS, or once 2.4.0 rolls around,
> Tom> specify video=aty128fb:1024x768@75 (or so).  There is no need for BootX
> Tom> to do this.

I agree w/ this, if mostly because bootX would either need to do a 
lot of querying to determine what the board/monitor combo could do or 
there would be yet another list of supportable modes that might get 
out of sync w/ what's already in the X config stuff.

At 16:56 -0400 08.23.1999, Jerry Quinn wrote:
>How do MacOS and Windows deal with the problem of different monitors and
>resolutions?  I know on the Mac so far, I automatically get the available
>resolutions, although Apple-style monitors have extra sense pins to provide
>the info.

W/ the coming of win9x, the pnp stuff wants to load 'extra' 
information about monitors etc taht it detects. This information 
'overrides' any monitor sense stuff that might be present (I've never 
seen a pc monitor like this), and restricts the list of availible 
modes presented to the user. I've since lost the brain cells involved 
(thank goodness), but you can 'hand edit' the .inf file (or whatever) 
to get modes that you know the monitor supports but that are not 
advertised. (Well, my co-workers at 3dfx and I would do this because 
we 'knew' our brand new viewsonic monitors could do a lot more than 
whatever appeared in the list).

I think that the lack of sense pins for normal vga connectors is part 
of the reason why windows still asks if the test pattern appears 
correctly on the monitor. It knows what the card can support, but not 
whether the user is using some crappy monitor that can't synch.

\p

---
We all enter this world in the same way:
naked; screaming; soaked in blood.
But if you live your life right, that kind of
thing doesn't have to stop there. -- Dana Gould

[[ 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. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: BootX enhancement request

[anthony tong]

Tom Rini (Mon, Aug 23, 1999 at 04:27:46PM -0400):
> > I think you missed my point.  Don't get me wrong, that's cool to know.
> > But I was thinking more along the lines of a drop down menu to set the
> > resolution from BootX rather than cryptic kernel arguements.
> 
> So you want BootX to be able to do what Monitors & Sound can do.  Either
> pick a mode there and use BootX from MacOS, or once 2.4.0 rolls around,
> specify video=aty128fb:1024x768@75 (or so).  There is no need for BootX to
> do this.

If you have a version of MacOS that saves the monitor mode in nvram,
you shouldn't need to give any kernel arguments. Alternatively you
can use the linuxpmac tool nvvideo to set this.

It should be simple to add modedb support for the time being as well.

> > It seems the 2.2.10 kernel will not sync to the video settings at all
> > without the kernel arguements.

The default (without kernel arguments) is 640x480-60, unless you have
a video mode already set in nvram.

> What, aty128fb?  It's beta and not done.  You're prolly better off using
> No Video Driver, unles you're gonna play w/ the source (Anthony, speak up
> if i'm wrong). :)

If it works, use it, if not, send me an email. :)


[[ 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. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: BootX enhancement request

[Paul Mackerras]

anthony tong <atong@uiuc.edu> wrote:

> If you have a version of MacOS that saves the monitor mode in nvram,
> you shouldn't need to give any kernel arguments. Alternatively you
> can use the linuxpmac tool nvvideo to set this.

Yep.  There are two problems at the moment, which I should get off my
butt and fix. :-)

The first is that the current machines use a different structure for
nvram, based on the CHRP spec, which means that just using a fixed
offset in nvram doesn't work.  In fact it seems like macos adds a OF
property with a really strange encoding to store arbitrary bits of
information for the device drivers for arbitrary devices.

The second is that macos is now using mode numbers > 20.  I haven't
worked out the correspondence yet.

Paul.

[[ 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. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: BootX enhancement request

[Tom Rini]

On Mon, 23 Aug 1999, Jerry Quinn wrote:

> >> "Tom" == Tom Rini <trini@disparity.net> writes:
> 
>  Tom> So you want BootX to be able to do what Monitors & Sound can do.  Either
>  Tom> pick a mode there and use BootX from MacOS, or once 2.4.0 rolls around,
>  Tom> specify video=aty128fb:1024x768@75 (or so).  There is no need for BootX
>  Tom> to do this.
> 
> Probably more to the point, we should strive to provide some easy way of doing
> it.  How do MacOS and Windows deal with the problem of different monitors and
> resolutions?  I know on the Mac so far, I automatically get the available
> resolutions, although Apple-style monitors have extra sense pins to provide
> the info.

Don't they both stick you at 640x480@60, and make you choose up from
there?  (I know I've seen waaay to many  640x480 PCs around in these dorms
lately).  There are ways to sense modes, and it is implemented in some
drivers (most, iirc)

> Ideally, I shouldn't have to ever think about my monitor or have to add
> command line args to the kernel.  Such twiddling should be as rare as
> possible. 

So set something in MacOS. :)

---
Tom Rini (TR1265)
http://gate.crashing.org/~trini/


[[ 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. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: BootX enhancement request

[Benjamin Herrenschmidt]

On Mon, Aug 23, 1999, Robert Shaw <robert.shaw@motorola.com> wrote:

>Ok, that's reasonable. Any thoughts Ben?

I could add a front-end to the various video=xxxx options, and eventually
I can try to find out which option to give the kernel based on queries to
the video driver, but this is not trivial. I'll look into this as soon as
I find some time to play with BootX.



-- 
           Perso. e-mail: <mailto:bh40@calva.net>
           Work   e-mail: <mailto:benh@mipsys.com>
BenH.      Web   : <http://calvaweb.calvacom.fr/bh40/>


[[ 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. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: BootX enhancement request

[Benjamin Herrenschmidt]

On Tue, Aug 24, 1999, Paul Mackerras <paulus@cs.anu.edu.au> wrote:


>Yep.  There are two problems at the moment, which I should get off my
>butt and fix. :-)
>
>The first is that the current machines use a different structure for
>nvram, based on the CHRP spec, which means that just using a fixed
>offset in nvram doesn't work.  In fact it seems like macos adds a OF
>property with a really strange encoding to store arbitrary bits of
>information for the device drivers for arbitrary devices.
>
>The second is that macos is now using mode numbers > 20.  I haven't
>worked out the correspondence yet.

MacOS no longer relies on the nvram setting. Video drivers are free to
put whatever they want in their own device tree node, and usually store
an nvram value for the mode there, but this is proprietary and depends on
the driver. MacOS itself now stores the various infos in a preferences
file. The old "Monitors" control panel still updates the old pram
location with a mode value but the meaning is not guaranteed (can be
driver specific).

-- 
           Perso. e-mail: <mailto:bh40@calva.net>
           Work   e-mail: <mailto:benh@mipsys.com>
BenH.      Web   : <http://calvaweb.calvacom.fr/bh40/>


[[ 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. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: BootX enhancement request

[Geert Uytterhoeven]

On Tue, 24 Aug 1999, Benjamin Herrenschmidt wrote:
> On Tue, Aug 24, 1999, Paul Mackerras <paulus@cs.anu.edu.au> wrote:
> >The second is that macos is now using mode numbers > 20.  I haven't
> >worked out the correspondence yet.
> 
> MacOS no longer relies on the nvram setting. Video drivers are free to
> put whatever they want in their own device tree node, and usually store
> an nvram value for the mode there, but this is proprietary and depends on
> the driver. MacOS itself now stores the various infos in a preferences
> file. The old "Monitors" control panel still updates the old pram
> location with a mode value but the meaning is not guaranteed (can be
> driver specific).

Thus I can remove the nvram code from atyfb?

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. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: BootX enhancement request

[Benjamin Herrenschmidt]

On Tue, Aug 24, 1999, Geert Uytterhoeven
<Geert.Uytterhoeven@cs.kuleuven.ac.be> wrote:

>Thus I can remove the nvram code from atyfb?

Depending on the version of MacOS, and if the user uses or not the old
"Monitors" control panel, it may still be useful. On my PowerBook, I
always had to set the resolution in the kernel command line, but I think
that the vram stuff still works on my 8500 (controlfb). 

I beleive the nvram code is useless on iMacs and blue G3s.

-- 
           Perso. e-mail: <mailto:bh40@calva.net>
           Work   e-mail: <mailto:benh@mipsys.com>
BenH.      Web   : <http://calvaweb.calvacom.fr/bh40/>

--GAG19404.935596886/motgate.mot.com--

[[ 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. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: BootX enhancement request

[David A. Gatwood]

On Tue, 24 Aug 1999, Benjamin Herrenschmidt wrote:

> MacOS no longer relies on the nvram setting. Video drivers are free to

That's not _entirely_ true.  The hardware itself relies on the nvram
setting in order to determine the initial startup mode before it starts
loading MacOS.  That's why you can do tricks with newer versions of MacOS
like have the preferences set to 1024x768 and the pram/nvram set to
640x480 and have it switch half-way into booting. (Makes it nice for
MkLinux on x100's where you have to be in 8-bit color, but don't want to
run MacOS that way.)  The Monitors & Sound CP does set the nvram value, at
least on some machines, unless it changed quite recently, but you
sometimes have to delete its prefs files to convince it to do so.


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. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: BootX enhancement request

[Benjamin Herrenschmidt]

On Tue, Aug 24, 1999, David A. Gatwood <dgatwood@mvista.com> wrote:

>That's not _entirely_ true.  The hardware itself relies on the nvram
>setting in order to determine the initial startup mode before it starts
>loading MacOS.  That's why you can do tricks with newer versions of MacOS
>like have the preferences set to 1024x768 and the pram/nvram set to
>640x480 and have it switch half-way into booting. (Makes it nice for
>MkLinux on x100's where you have to be in 8-bit color, but don't want to
>run MacOS that way.)  The Monitors & Sound CP does set the nvram value, at
>least on some machines, unless it changed quite recently, but you
>sometimes have to delete its prefs files to convince it to do so.

Yes, you are right. But the fact remains that video drivers are free to
store this in any proprietary format they want and I had some trouble
getting this to work with iMacs and blue G3s. Also, this nvram setting is
limited to those "official" mode values, but the driver is free to
implement completely different modes, and there's also some support for
DCC slowly appearing in MacOS. I don't think we can rely reliably on this
nvram value.

What I could eventually do is to add code to BootX that asks the driver
about the current mode (the driver should be able to return me all sorts
of informations, including some, but not all, of the timings) and build a
kernel command line with those. We should find something generic since
I'm not sure I can easily find out which kind of driver to use on the
command line (atyfb, platinumfb, controlfb, ...)

I have plans to extend BootX so that i can also setup OF environement
variables for quik-based booting. It would be able to setup those infos
there too. I'll look into this as soon as I have a new hard drive for my
8500 (the old one joined my pile of dead HDs last week, I'll soon be able
to make some kind of modern art with all those HDs ;-).

-- 
           Perso. e-mail: <mailto:bh40@calva.net>
           Work   e-mail: <mailto:benh@mipsys.com>
BenH.      Web   : <http://calvaweb.calvacom.fr/bh40/>


[[ 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. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: BootX enhancement request

[David Riley]

Benjamin Herrenschmidt wrote:

> On Mon, Aug 23, 1999, Robert Shaw <robert.shaw@motorola.com> wrote:
>
> >Ok, that's reasonable. Any thoughts Ben?
>
> I could add a front-end to the various video=xxxx options, and eventually
> I can try to find out which option to give the kernel based on queries to
> the video driver, but this is not trivial. I'll look into this as soon as
> I find some time to play with BootX.

Some of the drivers don't do video=xxxx.  I know controlfb doesn't.  Is there
a _good_ reason for this, or does controlfb just not like me?


--
--"Your mouse has been moved.  Windows 95 must be restarted for change to take
effect."


[[ 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. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: BootX enhancement request

[Paul Mackerras]

Geert Uytterhoeven <Geert.Uytterhoeven@cs.kuleuven.ac.be> wrote:

> Thus I can remove the nvram code from atyfb?

Well, what's there doesn't seem to be much use.  OTOH, we really do
need something to make it less likely that a newbie will be confronted
by a blank screen because they forgot to put "video=atyfb:vmode:17" in
their kernel command line.  Maybe it should look at the registers and
see if the chip is already running, and if so, just use whatever
timings the chip is currently set to (as long as they look sane).  Or
maybe there needs to be some intelligence somewhere that looks at the
`compatible' property on the device-tree root node and says "aha, an
iMac, default to 1024x768@75Hz".

I see that there properties called "ATY,DefaultMode" and
"ATY,DisplayMode" on the device-tree node for the ATI chip on my G3
desktop.  They both have the value 30 (0x1e).  I don't know what mode
30 is.

Paul.

[[ 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. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: BootX enhancement request

[Geert Uytterhoeven]

On Wed, 25 Aug 1999, Paul Mackerras wrote:
> Geert Uytterhoeven <Geert.Uytterhoeven@cs.kuleuven.ac.be> wrote:
> 
> > Thus I can remove the nvram code from atyfb?
> 
> Well, what's there doesn't seem to be much use.  OTOH, we really do
> need something to make it less likely that a newbie will be confronted
> by a blank screen because they forgot to put "video=atyfb:vmode:17" in
> their kernel command line.  Maybe it should look at the registers and
> see if the chip is already running, and if so, just use whatever
> timings the chip is currently set to (as long as they look sane).  Or
> maybe there needs to be some intelligence somewhere that looks at the
> `compatible' property on the device-tree root node and says "aha, an
> iMac, default to 1024x768@75Hz".

The default video mode should be chosen depending on the machine type.

> I see that there properties called "ATY,DefaultMode" and
> "ATY,DisplayMode" on the device-tree node for the ATI chip on my G3
> desktop.  They both have the value 30 (0x1e).  I don't know what mode
> 30 is.

Look at the OF `words' of that node. There should be a function to get the
supported video mode list.

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. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: BootX enhancement request

[Takashi Oe]

On Tue, 24 Aug 1999, David Riley wrote:

> Some of the drivers don't do video=xxxx.  I know controlfb doesn't.  Is there
> a _good_ reason for this, or does controlfb just not like me?

It's probably a simple oversight.  Last I checked,
controlfb does have the necessary code for "video=...", while
drivers/video/fbmem.c lacks an entry for controlfb to actually activate
the code.

Takashi Oe


[[ 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. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: BootX enhancement request

[Daniel Jacobowitz]

On Wed, Aug 25, 1999 at 07:49:34PM -0500, Takashi Oe wrote:
> 
> On Tue, 24 Aug 1999, David Riley wrote:
> 
> > Some of the drivers don't do video=xxxx.  I know controlfb doesn't.  Is there
> > a _good_ reason for this, or does controlfb just not like me?
> 
> It's probably a simple oversight.  Last I checked,
> controlfb does have the necessary code for "video=...", while
> drivers/video/fbmem.c lacks an entry for controlfb to actually activate
> the code.

Translation - I'm being far too lazy.  I have some other work for the
controlfb underway, and I'm hoping to make some progress.

Dan

/--------------------------------\  /--------------------------------\
|       Daniel Jacobowitz        |__|        SCS Class of 2002       |
|   Debian GNU/Linux Developer    __    Carnegie Mellon University   |
|         dan@debian.org         |  |       dmj+@andrew.cmu.edu      |
\--------------------------------/  \--------------------------------/

[[ 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. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: BootX enhancement request

[Geert Uytterhoeven]

On Wed, 25 Aug 1999, Takashi Oe wrote:
> On Tue, 24 Aug 1999, David Riley wrote:
> > Some of the drivers don't do video=xxxx.  I know controlfb doesn't.  Is there
> > a _good_ reason for this, or does controlfb just not like me?
> 
> It's probably a simple oversight.  Last I checked,
> controlfb does have the necessary code for "video=...", while
> drivers/video/fbmem.c lacks an entry for controlfb to actually activate
> the code.

Fixed this in vger, and sent a patch to Linus.

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. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: BootX enhancement request

[David Riley]

Geert Uytterhoeven wrote:

> On Wed, 25 Aug 1999, Takashi Oe wrote:
> > On Tue, 24 Aug 1999, David Riley wrote:
> > > Some of the drivers don't do video=xxxx.  I know controlfb doesn't.  Is there
> > > a _good_ reason for this, or does controlfb just not like me?
> >
> > It's probably a simple oversight.  Last I checked,
> > controlfb does have the necessary code for "video=...", while
> > drivers/video/fbmem.c lacks an entry for controlfb to actually activate
> > the code.
>
> Fixed this in vger, and sent a patch to Linus.

Neat.  Will there ever be a way to do vmode 14?


--
--"Your mouse has been moved.  Windows 95 must be restarted for change to take
effect."


[[ 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. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: BootX enhancement request

[brad allison]

Well the whole point of this was to get around having to boot into MacOS,
set resolution, call bootX, boot single user, Xautoconfig, init 5, just to
change your resolution.

Solaris2.7 has that nice m64config command that lets you set your
resolution and color depth on the command line, then you kill and restart
X and it takes effect.

It would be really cool if linuxppc had something like that.

Does it?

-b




On Tue, 24 Aug 1999, Benjamin Herrenschmidt wrote:

> 
> On Tue, Aug 24, 1999, David A. Gatwood <dgatwood@mvista.com> wrote:
> 
> >That's not _entirely_ true.  The hardware itself relies on the nvram
> >setting in order to determine the initial startup mode before it starts
> >loading MacOS.  That's why you can do tricks with newer versions of MacOS
> >like have the preferences set to 1024x768 and the pram/nvram set to
> >640x480 and have it switch half-way into booting. (Makes it nice for
> >MkLinux on x100's where you have to be in 8-bit color, but don't want to
> >run MacOS that way.)  The Monitors & Sound CP does set the nvram value, at
> >least on some machines, unless it changed quite recently, but you
> >sometimes have to delete its prefs files to convince it to do so.
> 
> Yes, you are right. But the fact remains that video drivers are free to
> store this in any proprietary format they want and I had some trouble
> getting this to work with iMacs and blue G3s. Also, this nvram setting is
> limited to those "official" mode values, but the driver is free to
> implement completely different modes, and there's also some support for
> DCC slowly appearing in MacOS. I don't think we can rely reliably on this
> nvram value.
> 
> What I could eventually do is to add code to BootX that asks the driver
> about the current mode (the driver should be able to return me all sorts
> of informations, including some, but not all, of the timings) and build a
> kernel command line with those. We should find something generic since
> I'm not sure I can easily find out which kind of driver to use on the
> command line (atyfb, platinumfb, controlfb, ...)
> 
> I have plans to extend BootX so that i can also setup OF environement
> variables for quik-based booting. It would be able to setup those infos
> there too. I'll look into this as soon as I have a new hard drive for my
> 8500 (the old one joined my pile of dead HDs last week, I'll soon be able
> to make some kind of modern art with all those HDs ;-).
> 
> -- 
>            Perso. e-mail: <mailto:bh40@calva.net>
>            Work   e-mail: <mailto:benh@mipsys.com>
> BenH.      Web   : <http://calvaweb.calvacom.fr/bh40/>
> 
> 

--
AOL SAPI 		                        703.265.0908     AIM:jackal242
http://jackal.fudge.org        `I was never more certain of how far away I was
from my goal than when I was standing right beside it.' - Ethan Hawke, Gattaca

[[ 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. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: BootX enhancement request

[Tom Rini]

On Tue, 24 Aug 1999, Geert Uytterhoeven wrote:

> 
> On Tue, 24 Aug 1999, Benjamin Herrenschmidt wrote:
> > On Tue, Aug 24, 1999, Paul Mackerras <paulus@cs.anu.edu.au> wrote:
> > >The second is that macos is now using mode numbers > 20.  I haven't
> > >worked out the correspondence yet.
> > 
> > MacOS no longer relies on the nvram setting. Video drivers are free to
> > put whatever they want in their own device tree node, and usually store
> > an nvram value for the mode there, but this is proprietary and depends on
> > the driver. MacOS itself now stores the various infos in a preferences
> > file. The old "Monitors" control panel still updates the old pram
> > location with a mode value but the meaning is not guaranteed (can be
> > driver specific).
> 
> Thus I can remove the nvram code from atyfb?

Why?  It works fine on lots of older machines w/ ati cards and older MacOS
versions.  If you remove it I can garrenty people will notice and
complain.

---
Tom Rini (TR1265)
http://gate.crashing.org/~trini/


[[ 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. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: BootX enhancement request

[Benjamin Herrenschmidt]

On Thu, Aug 26, 1999, Tom Rini <trini@kernel.crashing.org> wrote:

>> Thus I can remove the nvram code from atyfb?
>
>Why?  It works fine on lots of older machines w/ ati cards and older MacOS
>versions.  If you remove it I can garrenty people will notice and
>complain.

We should get rid of it for atyfb once we have DDC working. According to
Apple, all machines with ATI controllers are using DDC now. The nvram
setting would still be useful for the older video controllers.

-- 
           Perso. e-mail: <mailto:bh40@calva.net>
           Work   e-mail: <mailto:benh@mipsys.com>
BenH.      Web   : <http://calvaweb.calvacom.fr/bh40/>

[[ 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. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: BootX enhancement request

[Geert Uytterhoeven]

On Fri, 27 Aug 1999, Benjamin Herrenschmidt wrote:
> On Thu, Aug 26, 1999, Tom Rini <trini@kernel.crashing.org> wrote:
> 
> >> Thus I can remove the nvram code from atyfb?
> >
> >Why?  It works fine on lots of older machines w/ ati cards and older MacOS
> >versions.  If you remove it I can garrenty people will notice and
> >complain.
> 
> We should get rid of it for atyfb once we have DDC working. According to
> Apple, all machines with ATI controllers are using DDC now. The nvram
> setting would still be useful for the older video controllers.

The NVRAM code should be separated from atyfb, so it can be used by all Mac
drivers.

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. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]