Pat Campbell
2007-Dec-20 05:20 UTC
[Xen-devel][RFC] Dynamic modes support for PV xenfb (included)
Hi,
The attached files allow the PV framebuffer to be dynamically resized from
800x600 to 1024x768 and back.
xen-fbfront-resize.patch is applied to tip of linux-2.6.18-xen
xen-fbback-resize.patch is applied to tip of unstable-xen
I have tested the patches on SuSE SLES 10:
x86_64 dom0 x86_64 domU OK
x386 domU OK
x386 dom0 x386 domU OK
x86_64 domU Error: (4, ''Out of
memory'',
xc_dom_boot_mem_init: can''t allocate
low memory for domain)
( This is something else unrelated to my patch
I think )
I am NOT requesting commit to xen- unstable. This is just a posting
for code review and feedback.
After the patches are applied to dom0 and your domU
PV guest you will need to properly configure the domU X
server for display modes 800x600 and 1024x768.
For testing I used "xrandr" to dynamically resize the domU
GUI session.
>$ xrandr // show capabilities
SZ: Pixels Physical Refresh
*0 1024 x 768 ( 361mm x 291mm ) *73
1 800 x 600 ( 361mm x 291mm ) 73
Current rotation - normal
Current reflection - none
Rotations possible - normal
Reflections possible - none
>$ xrandr --size 800x600 //change to 800x600
>$ xrandr --size 1024x768
domU xorg.conf :
SuSE sax2 is not able to configure a PV framebuffer properly
so I hand crafted a new xorg.conf file for the PV guest. Below
are the sections I changed.
Section "Monitor"
HorizSync 30-65
Identifier "Monitor[0]"
ModelName "XEN PVFB"
Option "DPMS"
VendorName "XEN"
VertRefresh 43-75
UseModes "Modes[0]"
EndSection
Section "Modes"
Identifier "Modes[0]"
Modeline "1024x768" 77.25 1024 1080 1192 1360 768 769 772 800
Modeline "800x600" 46.15 800 840 920 1040 600 601 604 625
EndSection
Section "Screen"
SubSection "Display"
Depth 24
Modes "1024x768" "800x600"
EndSubSection
Device "Device[0]"
Identifier "Screen[0]"
Monitor "Monitor[0]"
EndSection
Pat
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Mark Williamson
2007-Dec-23 21:58 UTC
Re: [Xen-devel][RFC] Dynamic modes support for PV xenfb (included)
> The attached files allow the PV framebuffer to be dynamically resized from > 800x600 to 1024x768 and back. > > xen-fbfront-resize.patch is applied to tip of linux-2.6.18-xen > xen-fbback-resize.patch is applied to tip of unstable-xen> I am NOT requesting commit to xen- unstable. This is just a posting > for code review and feedback. > > After the patches are applied to dom0 and your domU > PV guest you will need to properly configure the domU X > server for display modes 800x600 and 1024x768.Nice. I took a quite look through the code and was impressed by how small a patch was actually required. A few general comments: 1) I think it would be preferable to be able to dynamically size the memory allocated to the framebuffer according to the resolution, rather than statically allocating it and then potentially not using all of it. Presumably this would require more extensive changes to the backend, since it would need to map and unmap the framebuffer memory during a resize operation. How complicated do you think this would be? 2) Dynamically allocating the memory would make it practical to support a larger range of resultions than currently possible, without wasting lots of memory for potential higher resolutions (e.g. to suit users with very big monitors connected to dom0). I think that this is nice support to have available. Other VMM user interfaces even allow resizing of the guest display resolution simply by resizing the viewer window on the host - this would require a little more software running in the guest to support it but would be cool to support. Of course, that''s just me getting excited - simply supporting resize from within the guest is a major win in practicality. Do you have any further plans for xenfb? It''s not got as much love as it could have done and it definitely seems like there are things that can be done to improve it still further. Cheers, Mark> For testing I used "xrandr" to dynamically resize the domU > GUI session. > > >$ xrandr // show capabilities > > SZ: Pixels Physical Refresh > *0 1024 x 768 ( 361mm x 291mm ) *73 > 1 800 x 600 ( 361mm x 291mm ) 73 > Current rotation - normal > Current reflection - none > Rotations possible - normal > Reflections possible - none > > >$ xrandr --size 800x600 //change to 800x600 > >$ xrandr --size 1024x768 > > domU xorg.conf : > SuSE sax2 is not able to configure a PV framebuffer properly > so I hand crafted a new xorg.conf file for the PV guest. Below > are the sections I changed. > > Section "Monitor" > HorizSync 30-65 > Identifier "Monitor[0]" > ModelName "XEN PVFB" > Option "DPMS" > VendorName "XEN" > VertRefresh 43-75 > UseModes "Modes[0]" > EndSection > > Section "Modes" > Identifier "Modes[0]" > Modeline "1024x768" 77.25 1024 1080 1192 1360 768 769 772 800 > Modeline "800x600" 46.15 800 840 920 1040 600 601 604 625 > EndSection > > Section "Screen" > SubSection "Display" > Depth 24 > Modes "1024x768" "800x600" > EndSubSection > Device "Device[0]" > Identifier "Screen[0]" > Monitor "Monitor[0]" > EndSection > > Pat-- Dave: Just a question. What use is a unicyle with no seat? And no pedals! Mark: To answer a question with a question: What use is a skateboard? Dave: Skateboards have wheels. Mark: My wheel has a wheel! _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Pat Campbell
2007-Dec-31 12:27 UTC
Re: [Xen-devel][RFC] Dynamic modes support for PV xenfb (included)
>>> On Sun, Dec 23, 2007 at 2:58 PM, in message<200712232158.13581.mark.williamson@cl.cam.ac.uk>, Mark Williamson <mark.williamson@cl.cam.ac.uk> wrote:>> The attached files allow the PV framebuffer to be dynamically resized from >> 800x600 to 1024x768 and back. >> >> xen-fbfront-resize.patch is applied to tip of linux-2.6.18-xen >> xen-fbback-resize.patch is applied to tip of unstable-xen > >> I am NOT requesting commit to xen- unstable. This is just a posting >> for code review and feedback. >> >> After the patches are applied to dom0 and your domU >> PV guest you will need to properly configure the domU X >> server for display modes 800x600 and 1024x768. > > Nice. > > I took a quite look through the code and was impressed by how small a patch > was actually required. > > A few general comments: > 1) I think it would be preferable to be able to dynamically size the memory > allocated to the framebuffer according to the resolution, rather than > statically allocating it and then potentially not using all of it. > Presumably this would require more extensive changes to the backend, since > it > would need to map and unmap the framebuffer memory during a resize > operation. > How complicated do you think this would be?I am not familiar enough with the Linux frame buffer code to even hazard a guess. Once the frame buffer is registered in the probe function can the memory be changed without crashing the app that has mmaped it in? Handshake with the backend would complicate things, need to disable shared memory access, remapped it and then reenable it. Not sure how suspend resume might work in this case. Absolute mouse positioning needs to know the resolution to scale the position properly. Need some new events to alert it of a resolution change.> > 2) Dynamically allocating the memory would make it practical to support a > larger range of resultions than currently possible, without wasting lots of > memory for potential higher resolutions (e.g. to suit users with very big > monitors connected to dom0). > > I think that this is nice support to have available. Other VMM user > interfaces even allow resizing of the guest display resolution simply by > resizing the viewer window on the host - this would require a little more > software running in the guest to support it but would be cool to support. > Of > course, that''s just me getting excited - simply supporting resize from > within > the guest is a major win in practicality. > > Do you have any further plans for xenfb? It''s not got as much love as it > could have done and it definitely seems like there are things that can be > done to improve it still further.No further plans at the moment. I looked into using grant tables for the shared memory but decided against it for now. Grant tables would break backwards compatibility unless both memory sharing techniques were supported.> > Cheers, > MarkThanks for taking the time to look at it. Pat> >> For testing I used "xrandr" to dynamically resize the domU >> GUI session. >> >> >$ xrandr // show capabilities >> >> SZ: Pixels Physical Refresh >> *0 1024 x 768 ( 361mm x 291mm ) *73 >> 1 800 x 600 ( 361mm x 291mm ) 73 >> Current rotation - normal >> Current reflection - none >> Rotations possible - normal >> Reflections possible - none >> >> >$ xrandr --size 800x600 //change to 800x600 >> >$ xrandr --size 1024x768 >> >> domU xorg.conf : >> SuSE sax2 is not able to configure a PV framebuffer properly >> so I hand crafted a new xorg.conf file for the PV guest. Below >> are the sections I changed. >> >> Section "Monitor" >> HorizSync 30-65 >> Identifier "Monitor[0]" >> ModelName "XEN PVFB" >> Option "DPMS" >> VendorName "XEN" >> VertRefresh 43-75 >> UseModes "Modes[0]" >> EndSection >> >> Section "Modes" >> Identifier "Modes[0]" >> Modeline "1024x768" 77.25 1024 1080 1192 1360 768 769 772 800 >> Modeline "800x600" 46.15 800 840 920 1040 600 601 604 625 >> EndSection >> >> Section "Screen" >> SubSection "Display" >> Depth 24 >> Modes "1024x768" "800x600" >> EndSubSection >> Device "Device[0]" >> Identifier "Screen[0]" >> Monitor "Monitor[0]" >> EndSection >> >> Pat > > > > -- > Dave: Just a question. What use is a unicyle with no seat? And no pedals! > Mark: To answer a question with a question: What use is a skateboard? > Dave: Skateboards have wheels. > Mark: My wheel has a wheel!_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Gerd Hoffmann
2008-Jan-02 10:51 UTC
Re: [Xen-devel][RFC] Dynamic modes support for PV xenfb (included)
Pat Campbell wrote:>> I took a quite look through the code and was impressed by how small a patch >> was actually required.The linux framebuffer has resize support, so this is easy ;) Resizing the framebuffer text console using the "fbset" utility should work too btw.>> A few general comments: >> 1) I think it would be preferable to be able to dynamically size the memory >> allocated to the framebuffer according to the resolution, rather than >> statically allocating it and then potentially not using all of it. >> Presumably this would require more extensive changes to the backend, since >> it >> would need to map and unmap the framebuffer memory during a resize >> operation. >> How complicated do you think this would be? > > I am not familiar enough with the Linux frame buffer code to even hazard > a guess. Once the frame buffer is registered in the probe function can the > memory be changed without crashing the app that has mmaped it in?Easy. You can zap the mapping, then fill it with other pages in the page fault handler. I think the driver already does that anyway to track framebuffer page writes (aka screen updates).> Handshake with the backend would complicate things, need to disable shared > memory access, remapped it and then reenable it. Not sure how suspend > resume might work in this case.Backend handshake would be more tricky. You can''t release the pages as long as the backend has them mapped. Otherwise things will go seriously wrong, especially in case the kernel decides to use the released pages as page tables. When you touch these things anyway it you might want switch over to grant tables (we have resizeable grant tables and a grant table device for userspace apps now) to allow the backend access to the framebuffer memory. And make the structs 32/64-bit invariant.> Absolute mouse positioning needs to know the resolution to scale the > position properly. Need some new events to alert it of a resolution change.Just watch xenbus width/height nodes?> No further plans at the moment. I looked into using grant tables for the > shared memory but decided against it for now. Grant tables would break > backwards compatibility unless both memory sharing techniques were > supported.On the flip side the current scheme (one page full of mfns) limits the video memory, for larger virtual screens this must be changed anyway. So maybe just keep the current scheme for 800x600 fixed size? And require grant tables for the resizable fb? That will make the amount of backward compatibility code smaller as the resizeable bits are required in the grant tables code paths only. cheers, Gerd _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel