Any thoughts/feedback on this one? It really is a downer to be forced to manipulate both of these via hooks. These are both pretty standard configuration items to enhance/tweak or make various guests fully functional.

- DHC On Fri, Mar 22, 2013 at 9:12 AM, Dead Horse <deadhorseconsulting(a)gmail.com <mailto:deadhorseconsulting@gmail.com>> wrote: Allow for a usbtablet input device to be enabled and used. Perhaps via the console configuration UI for a VM in the admin and user portals. -Highly useful in the event that a guest OS does not have the spice agent loaded nor is it available for said guest OS. -Also in the case of guest OS that simply does not want to work and play well with <input type='mouse' bus='ps2'> - All Operating systems since ~1998 understand <input type='tablet' bus='usb'/> and will deal with mouse events in absolute mode. Allow for vram and vram_ size to be configurable for CIrrus(VNC) and QXL(Spice) console types. Again probably best suited to have this on console configuration UI for a VM in the admin and user portals. - Default VRAM sizes are not enough to allow for larger resolutions and pixel depths at times. - Especially the case in multiple monitor SPICE, fullscreen, or VNC consoles - More VRAM is useful in the case of attempting to run accelerated applications within a QXL configured guest. The above can be altered via VDSM hooks however this is rather painful. Additionally these options or similar are configurable in other competing solutions. - DHC _______________________________________________ Users mailing list Users(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/users

I just checked on VNC. In the case of a VNC console usbtablet is being used in the generated dom xml. However like VNC when a guest has no spice awareness it is in the same boat as VNC so usbtablet is helpful in getting to that point. Or just simply if it cannot be made spice aware at all as is the case for some guest types (EG: no vdagent possiblity for example). Making VRAM configurable would be a nice benefit to SPICE or VNC console. Thus allowing for a guest to have enough vram for higher resolutions and bit depths as well as more vram for 2D video operations.

- DHC On Wed, Apr 3, 2013 at 2:39 PM, Itamar Heim <iheim(a)redhat.com <mailto:iheim@redhat.com>> wrote: On 03/27/2013 05:23 PM, Dead Horse wrote: Any thoughts/feedback on this one? It really is a downer to be forced to manipulate both of these via hooks. These are both pretty standard configuration items to enhance/tweak or make various guests fully functional. will track via the bugs. the vram for spice multi monitor i see the issue with. for usb tablet, don't we always enable it for vnc display? - DHC On Fri, Mar 22, 2013 at 9:12 AM, Dead Horse <deadhorseconsulting(a)gmail.com <mailto:deadhorseconsulting@gmail.com> <mailto:deadhorseconsulting@__gmail.com <mailto:deadhorseconsulting@gmail.com>>> wrote: Allow for a usbtablet input device to be enabled and used. Perhaps via the console configuration UI for a VM in the admin and user portals. -Highly useful in the event that a guest OS does not have the spice agent loaded nor is it available for said guest OS. -Also in the case of guest OS that simply does not want to work and play well with <input type='mouse' bus='ps2'> - All Operating systems since ~1998 understand <input type='tablet' bus='usb'/> and will deal with mouse events in absolute mode. Allow for vram and vram_ size to be configurable for CIrrus(VNC) and QXL(Spice) console types. Again probably best suited to have this on console configuration UI for a VM in the admin and user portals. - Default VRAM sizes are not enough to allow for larger resolutions and pixel depths at times. - Especially the case in multiple monitor SPICE, fullscreen, or VNC consoles - More VRAM is useful in the case of attempting to run accelerated applications within a QXL configured guest. The above can be altered via VDSM hooks however this is rather painful. Additionally these options or similar are configurable in other competing solutions. - DHC _________________________________________________ Users mailing list Users(a)ovirt.org <mailto:Users@ovirt.org> http://lists.ovirt.org/__mailman/listinfo/users <http://lists.ovirt.org/mailman/listinfo/users>