convert_to_ints() converts all the string resolutions in the resolutions property of the QEMU,VGA node and converts them to an int array.
Signed-off-by: John Arbuckle programmingkidx@gmail.com --- arch/ppc/qemu/init.c | 82 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 82 insertions(+)
diff --git a/arch/ppc/qemu/init.c b/arch/ppc/qemu/init.c index 6f21814..b6c7db0 100644 --- a/arch/ppc/qemu/init.c +++ b/arch/ppc/qemu/init.c @@ -619,6 +619,83 @@ id_cpu(void) } }
+ +/* convert ASCII string to number */ +static int atoi(const char *str) +{ + int result = 0; + while (*str) { + result = result * 10 + *str - '0'; + str++; + } + return result; +} + +void convert_to_ints(void); + +/* Converts the QEMU,VGA node's resolutions property to int's*/ +void convert_to_ints(void) +{ + const int max_buffer_size = 200; + char *orig_property; + char buffer[max_buffer_size]; + int index, count, value, addr, len; + char c; + + count = 0; + index = 0; + push_str("/pci/QEMU,VGA"); + fword("find-package"); + if (POP() == 0) { + fword("cr"); + push_str("convert-to-ints(): could not find package /pci/QEMU,VGA!"); + fword("type"); + fword("cr"); + return; + } + fword("active-package!"); + push_str("resolutions"); + fword("active-package"); + fword("get-package-property"); + if (POP() == -1) { + fword("cr"); + push_str("convert-to-ints(): could not find resolutions property!"); + fword("type"); + fword("cr"); + return; + } + len = POP(); + addr = POP(); + orig_property = (char *) malloc(len); + strncpy(orig_property, (char *)addr, len); + c = orig_property[0]; + while(c != '\0') { + if (c == 'x' || c == ',') { + buffer[index] = '\0'; + value = atoi(buffer); + count++; + if (count == 3) { + count = 1; + fword("encode+"); + continue; + } + PUSH(value); + fword("encode-int"); + index = -1; + } + else { + buffer[index] = c; + } + index++; + c = *(++orig_property); + } + fword("encode+"); + push_str("resolutions"); + fword("property"); + free(orig_property); +} + + static void go(void); unsigned int start_elf(unsigned long entry_point, unsigned long param);
@@ -632,6 +709,10 @@ go(void) fword("insert-copyright-property"); }
+ /* Used to support user specified resolutions */ + fword("copy-resolutions-property"); + convert_to_ints(); + feval("saved-program-state >sps.entry @"); addr = POP();
@@ -1078,3 +1159,4 @@ arch_of_init(void) bind_func("platform-boot", boot); bind_func("(go)", go); } +
On Sat, Sep 24, 2016 at 12:56:40PM -0400, Programmingkid wrote:
+/* Converts the QEMU,VGA node's resolutions property to int's*/
And store them, where?
+void convert_to_ints(void)
Since almost everything here just calls Forth words, can't you write it in actual Forth instead? ">number" is your friend.
Segher
On Sep 25, 2016, at 12:50 AM, Segher Boessenkool wrote:
On Sat, Sep 24, 2016 at 12:56:40PM -0400, Programmingkid wrote:
+/* Converts the QEMU,VGA node's resolutions property to int's*/
And store them, where?
In the resolutions property.
+void convert_to_ints(void)
Since almost everything here just calls Forth words, can't you write it in actual Forth instead? ">number" is your friend.
...but Forth is not. C is a lot easier to me to use than Forth.
On Sun, Sep 25, 2016 at 12:56:10AM -0400, Programmingkid wrote:
On Sep 25, 2016, at 12:50 AM, Segher Boessenkool wrote:
On Sat, Sep 24, 2016 at 12:56:40PM -0400, Programmingkid wrote:
+/* Converts the QEMU,VGA node's resolutions property to int's*/
And store them, where?
In the resolutions property.
In the resolutions property _where_?
This should be part of the comment here, of course.
+void convert_to_ints(void)
Since almost everything here just calls Forth words, can't you write it in actual Forth instead? ">number" is your friend.
...but Forth is not. C is a lot easier to me to use than Forth.
Then learn to use it better! :-)
Segher
On Sep 25, 2016, at 3:00 AM, Segher Boessenkool wrote:
On Sun, Sep 25, 2016 at 12:56:10AM -0400, Programmingkid wrote:
On Sep 25, 2016, at 12:50 AM, Segher Boessenkool wrote:
On Sat, Sep 24, 2016 at 12:56:40PM -0400, Programmingkid wrote:
+/* Converts the QEMU,VGA node's resolutions property to int's*/
And store them, where?
In the resolutions property.
In the resolutions property _where_?
In the /pci/QEMU,VGA node.
This should be part of the comment here, of course.
+void convert_to_ints(void)
Since almost everything here just calls Forth words, can't you write it in actual Forth instead? ">number" is your friend.
...but Forth is not. C is a lot easier to me to use than Forth.
Then learn to use it better! :-)
The convert_to_ints() function is just too complex for me to write it in Forth. C is so much nicer.
On 2016-Sep-25 10:45 , G 3 wrote:
+void convert_to_ints(void)
Since almost everything here just calls Forth words, can't you write it in actual Forth instead? ">number" is your friend.
...but Forth is not. C is a lot easier to me to use than Forth.
Then learn to use it better! :-)
The convert_to_ints() function is just too complex for me to write it in Forth. C is so much nicer.
See section 7.3.5.2 of IEEE 1275.
$number ( addr len -- true | n false ) Convert a string to a number
But aside from that, I'm not sure what the hesitation to use ascii strings in drivers comes from. It's standard practice. Video drivers are usually specified with device strings like "/pci@xx/display@1:1040x1024" or something like that, with the option argument being parsed at runtime (often it's a straight string comparison, but sometimes it needs more detailed parsing).
On Sep 25, 2016, at 11:03 AM, Tarl Neustaedter wrote:
On 2016-Sep-25 10:45 , G 3 wrote:
+void convert_to_ints(void)
Since almost everything here just calls Forth words, can't you write it in actual Forth instead? ">number" is your friend.
...but Forth is not. C is a lot easier to me to use than Forth.
Then learn to use it better! :-)
The convert_to_ints() function is just too complex for me to write it in Forth. C is so much nicer.
See section 7.3.5.2 of IEEE 1275.
$number ( addr len -- true | n false ) Convert a string to a number
But aside from that, I'm not sure what the hesitation to use ascii strings in drivers comes from. It's standard practice. Video drivers are usually specified with device strings like "/pci@xx/ display@1:1040x1024" or something like that, with the option argument being parsed at runtime (often it's a straight string comparison, but sometimes it needs more detailed parsing).
Good point.
On Sun, Sep 25, 2016 at 11:03:47AM -0400, Tarl Neustaedter wrote:
See section 7.3.5.2 of IEEE 1275.
$number ( addr len -- true | n false ) Convert a string to a number
number is much more useful. The description in 1275, well, sucks;
but it is a standard Forth word, and the description in the standard is fine.
But aside from that, I'm not sure what the hesitation to use ascii strings in drivers comes from. It's standard practice. Video drivers are usually specified with device strings like "/pci@xx/display@1:1040x1024" or something like that, with the option argument being parsed at runtime (often it's a straight string comparison, but sometimes it needs more detailed parsing).
This isn't about device arguments. This is about using strings in properties to denote an array of integers; which is just a dumb thing to do.
Segher
On Sep 25, 2016, at 11:22 AM, Segher Boessenkool wrote:
On Sun, Sep 25, 2016 at 11:03:47AM -0400, Tarl Neustaedter wrote:
See section 7.3.5.2 of IEEE 1275.
$number ( addr len -- true | n false ) Convert a string to a number
number is much more useful. The description in 1275, well, sucks;
but it is a standard Forth word, and the description in the standard is fine.
But aside from that, I'm not sure what the hesitation to use ascii strings in drivers comes from. It's standard practice. Video drivers are usually specified with device strings like "/pci@xx/ display@1:1040x1024" or something like that, with the option argument being parsed at runtime (often it's a straight string comparison, but sometimes it needs more detailed parsing).
This isn't about device arguments. This is about using strings in properties to denote an array of integers; which is just a dumb thing to do.
Using a string can make things easier for the user. If someone needs to see what values are in the resolutions property, he or she could do so easily with data stored in a string format.
On 2016-Sep-25 11:22 , Segher Boessenkool wrote:
This isn't about device arguments. This is about using strings in properties to denote an array of integers; which is just a dumb thing to do.
My understanding was that this was to allow specifying a display resolution from the command line.
The sequence I'd expect from that would be that the command line would affect the "output-device" property/non-volatile variable, by adding a specific resolution as an argument to the display device. The display driver would get the resolution as a device-arg string, which it could either parse or do a straight comparison against a list of supported resolutions. That's the way it generally worked on systems at Sun (now Oracle).
Creating properties in /options seems like a long way around to get the information from the command line into the driver.
On Sun, Sep 25, 2016 at 11:50:50AM -0400, Tarl Neustaedter wrote:
On 2016-Sep-25 11:22 , Segher Boessenkool wrote:
This isn't about device arguments. This is about using strings in properties to denote an array of integers; which is just a dumb thing to do.
My understanding was that this was to allow specifying a display resolution from the command line.
As far as I understand it it is about getting a list of supported resolutions?
Segher
On Sep 25, 2016, at 12:21 PM, Segher Boessenkool wrote:
On Sun, Sep 25, 2016 at 11:50:50AM -0400, Tarl Neustaedter wrote:
On 2016-Sep-25 11:22 , Segher Boessenkool wrote:
This isn't about device arguments. This is about using strings in properties to denote an array of integers; which is just a dumb thing to do.
My understanding was that this was to allow specifying a display resolution from the command line.
As far as I understand it it is about getting a list of supported resolutions?
That is exactly what is being done.
The copy-resolutions-property copies all the resolutions from the resolutions property of the options node to the resolutions property of the QEMU,VGA node. This is used to support specifying resolutions via the command-line.
Signed-off-by: John Arbuckle programmingkidx@gmail.com --- v2: Eliminated all if conditions.
arch/ppc/qemu/qemu.fs | 10 ++++++++++ 1 file changed, 10 insertions(+)
diff --git a/arch/ppc/qemu/qemu.fs b/arch/ppc/qemu/qemu.fs index 3d99a34..b53115a 100644 --- a/arch/ppc/qemu/qemu.fs +++ b/arch/ppc/qemu/qemu.fs @@ -138,3 +138,13 @@ variable keyboard-phandle 0 keyboard-phandle ! 3drop 0 then ; + +\ Copies the resolutions property from the /options node to QEMU,VGA node + +: copy-resolutions-property ( -- ) + " /options" find-device + " resolutions" active-package get-package-property + abort" copy-resolutions-property: Failed to find resolutions property!" + " /pci/QEMU,VGA" find-device + " resolutions" property +;
On 26/09/16 18:05, Programmingkid wrote:
The copy-resolutions-property copies all the resolutions from the resolutions property of the options node to the resolutions property of the QEMU,VGA node. This is used to support specifying resolutions via the command-line.
Signed-off-by: John Arbuckle programmingkidx@gmail.com
v2: Eliminated all if conditions.
arch/ppc/qemu/qemu.fs | 10 ++++++++++ 1 file changed, 10 insertions(+)
diff --git a/arch/ppc/qemu/qemu.fs b/arch/ppc/qemu/qemu.fs index 3d99a34..b53115a 100644 --- a/arch/ppc/qemu/qemu.fs +++ b/arch/ppc/qemu/qemu.fs @@ -138,3 +138,13 @@ variable keyboard-phandle 0 keyboard-phandle ! 3drop 0 then ;
+\ Copies the resolutions property from the /options node to QEMU,VGA node
+: copy-resolutions-property ( -- )
- " /options" find-device
- " resolutions" active-package get-package-property
- abort" copy-resolutions-property: Failed to find resolutions property!"
- " /pci/QEMU,VGA" find-device
- " resolutions" property
+;
Some more general thoughts on the approach: I think that you're doing this the wrong way around. Rather than injecting the resolutions into the QEMU,VGA device, I think the better way is to alter QEMU,VGA.fs so that it searches for an optional "fb-modes" property under /options, parses it, and then sets its own encode-int property version.
Also you never replied if there was a way of reading the in-built resolutions from the QEMU VGA controller? If yes, let's grab the information from there. If not, then it would make sense to add the basic VGA/XGA resolutions into the QEMU,VGA device as default and then simply add any custom resolution to the end of the list.
Finally for reference take a look at the Sun Framebuffer FAQ at http://www.sunhelp.org/faq/FrameBuffer.html to check the format the mode string should be in (it seems to be the format eluded to earlier by Tarl) and also the parameter should perhaps be called "fb-mode" which is the name used by Apple's OF implementation.
ATB,
Mark.
On Oct 1, 2016, at 2:11 PM, Mark Cave-Ayland wrote:
On 26/09/16 18:05, Programmingkid wrote:
The copy-resolutions-property copies all the resolutions from the resolutions property of the options node to the resolutions property of the QEMU,VGA node. This is used to support specifying resolutions via the command-line.
Signed-off-by: John Arbuckle programmingkidx@gmail.com
v2: Eliminated all if conditions.
arch/ppc/qemu/qemu.fs | 10 ++++++++++ 1 file changed, 10 insertions(+)
diff --git a/arch/ppc/qemu/qemu.fs b/arch/ppc/qemu/qemu.fs index 3d99a34..b53115a 100644 --- a/arch/ppc/qemu/qemu.fs +++ b/arch/ppc/qemu/qemu.fs @@ -138,3 +138,13 @@ variable keyboard-phandle 0 keyboard-phandle ! 3drop 0 then ;
+\ Copies the resolutions property from the /options node to QEMU,VGA node
+: copy-resolutions-property ( -- )
- " /options" find-device
- " resolutions" active-package get-package-property
- abort" copy-resolutions-property: Failed to find resolutions property!"
- " /pci/QEMU,VGA" find-device
- " resolutions" property
+;
Some more general thoughts on the approach: I think that you're doing this the wrong way around. Rather than injecting the resolutions into the QEMU,VGA device, I think the better way is to alter QEMU,VGA.fs so that it searches for an optional "fb-modes" property under /options, parses it, and then sets its own encode-int property version.
I suppose this would only require a few changes to my patches. I just feel the word 'resolutions' is easier to remember and type than 'fb-modes'.
What is the advantage of doing things this way?
Also you never replied if there was a way of reading the in-built resolutions from the QEMU VGA controller? If yes, let's grab the information from there. If not, then it would make sense to add the basic VGA/XGA resolutions into the QEMU,VGA device as default and then simply add any custom resolution to the end of the list.
I'm sorry I didn't answer your question. I must have missed it. Do you know what file has these built-in resolutions? Currently I do not know a way to access these resolutions.
Finally for reference take a look at the Sun Framebuffer FAQ at http://www.sunhelp.org/faq/FrameBuffer.html to check the format the mode string should be in (it seems to be the format eluded to earlier by Tarl) and also the parameter should perhaps be called "fb-mode" which is the name used by Apple's OF implementation.
Is this the format: widthxheightxbitdepth ? I just think it is easier to specify only width and height. The monitors control panel in Mac OS 9 allows the user to switch the bitdepth at any resolution (within vram limits).
Do you have any documentation on the fb-mode property? I did a quick check on my Macintosh's video card node in open firmware and couldn't find this fb-mode property.
On 01/10/16 19:44, Programmingkid wrote:
On Oct 1, 2016, at 2:11 PM, Mark Cave-Ayland wrote:
On 26/09/16 18:05, Programmingkid wrote:
The copy-resolutions-property copies all the resolutions from the resolutions property of the options node to the resolutions property of the QEMU,VGA node. This is used to support specifying resolutions via the command-line.
Signed-off-by: John Arbuckle programmingkidx@gmail.com
v2: Eliminated all if conditions.
arch/ppc/qemu/qemu.fs | 10 ++++++++++ 1 file changed, 10 insertions(+)
diff --git a/arch/ppc/qemu/qemu.fs b/arch/ppc/qemu/qemu.fs index 3d99a34..b53115a 100644 --- a/arch/ppc/qemu/qemu.fs +++ b/arch/ppc/qemu/qemu.fs @@ -138,3 +138,13 @@ variable keyboard-phandle 0 keyboard-phandle ! 3drop 0 then ;
+\ Copies the resolutions property from the /options node to QEMU,VGA node
+: copy-resolutions-property ( -- )
- " /options" find-device
- " resolutions" active-package get-package-property
- abort" copy-resolutions-property: Failed to find resolutions property!"
- " /pci/QEMU,VGA" find-device
- " resolutions" property
+;
Some more general thoughts on the approach: I think that you're doing this the wrong way around. Rather than injecting the resolutions into the QEMU,VGA device, I think the better way is to alter QEMU,VGA.fs so that it searches for an optional "fb-modes" property under /options, parses it, and then sets its own encode-int property version.
I suppose this would only require a few changes to my patches. I just feel the word 'resolutions' is easier to remember and type than 'fb-modes'.
What is the advantage of doing things this way?
Well OpenBIOS has always been intended to be as close to real hardware implementations as possible, so if there is an existing standard we should use it.
Also you never replied if there was a way of reading the in-built resolutions from the QEMU VGA controller? If yes, let's grab the information from there. If not, then it would make sense to add the basic VGA/XGA resolutions into the QEMU,VGA device as default and then simply add any custom resolution to the end of the list.
I'm sorry I didn't answer your question. I must have missed it. Do you know what file has these built-in resolutions? Currently I do not know a way to access these resolutions.
You need to see if you can read this information somehow from the VGA contoller or via VBE.
Finally for reference take a look at the Sun Framebuffer FAQ at http://www.sunhelp.org/faq/FrameBuffer.html to check the format the mode string should be in (it seems to be the format eluded to earlier by Tarl) and also the parameter should perhaps be called "fb-mode" which is the name used by Apple's OF implementation.
Is this the format: widthxheightxbitdepth ? I just think it is easier to specify only width and height. The monitors control panel in Mac OS 9 allows the user to switch the bitdepth at any resolution (within vram limits).
Do you have any documentation on the fb-mode property? I did a quick check on my Macintosh's video card node in open firmware and couldn't find this fb-mode property.
Just google, since I own no PPC Mac hardware :)
ATB,
Mark.
On Oct 1, 2016, at 3:24 PM, Mark Cave-Ayland wrote:
On 01/10/16 19:44, Programmingkid wrote:
On Oct 1, 2016, at 2:11 PM, Mark Cave-Ayland wrote:
On 26/09/16 18:05, Programmingkid wrote:
The copy-resolutions-property copies all the resolutions from the resolutions property of the options node to the resolutions property of the QEMU,VGA node. This is used to support specifying resolutions via the command- line.
Signed-off-by: John Arbuckle programmingkidx@gmail.com
v2: Eliminated all if conditions.
arch/ppc/qemu/qemu.fs | 10 ++++++++++ 1 file changed, 10 insertions(+)
diff --git a/arch/ppc/qemu/qemu.fs b/arch/ppc/qemu/qemu.fs index 3d99a34..b53115a 100644 --- a/arch/ppc/qemu/qemu.fs +++ b/arch/ppc/qemu/qemu.fs @@ -138,3 +138,13 @@ variable keyboard-phandle 0 keyboard-phandle ! 3drop 0 then ;
+\ Copies the resolutions property from the /options node to QEMU,VGA node
+: copy-resolutions-property ( -- )
- " /options" find-device
- " resolutions" active-package get-package-property
- abort" copy-resolutions-property: Failed to find
resolutions property!"
- " /pci/QEMU,VGA" find-device
- " resolutions" property
+;
Some more general thoughts on the approach: I think that you're doing this the wrong way around. Rather than injecting the resolutions into the QEMU,VGA device, I think the better way is to alter QEMU,VGA.fs so that it searches for an optional "fb-modes" property under /options, parses it, and then sets its own encode-int property version.
I suppose this would only require a few changes to my patches. I just feel the word 'resolutions' is easier to remember and type than 'fb- modes'.
What is the advantage of doing things this way?
Well OpenBIOS has always been intended to be as close to real hardware implementations as possible, so if there is an existing standard we should use it.
Also you never replied if there was a way of reading the in-built resolutions from the QEMU VGA controller? If yes, let's grab the information from there. If not, then it would make sense to add the basic VGA/XGA resolutions into the QEMU,VGA device as default and then simply add any custom resolution to the end of the list.
I'm sorry I didn't answer your question. I must have missed it. Do you know what file has these built-in resolutions? Currently I do not know a way to access these resolutions.
You need to see if you can read this information somehow from the VGA contoller or via VBE.
I would think for a PCI VGA card any resolution information would be kept in either PCI configuration space or in a register. After looking at several of the VGA related files in QEMU, there does not appear to be a list of supported resolutions. I think using the fb-modes property is fine. I made the required changes to the VGA driver and was able to use all the resolutions in both Mac OS 9 and Mac OS X.
Finally for reference take a look at the Sun Framebuffer FAQ at http://www.sunhelp.org/faq/FrameBuffer.html to check the format the mode string should be in (it seems to be the format eluded to earlier by Tarl) and also the parameter should perhaps be called "fb-mode" which is the name used by Apple's OF implementation.
Is this the format: widthxheightxbitdepth ? I just think it is easier to specify only width and height. The monitors control panel in Mac OS 9 allows the user to switch the bitdepth at any resolution (within vram limits).
Do you have any documentation on the fb-mode property? I did a quick check on my Macintosh's video card node in open firmware and couldn't find this fb-mode property.
Just google, since I own no PPC Mac hardware :)
I tried that but didn't find anything relevant. I will accept your idea and use the fb-modes property in the QEMU,VGA node.
On 2016-Oct-1 14:11 , Mark Cave-Ayland wrote:
Finally for reference take a look at the Sun Framebuffer FAQ at http://www.sunhelp.org/faq/FrameBuffer.html to check the format the mode string should be in (it seems to be the format eluded to earlier by Tarl)
Yup. Looking at that, I'm reminded there are four variables for resolution: Height, Width, bits-per-pixel, and frequency (updates per second).
The usual answer for how this worked was that you specified a particular resolution at startup, and subsequent drivers looked up that resolution in their own tables. There wasn't anything about passing a list of resolutions in, it was _the_ specific resolution to use. The assumption is that when you picked the startup resolution, that was the resolution you intended to use, period.
On 01/10/16 20:35, Tarl Neustaedter wrote:
On 2016-Oct-1 14:11 , Mark Cave-Ayland wrote:
Finally for reference take a look at the Sun Framebuffer FAQ at http://www.sunhelp.org/faq/FrameBuffer.html to check the format the mode string should be in (it seems to be the format eluded to earlier by Tarl)
Yup. Looking at that, I'm reminded there are four variables for resolution: Height, Width, bits-per-pixel, and frequency (updates per second).
The usual answer for how this worked was that you specified a particular resolution at startup, and subsequent drivers looked up that resolution in their own tables. There wasn't anything about passing a list of resolutions in, it was _the_ specific resolution to use. The assumption is that when you picked the startup resolution, that was the resolution you intended to use, period.
Yes I think that's what I'm inclined to do - add the standard VGA/XGA resolutions along with the current custom resolution if specified.
ATB,
Mark.
On Sat, 2016-10-01 at 19:11 +0100, Mark Cave-Ayland wrote:
Also you never replied if there was a way of reading the in-built resolutions from the QEMU VGA controller? If yes, let's grab the information from there. If not, then it would make sense to add the basic VGA/XGA resolutions into the QEMU,VGA device as default and then simply add any custom resolution to the end of the list.
The emulated HW doesn't have a way to obtain a list of resultions, at least not that I know of.
Finally for reference take a look at the Sun Framebuffer FAQ at http://www.sunhelp.org/faq/FrameBuffer.html%C2%A0to check the format the mode string should be in (it seems to be the format eluded to earlier by Tarl) and also the parameter should perhaps be called "fb-mode" which is the name used by Apple's OF implementation.
On 2016-Oct-1 19:20 , Benjamin Herrenschmidt wrote:
The emulated HW doesn't have a way to obtain a list of resultions, at least not that I know of.
Sorry if I'm being repetitive here, but it seems I missed a major part of the conversation - by the time I got copied on the conversation, the assumption was that a list was needed.
*Why* does OpenBIOS need a list of resolutions?
It should need one resolution - the one it's told to use. Openbios won't be changing the resolution, so why would it care about resolutions it doesn't use?
On Oct 1, 2016, at 8:33 PM, Tarl Neustaedter wrote:
On 2016-Oct-1 19:20 , Benjamin Herrenschmidt wrote:
The emulated HW doesn't have a way to obtain a list of resultions, at least not that I know of.
Sorry if I'm being repetitive here, but it seems I missed a major part of the conversation - by the time I got copied on the conversation, the assumption was that a list was needed.
*Why* does OpenBIOS need a list of resolutions?
It should need one resolution - the one it's told to use. Openbios won't be changing the resolution, so why would it care about resolutions it doesn't use?
There is a VGA driver that was recently made that works with the Mac OS. This driver reports all the resolutions the emulated computer can handle. To make the driver as maintenance free as possible we have decided to move the reported list of resolutions to OpenBIOS. A control panel in the Mac OS list all of these resolutions. The user can then select one and use it.
On 2016-Oct-1 20:39 , G 3 wrote:
There is a VGA driver that was recently made that works with the Mac OS. This driver reports all the resolutions the emulated computer can handle. To make the driver as maintenance free as possible we have decided to move the reported list of resolutions to OpenBIOS. A control panel in the Mac OS list all of these resolutions. The user can then select one and use it.
Ah! So this has nothing to do with OpenBIOS or the VGA driver under it, it's a means of passing information from the outside entity into MacOS.
Does MacOS demand the list be a property of the VGA display node? If so, does it want it as a string or as an array of integers?
On Oct 1, 2016, at 8:42 PM, Tarl Neustaedter wrote:
On 2016-Oct-1 20:39 , G 3 wrote:
There is a VGA driver that was recently made that works with the Mac OS. This driver reports all the resolutions the emulated computer can handle. To make the driver as maintenance free as possible we have decided to move the reported list of resolutions to OpenBIOS. A control panel in the Mac OS list all of these resolutions. The user can then select one and use it.
Ah! So this has nothing to do with OpenBIOS or the VGA driver under it, it's a means of passing information from the outside entity into MacOS.
Does MacOS demand the list be a property of the VGA display node? If so, does it want it as a string or as an array of integers?
Actually the Mac OS gets all its information from the VGA driver. It would be the VGA driver that would read the list in OpenBIOS. Currently the VGA driver needs the list to an array of integers.
On 2016-Oct-1 20:47 , G 3 wrote:
Actually the Mac OS gets all its information from the VGA driver. It would be the VGA driver that would read the list in OpenBIOS. Currently the VGA driver needs the list to an array of integers.
O.k. - misunderstood. The new VGA driver is a MacOS driver, not a OpenBIOS driver. So we aren't booting standard MacOS, but a modified version.
The traditional way information is passed (for IEEE1275 in Sun/Oracle style) from the outside world into drivers/operating systems is with properties in either /chosen or /options. Properties in /options mimic NVRAM variables, looking like they might have been set by the previous iteration of an operating system - that's probably not ideal, it might appear that the client OS could set them, which wouldn't be the case. Properties in /chosen are places where firmware stores anything it determines at startup for use by later clients.
I would suggest in this case that /chosen would be your better location than a device node.
On Oct 1, 2016, at 9:05 PM, Tarl Neustaedter wrote:
On 2016-Oct-1 20:47 , G 3 wrote:
Actually the Mac OS gets all its information from the VGA driver. It would be the VGA driver that would read the list in OpenBIOS. Currently the VGA driver needs the list to an array of integers.
O.k. - misunderstood. The new VGA driver is a MacOS driver, not a OpenBIOS driver. So we aren't booting standard MacOS, but a modified version.
Actually we are booting a standard (unmodified) Mac OS.
The traditional way information is passed (for IEEE1275 in Sun/Oracle style) from the outside world into drivers/operating systems is with properties in either /chosen or /options. Properties in /options mimic NVRAM variables, looking like they might have been set by the previous iteration of an operating system - that's probably not ideal, it might appear that the client OS could set them, which wouldn't be the case. Properties in /chosen are places where firmware stores anything it determines at startup for use by later clients.
I would suggest in this case that /chosen would be your better location than a device node.
I so wanted to use the /options node, but there is some bug between OpenBIOS, QEMU, or Mac OS X that prevents Mac OS X from seeing anything in the NVRAM. When Mac OS 9 boots it always displays this error message pertaining to the NVRAM. So far no one knows how to fix this problem, so using a property in the QEMU,VGA node is what works.
On 02/10/16 02:05, Tarl Neustaedter wrote:
On 2016-Oct-1 20:47 , G 3 wrote:
Actually the Mac OS gets all its information from the VGA driver. It would be the VGA driver that would read the list in OpenBIOS. Currently the VGA driver needs the list to an array of integers.
O.k. - misunderstood. The new VGA driver is a MacOS driver, not a OpenBIOS driver. So we aren't booting standard MacOS, but a modified version.
The traditional way information is passed (for IEEE1275 in Sun/Oracle style) from the outside world into drivers/operating systems is with properties in either /chosen or /options. Properties in /options mimic NVRAM variables, looking like they might have been set by the previous iteration of an operating system - that's probably not ideal, it might appear that the client OS could set them, which wouldn't be the case. Properties in /chosen are places where firmware stores anything it determines at startup for use by later clients.
I would suggest in this case that /chosen would be your better location than a device node.
At the moment the screen width/height/depth can be found in 2 places: i) via Bochs VBE extensions and ii) the QEMU fw_cfg interface.
During PROM startup the latter is used to construct the width, height and depth properties for the QEMU,VGA device node which is currently how this is exposed to the guest.
ATB,
Mark.
On 02/10/16 00:20, Benjamin Herrenschmidt wrote:
On Sat, 2016-10-01 at 19:11 +0100, Mark Cave-Ayland wrote:
Also you never replied if there was a way of reading the in-built resolutions from the QEMU VGA controller? If yes, let's grab the information from there. If not, then it would make sense to add the basic VGA/XGA resolutions into the QEMU,VGA device as default and then simply add any custom resolution to the end of the list.
The emulated HW doesn't have a way to obtain a list of resultions, at least not that I know of.
I know it's not available through VBE, but was hoping there might be some kind of EDID emulation on the QEMU VGA controller.
Other than that, can the MacOS driver environment read/write configuration to disk? If so, all we need to do on boot is read the current resolution via VBE and/or the QEMU,VGA device and we are good.
The first time the driver runs it can write a config file of default VGA/XGA resolutions to disk which power users can alter themselves to add further options on subsequent reboots if required.
ATB,
Mark.
On Sun, 2016-10-02 at 12:31 +0100, Mark Cave-Ayland wrote:
On 02/10/16 00:20, Benjamin Herrenschmidt wrote:
On Sat, 2016-10-01 at 19:11 +0100, Mark Cave-Ayland wrote:
Also you never replied if there was a way of reading the in-built resolutions from the QEMU VGA controller? If yes, let's grab the information from there. If not, then it would make sense to add the basic VGA/XGA resolutions into the QEMU,VGA device as default and then simply add any custom resolution to the end of the list.
The emulated HW doesn't have a way to obtain a list of resultions, at least not that I know of.
I know it's not available through VBE, but was hoping there might be some kind of EDID emulation on the QEMU VGA controller.
Other than that, can the MacOS driver environment read/write configuration to disk? If so, all we need to do on boot is read the current resolution via VBE and/or the QEMU,VGA device and we are good.
No, but it can access the NVRAM if we emulate it properly
The first time the driver runs it can write a config file of default VGA/XGA resolutions to disk which power users can alter themselves to add further options on subsequent reboots if required.
ATB,
Mark.
On Sep 25, 2016, at 11:50 AM, Tarl Neustaedter wrote:
On 2016-Sep-25 11:22 , Segher Boessenkool wrote:
This isn't about device arguments. This is about using strings in properties to denote an array of integers; which is just a dumb thing to do.
My understanding was that this was to allow specifying a display resolution from the command line.
The sequence I'd expect from that would be that the command line would affect the "output-device" property/non-volatile variable, by adding a specific resolution as an argument to the display device. The display driver would get the resolution as a device-arg string, which it could either parse or do a straight comparison against a list of supported resolutions. That's the way it generally worked on systems at Sun (now Oracle).
Creating properties in /options seems like a long way around to get the information from the command line into the driver.
The only way I know to send a command-line argument to the VGA driver is by using the "-prom-env" command-line option. The data would take this route:
QEMU -> OpenBIOS -> VGA driver
Do you have a short-cut?
-
Benjamin Herrenschmidt -
G 3 -
Mark Cave-Ayland -
Programmingkid
-
Segher Boessenkool -
Tarl Neustaedter