The way resolution and modesetting work right now is static. We have
two static items:
1) A static (atm 8 meg) framebuffer location, where the primary
surface is always allocated at offset 0. The memory not used
by the framebuffer is wasted.
2) A static list of supported resolutions in the qxl device rom.
Changing any of these is an incompatible change for device migration.
Additionally there can only be one primary surface per device, which
is also less dynamic than we want.
This is no good, we want to be able to support resolutions larger than
fits in 8 megs without wasting ram, and we want to support resolutions
that the client can support without being in some hardcoded list, and
we want to support multiple monitors on a single device.
We've discussed this internally and on bugs before, and I'd like to
write down in public some of the ideas we've come up with.
First of all, the list of resolutions in the rom is required for
compatibility with drivers that use it, but the actual operations that
set the mode doesn't take this list into account at all. All they pass
is the resolution and the width/height. So, while the current windows
driver does limit itself to this set of resolution we can easily fix
this in a driver update, with no spice changes needed.
To make this work nicely we could have a static small set of
resolutions, then have the client report further resolutions. Maybe we
could also have modesetting working in the driver to any resolution
(even those not listed in the drivers mode list) so that the agent can
change to any resolution, thus matching whatever resoltion the client
currently has. In fact, this way we could probably support resizeing
the client window changing the resolution.
Secondly, the 8 meg ram region that is currently used for the fixed
framebuffer (and as vga ram in vga mode) isn't really implicit in
modesetting. When modesetting all we do is pass the physical memory
address of the framebuffer and its stride to spice. At the moment
we always pass in the start of the 8 meg block, but there is nothing
that requires this.
So, for framebuffers larger than 8 megabytes we should try to allocate
the framebuffer from the vram, which is where we allocate offscreen
surfaces. This is currently 64 meg, so should be enough for very high
resolutions. It may be that the allocation fails due to fragmentation
or lots of offscreens, but if so we can just migrate some offscreens
into normal software surfaces.
I don't think there is anything in the current spice server that makes
this not work, but only experimenting can verify this.
The one last thing is support for multiple primary surfaces. This is
something that the X driver need for true Xrandr. Theoretically this
should work by creating multiple primaries, some in the vram. However,
this is unlikely to work with current spice as there are assumptions
at various places in the code that there is only one primary
surface. So, this requires changes in all of spice.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander Larsson Red Hat, Inc
al...@redhat.com alexander.lars...@gmail.com
He's a fiendish alcoholic werewolf for the 21st century. She's a brilliant
kleptomaniac journalist with an evil twin sister. They fight crime!
_______________________________________________
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
