Pat Campbell
2008-Jan-08 15:34 UTC
[Xen-devel][PATCH] Dynamic modes support for PV xenfb (0 of 2)
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>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Daniel P. Berrange
2008-Jan-09 19:43 UTC
Re: [Xen-devel][PATCH] Dynamic modes support for PV xenfb (0 of 2)
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: 0Its 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 -=| _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Daniel P. Berrange
2008-Jan-09 21:29 UTC
Re: [Xen-devel][PATCH] Dynamic modes support for PV xenfb (0 of 2)
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 -=| _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Pat Campbell
2008-Jan-09 22:07 UTC
Re: [Xen-devel][PATCH] Dynamic modes support for PV xenfb (0 of 2)
>>> 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel