WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel][RFC] Dynamic modes support for PV xenfb (included)

To: "Mark Williamson" <mark.williamson@xxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel][RFC] Dynamic modes support for PV xenfb (included)
From: "Pat Campbell" <plc@xxxxxxxxxx>
Date: Mon, 31 Dec 2007 05:27:34 -0700
Delivery-date: Mon, 31 Dec 2007 04:28:21 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>> On Sun, Dec 23, 2007 at  2:58 PM, in message
<200712232158.13581.mark.williamson@xxxxxxxxxxxx>, Mark Williamson
<mark.williamson@xxxxxxxxxxxx> 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,
> Mark

Thanks 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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>