Re: [Xen-devel][PATCH] Dynamic modes support for PV xenfb (0 of 2)

["Pat Campbell" <plc@xxxxxxxxxx>]

>>> On Wed, Jan 9, 2008 at 12:43 PM, in message 
>>> <20080109194325.GN8732@xxxxxxxxxx>,
"Daniel P. Berrange" <berrange@xxxxxxxxxx> wrote: 
> On Tue, Jan 08, 2008 at 08:34:31AM -   0700, Pat Campbell wrote:
>> 
>> Patches 1of2 and 2of2 adds multiple frame buffer resolution
>> support to the PV xenfb frame buffer driver and the PV xenfb
>> VNC server.
>> 
>> API Changelog entry is included here as I did not see doc/ChangeLog
>> when I did a tip clone this morning.
>> 
>> ---------------------------------------------------------------
>> API Changelog entry:
>> 
>>  PV framebuffer multiple resolution facility:
>> 
>>   Guest may send XENFB_TYPE_RESIZE if feature-   resize = 1 in
>>   xenstore of the backend VNC server. VNC server code sets
>>   feature-   resize if it can handle the resize reguest.
>> 
>>   When multiple resolution support is enabled the guests frame
>>   buffer size jumps from 2MB to 5MB.  Maximum scanline length
>>   is 1280 pixels. Code can support any resolution thats fits
>>   within the 5MB and does not exceed a width of 1280.
>> 
>>   New xenstore virtual machine specific VNC attributes:
>>     vncresizable-   pvfb: For those that don't need higher
>>       resolutions in their guest. Default: 0.
> 
> Is there really any compelling need to make the resize stuff
> a config option ?  IMHO it should just always be on by default.
> If a user doesn't want to resize the guest, then they can simply
> not run the xrandr tool in their guest.

My thinking was that some people would not want the extra
3MB memory hit caused by the larger frame buffer.  If no one
else has any input as to the 5MB size I will remove that option.

> 
>>     vnc-   fixevdev-   abs: Older versions of evdev do not
>>       have an option to disable scaling.  This attribute
>>       adjust the abs mouse position to counter evdevs scaling.
>>       Default: 0
> 
> Its a rather sick hack, but if this is the only way we have to deal
> with evdev, then I guess we have no choice. I'd like to see if have
> a slightly less hack-   ish name though -    perhaps 'vnc-   scale-   pointer'
> 

I will change that to the name you suggest.  

I suppose we could just say that to use dynamic modes in a 
PV guest you need a recent version of X running in the guest. 

>>   Attribute usage:
>>     vfb=['type=vnc,vncunused=1,vncresizable-   pvfb=1,vnc-   fixevdev-   
>> abs=1']
>> 
>>   Note: For proper absolute mouse tracking support when
>>         resizing, the guests xorg.conf file will need to
>>         have one of the following options added to it's
>>         InputDevice section.
>> 
>>         For driver 'evdev' add:   Option "AbsoluteScreen" "-   1"
>>          (Or set vnc-   fixevdev-   abs in the vm config file vfb section)
>>         For driver 'evtouch" add: Option "Calibrate" "1"
> 
> If I'm understanding the problem correctly -    QEMU will scale the
> mouse coords it sends to match the new resolution. The guest evdev
> driver will then scale them again ?  

Actually we reverse the scale so that the scale done in evdev results in
the original position.
   orig pos --> xenfb reverse scale -->  evdev scale --> orig pos

> 
> If so would it be possible to simply stop QEMU scaling them, so we
> can always have the guest do the adjustment without needing special
> config options ?   The goal of latest Xorg is to have all input devices
> automatically configured -    there will be no config file for Xorg by
> default. So if we can't get the Xen PVFB to work correctly with zero
> config settings in the guest Xen is going to behave sub-   optimally 
>

In working up this response I found that newer versions of evdev will
request new frame buffer ABS min/max values if a SYN_CONFIG 
is sent.  I will modify the xenfb driver patch to send a SYN_CONFIG
and see if that works, if so that should eliminate any need to 
configure Xorg for newer releases of X.

Will send new patches out when done

Pat






_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel