[PATCH] Dynamic modes support for PV xenfb (0 of 2)

[PATCH] Dynamic modes support for PV xenfb (0 of 2)

[Pat Campbell]

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.
    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

  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"

        OpenSuSE 10.3 and Fedora 8 both have evdev AbsoluteSceen
        option.  RHEL5 and SLES10 do not and would require
        vnc-fixevdev-abs.

---------------------------------------------------------------

Signed-      off-      by: Pat Campbell <plc@novell.com>

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

[Daniel P. Berrange]

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.

>     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'

>   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 ?  

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 

Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 

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

[Daniel P. Berrange]

On Wed, Jan 09, 2008 at 02:16:07PM -0700, Pat Campbell wrote:
> >>> On Wed, Jan 9, 2008 at 12:43 PM, in message <20080109194325.GN8732@redhat.com>,
> "Daniel P. Berrange" <berrange@redhat.com> wrote: 
> > On Tue, Jan 08, 2008 at 08:34:31AM -  0700, Pat Campbell wrote:
> >>   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.

That's a fair point. HOw about having a 'videoram=XXX' config
parameter instead, and have your new resize feature also inform
the guest of the desired RAM allocation. Then we can allow any
resolution that fits in the configured RAM.   A videoram param
is something that's a reasonably generic concept across full and
paravirt and different hypervisors so would fit into nicely to
the UI of management tools

Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 

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

[Pat Campbell]

>>> On Wed, Jan 9, 2008 at 12:43 PM, in message <20080109194325.GN8732@redhat.com>,
"Daniel P. Berrange" <berrange@redhat.com> 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