* [Qemu-devel] Questions about EDID @ 2019-02-25 14:05 G 3 2019-02-25 15:26 ` Gerd Hoffmann 0 siblings, 1 reply; 16+ messages in thread From: G 3 @ 2019-02-25 14:05 UTC (permalink / raw) To: Gerd Hoffmann, qemu-devel qemu-devel Hi Gerd, I was wondering if you have made any documentation for your EDID patches. If you have could you provide a link please? Also could a feature be added that allows the user to specify resolutions to be made available to the guest? Maybe it could work like this: -device VGA,edid=on,res=1366x768,7680x4320 Thank you. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Qemu-devel] Questions about EDID 2019-02-25 14:05 [Qemu-devel] Questions about EDID G 3 @ 2019-02-25 15:26 ` Gerd Hoffmann 2019-02-26 2:49 ` Programmingkid 0 siblings, 1 reply; 16+ messages in thread From: Gerd Hoffmann @ 2019-02-25 15:26 UTC (permalink / raw) To: G 3; +Cc: qemu-devel qemu-devel On Mon, Feb 25, 2019 at 09:05:30AM -0500, G 3 wrote: > Hi Gerd, I was wondering if you have made any documentation for your EDID > patches. If you have could you provide a link please? No docs. > Also could a feature be added that allows the user to specify resolutions > to be made available to the guest? > > Maybe it could work like this: -device VGA,edid=on,res=1366x768,7680x4320 A single resolution works (via xres + yres properties). cheers, Gerd ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Qemu-devel] Questions about EDID 2019-02-25 15:26 ` Gerd Hoffmann @ 2019-02-26 2:49 ` Programmingkid 2019-02-26 6:43 ` Gerd Hoffmann 0 siblings, 1 reply; 16+ messages in thread From: Programmingkid @ 2019-02-26 2:49 UTC (permalink / raw) To: Gerd Hoffmann; +Cc: qemu-devel qemu-devel > On Feb 25, 2019, at 10:26 AM, Gerd Hoffmann <kraxel@redhat.com> wrote: > > On Mon, Feb 25, 2019 at 09:05:30AM -0500, G 3 wrote: >> Hi Gerd, I was wondering if you have made any documentation for your EDID >> patches. If you have could you provide a link please? > > No docs. > >> Also could a feature be added that allows the user to specify resolutions >> to be made available to the guest? >> >> Maybe it could work like this: -device VGA,edid=on,res=1366x768,7680x4320 > > A single resolution works (via xres + yres properties). Could you send an example of the xres and yres properties please? I tried this but it didn't work: -device VGA,edid=on,xres=999,yres=888 Thank you. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Qemu-devel] Questions about EDID 2019-02-26 2:49 ` Programmingkid @ 2019-02-26 6:43 ` Gerd Hoffmann 2019-02-26 21:11 ` G 3 0 siblings, 1 reply; 16+ messages in thread From: Gerd Hoffmann @ 2019-02-26 6:43 UTC (permalink / raw) To: Programmingkid; +Cc: qemu-devel qemu-devel On Mon, Feb 25, 2019 at 09:49:22PM -0500, Programmingkid wrote: > > > On Feb 25, 2019, at 10:26 AM, Gerd Hoffmann <kraxel@redhat.com> wrote: > > > > On Mon, Feb 25, 2019 at 09:05:30AM -0500, G 3 wrote: > >> Hi Gerd, I was wondering if you have made any documentation for your EDID > >> patches. If you have could you provide a link please? > > > > No docs. > > > >> Also could a feature be added that allows the user to specify resolutions > >> to be made available to the guest? > >> > >> Maybe it could work like this: -device VGA,edid=on,res=1366x768,7680x4320 > > > > A single resolution works (via xres + yres properties). > > Could you send an example of the xres and yres properties please? > I tried this but it didn't work: -device VGA,edid=on,xres=999,yres=888 That is correct. But you also need a guest driver with edid support. I think the macos driver got support for that, for linux support landed in the 5.0 devel cycle. cheers, Gerd ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Qemu-devel] Questions about EDID 2019-02-26 6:43 ` Gerd Hoffmann @ 2019-02-26 21:11 ` G 3 2019-02-27 5:27 ` Gerd Hoffmann 0 siblings, 1 reply; 16+ messages in thread From: G 3 @ 2019-02-26 21:11 UTC (permalink / raw) To: Gerd Hoffmann; +Cc: qemu-devel qemu-devel When I use edid=on, I do see a lot of extra resolutions available in Mac OS 9 and Mac OS X, just not the resolution I want to use. Is there some kind of rule like the resolution value has to be divisible by a certain number? On Tue, Feb 26, 2019 at 1:43 AM Gerd Hoffmann <kraxel@redhat.com> wrote: > On Mon, Feb 25, 2019 at 09:49:22PM -0500, Programmingkid wrote: > > > > > On Feb 25, 2019, at 10:26 AM, Gerd Hoffmann <kraxel@redhat.com> wrote: > > > > > > On Mon, Feb 25, 2019 at 09:05:30AM -0500, G 3 wrote: > > >> Hi Gerd, I was wondering if you have made any documentation for your > EDID > > >> patches. If you have could you provide a link please? > > > > > > No docs. > > > > > >> Also could a feature be added that allows the user to specify > resolutions > > >> to be made available to the guest? > > >> > > >> Maybe it could work like this: -device > VGA,edid=on,res=1366x768,7680x4320 > > > > > > A single resolution works (via xres + yres properties). > > > > Could you send an example of the xres and yres properties please? > > I tried this but it didn't work: -device VGA,edid=on,xres=999,yres=888 > > That is correct. But you also need a guest driver with edid support. > > I think the macos driver got support for that, for linux support landed > in the 5.0 devel cycle. > > cheers, > Gerd > > ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Qemu-devel] Questions about EDID 2019-02-26 21:11 ` G 3 @ 2019-02-27 5:27 ` Gerd Hoffmann 2019-02-27 21:22 ` Programmingkid 2019-02-28 5:01 ` Mark Cave-Ayland 0 siblings, 2 replies; 16+ messages in thread From: Gerd Hoffmann @ 2019-02-27 5:27 UTC (permalink / raw) To: G 3; +Cc: qemu-devel qemu-devel On Tue, Feb 26, 2019 at 04:11:06PM -0500, G 3 wrote: > When I use edid=on, I do see a lot of extra resolutions available in Mac OS > 9 and Mac OS X, just not the resolution I want to use. Is there some kind > of rule like the resolution value has to be divisible by a certain number? qemu doesn't have such a requirement. Might be the guest drivers have. Try making width/height multiple of 8 or 16. cheers, Gerd ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Qemu-devel] Questions about EDID 2019-02-27 5:27 ` Gerd Hoffmann @ 2019-02-27 21:22 ` Programmingkid 2019-02-28 5:01 ` Mark Cave-Ayland 1 sibling, 0 replies; 16+ messages in thread From: Programmingkid @ 2019-02-27 21:22 UTC (permalink / raw) To: Gerd Hoffmann; +Cc: qemu-devel qemu-devel > On Feb 27, 2019, at 12:27 AM, Gerd Hoffmann <kraxel@redhat.com> wrote: > > On Tue, Feb 26, 2019 at 04:11:06PM -0500, G 3 wrote: >> When I use edid=on, I do see a lot of extra resolutions available in Mac OS >> 9 and Mac OS X, just not the resolution I want to use. Is there some kind >> of rule like the resolution value has to be divisible by a certain number? > > qemu doesn't have such a requirement. > Might be the guest drivers have. > Try making width/height multiple of 8 or 16. I counted 10 more added resolutions when using your edid feature on Mac OS 9.2 and on Mac OS 10.4. But when I tried adding one using the xres/yres properties, it didn't work. What operating system do you see success on? What is your command line you use? I did try your suggestion by using 800x800 (16*50) resolution. It didn't work.' Thank you. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Qemu-devel] Questions about EDID 2019-02-27 5:27 ` Gerd Hoffmann 2019-02-27 21:22 ` Programmingkid @ 2019-02-28 5:01 ` Mark Cave-Ayland 2019-02-28 5:49 ` Gerd Hoffmann 2019-02-28 16:53 ` G 3 1 sibling, 2 replies; 16+ messages in thread From: Mark Cave-Ayland @ 2019-02-28 5:01 UTC (permalink / raw) To: Gerd Hoffmann, G 3; +Cc: qemu-devel qemu-devel On 27/02/2019 05:27, Gerd Hoffmann wrote: > On Tue, Feb 26, 2019 at 04:11:06PM -0500, G 3 wrote: >> When I use edid=on, I do see a lot of extra resolutions available in Mac OS >> 9 and Mac OS X, just not the resolution I want to use. Is there some kind >> of rule like the resolution value has to be divisible by a certain number? > > qemu doesn't have such a requirement. > Might be the guest drivers have. > Try making width/height multiple of 8 or 16. Right, at the moment all the MacOS driver does is parse the resolution list from the EDID and add them to the dropdown list - it doesn't support the xres and yres properties. The main reason for this that OpenBIOS currently makes use of the -g XxYxD parameter to set up the display resolution and bit depth, and AFAICT we currently only have access to the X and Y resolutions via the EDID blob. So it's not clear whether EDID can completely replace the existing mechanism yet. The other issue to contend with is that some machines such as SPARC will reject invalid bit depths (i.e. d != 8 || d != 24) during machine init to prevent screen corruption, and I'm not yet sure how to enforce this with EDID. ATB, Mark. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Qemu-devel] Questions about EDID 2019-02-28 5:01 ` Mark Cave-Ayland @ 2019-02-28 5:49 ` Gerd Hoffmann 2019-02-28 6:01 ` Mark Cave-Ayland 2019-02-28 16:53 ` G 3 1 sibling, 1 reply; 16+ messages in thread From: Gerd Hoffmann @ 2019-02-28 5:49 UTC (permalink / raw) To: Mark Cave-Ayland; +Cc: G 3, qemu-devel qemu-devel Hi, > Right, at the moment all the MacOS driver does is parse the resolution list from the > EDID and add them to the dropdown list - it doesn't support the xres and yres properties. > The main reason for this that OpenBIOS currently makes use of the -g XxYxD parameter > to set up the display resolution and bit depth, and AFAICT we currently only have > access to the X and Y resolutions via the EDID blob. So it's not clear whether EDID > can completely replace the existing mechanism yet. EDID can only propagate x + y, not depth. cheers, Gerd ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Qemu-devel] Questions about EDID 2019-02-28 5:49 ` Gerd Hoffmann @ 2019-02-28 6:01 ` Mark Cave-Ayland 2019-02-28 6:38 ` Gerd Hoffmann 0 siblings, 1 reply; 16+ messages in thread From: Mark Cave-Ayland @ 2019-02-28 6:01 UTC (permalink / raw) To: Gerd Hoffmann; +Cc: G 3, qemu-devel qemu-devel On 28/02/2019 05:49, Gerd Hoffmann wrote: > Hi, > >> Right, at the moment all the MacOS driver does is parse the resolution list from the >> EDID and add them to the dropdown list - it doesn't support the xres and yres properties. > >> The main reason for this that OpenBIOS currently makes use of the -g XxYxD parameter >> to set up the display resolution and bit depth, and AFAICT we currently only have >> access to the X and Y resolutions via the EDID blob. So it's not clear whether EDID >> can completely replace the existing mechanism yet. > > EDID can only propagate x + y, not depth. Right - my quick reading online was that there was very limited depth capability, and certainly nothing greater than 16-bit. Rather than duplicating these parameters, would it make sense to come up with a custom QEMU extension block to hold the extra depth information? ATB, Mark. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Qemu-devel] Questions about EDID 2019-02-28 6:01 ` Mark Cave-Ayland @ 2019-02-28 6:38 ` Gerd Hoffmann 2019-02-28 16:57 ` Mark Cave-Ayland 0 siblings, 1 reply; 16+ messages in thread From: Gerd Hoffmann @ 2019-02-28 6:38 UTC (permalink / raw) To: Mark Cave-Ayland; +Cc: G 3, qemu-devel qemu-devel On Thu, Feb 28, 2019 at 06:01:30AM +0000, Mark Cave-Ayland wrote: > On 28/02/2019 05:49, Gerd Hoffmann wrote: > > > Hi, > > > >> Right, at the moment all the MacOS driver does is parse the resolution list from the > >> EDID and add them to the dropdown list - it doesn't support the xres and yres properties. > > > >> The main reason for this that OpenBIOS currently makes use of the -g XxYxD parameter > >> to set up the display resolution and bit depth, and AFAICT we currently only have > >> access to the X and Y resolutions via the EDID blob. So it's not clear whether EDID > >> can completely replace the existing mechanism yet. > > > > EDID can only propagate x + y, not depth. > > Right - my quick reading online was that there was very limited depth capability, and > certainly nothing greater than 16-bit. That is another depth, it's the bits *per color* the monitor is able to display. > Rather than duplicating these parameters, would it make sense to come up with a > custom QEMU extension block to hold the extra depth information? Well, not really. EDID is about monitor capabilities. The monitor will see 8 bit per color channel, no matter whenever your GPU composes that signal using a 8bpp mode + color palette or 24bpp mode with direct color. cheers, Gerd ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Qemu-devel] Questions about EDID 2019-02-28 6:38 ` Gerd Hoffmann @ 2019-02-28 16:57 ` Mark Cave-Ayland 2019-03-01 5:43 ` Gerd Hoffmann 0 siblings, 1 reply; 16+ messages in thread From: Mark Cave-Ayland @ 2019-02-28 16:57 UTC (permalink / raw) To: Gerd Hoffmann; +Cc: G 3, qemu-devel qemu-devel On 28/02/2019 06:38, Gerd Hoffmann wrote: > On Thu, Feb 28, 2019 at 06:01:30AM +0000, Mark Cave-Ayland wrote: >> On 28/02/2019 05:49, Gerd Hoffmann wrote: >> >>> Hi, >>> >>>> Right, at the moment all the MacOS driver does is parse the resolution list from the >>>> EDID and add them to the dropdown list - it doesn't support the xres and yres properties. >>> >>>> The main reason for this that OpenBIOS currently makes use of the -g XxYxD parameter >>>> to set up the display resolution and bit depth, and AFAICT we currently only have >>>> access to the X and Y resolutions via the EDID blob. So it's not clear whether EDID >>>> can completely replace the existing mechanism yet. >>> >>> EDID can only propagate x + y, not depth. >> >> Right - my quick reading online was that there was very limited depth capability, and >> certainly nothing greater than 16-bit. > > That is another depth, it's the bits *per color* the monitor is able to > display. Ah I see - my mistake. >> Rather than duplicating these parameters, would it make sense to come up with a >> custom QEMU extension block to hold the extra depth information? > > Well, not really. EDID is about monitor capabilities. The monitor will > see 8 bit per color channel, no matter whenever your GPU composes that > signal using a 8bpp mode + color palette or 24bpp mode with direct > color. Hmmm okay. Perhaps it might still be worth hooking -g XxYxD to also put X and Y into xres and yres within the EDID so at least everything is consistent between OpenBIOS and the client driver when it eventually loads? ATB, Mark. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Qemu-devel] Questions about EDID 2019-02-28 16:57 ` Mark Cave-Ayland @ 2019-03-01 5:43 ` Gerd Hoffmann 0 siblings, 0 replies; 16+ messages in thread From: Gerd Hoffmann @ 2019-03-01 5:43 UTC (permalink / raw) To: Mark Cave-Ayland; +Cc: G 3, qemu-devel qemu-devel Hi, > > Well, not really. EDID is about monitor capabilities. The monitor will > > see 8 bit per color channel, no matter whenever your GPU composes that > > signal using a 8bpp mode + color palette or 24bpp mode with direct > > color. > > Hmmm okay. Perhaps it might still be worth hooking -g XxYxD to also put X and Y into > xres and yres within the EDID so at least everything is consistent between OpenBIOS > and the client driver when it eventually loads? That makes sense, sure. Will be a bit tricky due to (I think) only ppc and sparc actually looking at -g right now, to make sure current behavior of the other archs doesn't change when -g is not specified. cheers, Gerd ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Qemu-devel] Questions about EDID 2019-02-28 5:01 ` Mark Cave-Ayland 2019-02-28 5:49 ` Gerd Hoffmann @ 2019-02-28 16:53 ` G 3 2019-03-01 5:47 ` Gerd Hoffmann 1 sibling, 1 reply; 16+ messages in thread From: G 3 @ 2019-02-28 16:53 UTC (permalink / raw) To: Mark Cave-Ayland; +Cc: Gerd Hoffmann, qemu-devel qemu-devel On Thu, Feb 28, 2019 at 12:01 AM Mark Cave-Ayland < mark.cave-ayland@ilande.co.uk> wrote: > On 27/02/2019 05:27, Gerd Hoffmann wrote: > > > On Tue, Feb 26, 2019 at 04:11:06PM -0500, G 3 wrote: > >> When I use edid=on, I do see a lot of extra resolutions available in > Mac OS > >> 9 and Mac OS X, just not the resolution I want to use. Is there some > kind > >> of rule like the resolution value has to be divisible by a certain > number? > > > > qemu doesn't have such a requirement. > > Might be the guest drivers have. > > Try making width/height multiple of 8 or 16. > > Right, at the moment all the MacOS driver does is parse the resolution > list from the > EDID and add them to the dropdown list - it doesn't support the xres and > yres properties. > Gerd, could the xres +yres numbers be added to the list of resolutions then? ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Qemu-devel] Questions about EDID 2019-02-28 16:53 ` G 3 @ 2019-03-01 5:47 ` Gerd Hoffmann 2019-03-01 14:41 ` G 3 0 siblings, 1 reply; 16+ messages in thread From: Gerd Hoffmann @ 2019-03-01 5:47 UTC (permalink / raw) To: G 3; +Cc: Mark Cave-Ayland, qemu-devel qemu-devel On Thu, Feb 28, 2019 at 11:53:43AM -0500, G 3 wrote: > On Thu, Feb 28, 2019 at 12:01 AM Mark Cave-Ayland < > mark.cave-ayland@ilande.co.uk> wrote: > > > On 27/02/2019 05:27, Gerd Hoffmann wrote: > > > > > On Tue, Feb 26, 2019 at 04:11:06PM -0500, G 3 wrote: > > >> When I use edid=on, I do see a lot of extra resolutions available in > > Mac OS > > >> 9 and Mac OS X, just not the resolution I want to use. Is there some > > kind > > >> of rule like the resolution value has to be divisible by a certain > > number? > > > > > > qemu doesn't have such a requirement. > > > Might be the guest drivers have. > > > Try making width/height multiple of 8 or 16. > > > > Right, at the moment all the MacOS driver does is parse the resolution > > list from the > > EDID and add them to the dropdown list - it doesn't support the xres and > > yres properties. > > > > Gerd, could the xres +yres numbers be added to the list of resolutions > then? That is already the case: qemu-edid -x 1234 -y 567 | edid-decode [ ... ] First detailed timing is preferred timing Established timings supported: 640x480@60Hz 800x600@60Hz 1024x768@60Hz Standard timings supported: 2048x1152@60Hz 1920x1080@60Hz Detailed mode: Clock 73.170 MHz, 485 mm x 223 mm 1234 1542 1579 1665 hborder 0 ^^^^ 567 569 571 586 vborder 0 ^^^ -hsync -vsync [ ... ] cheers, Gerd ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Qemu-devel] Questions about EDID 2019-03-01 5:47 ` Gerd Hoffmann @ 2019-03-01 14:41 ` G 3 0 siblings, 0 replies; 16+ messages in thread From: G 3 @ 2019-03-01 14:41 UTC (permalink / raw) To: Gerd Hoffmann; +Cc: Mark Cave-Ayland, qemu-devel qemu-devel If the value is already in the list, then something else must be happening that prevents the custom resolution from reaching the guest. Would you know where in the list the custom resolution is added? My guess right now is the size of the list is being reported incorrectly - the custom resolution isn't being counted. When the operating system iterates thru the list it might stop right before the custom resolution value, preventing its inclusion. On Fri, Mar 1, 2019 at 12:47 AM Gerd Hoffmann <kraxel@redhat.com> wrote: > On Thu, Feb 28, 2019 at 11:53:43AM -0500, G 3 wrote: > > On Thu, Feb 28, 2019 at 12:01 AM Mark Cave-Ayland < > > mark.cave-ayland@ilande.co.uk> wrote: > > > > > On 27/02/2019 05:27, Gerd Hoffmann wrote: > > > > > > > On Tue, Feb 26, 2019 at 04:11:06PM -0500, G 3 wrote: > > > >> When I use edid=on, I do see a lot of extra resolutions available in > > > Mac OS > > > >> 9 and Mac OS X, just not the resolution I want to use. Is there some > > > kind > > > >> of rule like the resolution value has to be divisible by a certain > > > number? > > > > > > > > qemu doesn't have such a requirement. > > > > Might be the guest drivers have. > > > > Try making width/height multiple of 8 or 16. > > > > > > Right, at the moment all the MacOS driver does is parse the resolution > > > list from the > > > EDID and add them to the dropdown list - it doesn't support the xres > and > > > yres properties. > > > > > > > Gerd, could the xres +yres numbers be added to the list of resolutions > > then? > > That is already the case: > > qemu-edid -x 1234 -y 567 | edid-decode > [ ... ] > First detailed timing is preferred timing > Established timings supported: > 640x480@60Hz > 800x600@60Hz > 1024x768@60Hz > Standard timings supported: > 2048x1152@60Hz > 1920x1080@60Hz > Detailed mode: Clock 73.170 MHz, 485 mm x 223 mm > 1234 1542 1579 1665 hborder 0 > ^^^^ > 567 569 571 586 vborder 0 > ^^^ > -hsync -vsync > [ ... ] > > cheers, > Gerd > > ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2019-03-01 14:41 UTC | newest] Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-02-25 14:05 [Qemu-devel] Questions about EDID G 3 2019-02-25 15:26 ` Gerd Hoffmann 2019-02-26 2:49 ` Programmingkid 2019-02-26 6:43 ` Gerd Hoffmann 2019-02-26 21:11 ` G 3 2019-02-27 5:27 ` Gerd Hoffmann 2019-02-27 21:22 ` Programmingkid 2019-02-28 5:01 ` Mark Cave-Ayland 2019-02-28 5:49 ` Gerd Hoffmann 2019-02-28 6:01 ` Mark Cave-Ayland 2019-02-28 6:38 ` Gerd Hoffmann 2019-02-28 16:57 ` Mark Cave-Ayland 2019-03-01 5:43 ` Gerd Hoffmann 2019-02-28 16:53 ` G 3 2019-03-01 5:47 ` Gerd Hoffmann 2019-03-01 14:41 ` G 3
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.