Den 2009-03-16 18:15 skrev Pierre Ossman:
On Mon, 16 Mar 2009 16:54:20 +0100
Peter Rosin wrote:
Den 2009-03-16 15:00 skrev Pierre Ossman:
Annoying. Do they also rely on putting the conversion requirements on
the client?
Yes. If a client claims support for WMVi, it has to support all pixfmts
(or disconnect on reception of something unlikeable).
But what if the client doesn't claim to support it? Seems like they
have to implement format conversion in the server anyway.
Oh yes, they do it in the server too. One reason to go with WMVi might
be that the server doesn't need to do a lot of conversions during a
pixfmt change as all clients are forced to follow the server
preference. But I also think you could have evaded that with a single
rect update that only specifies a new pixfmt preference, instead
of an update starting with a WMVi rect and then a full update in the
new pixfmt following. The client would then get a chance to change
pixfmt without the server doing any conversions. And the clients could
be kept simpler.
As is, I think QEMU simply disconnects clients that does not support
WMVi, should its preferred pixfmt change. But a client can still request
whatever pixfmt it wants, it's just when the preferred pixfmt changes
that the server disconnects all non-WMVi clients. But that is from memory
and it might also have changed since I looked?
Indeed, but describing such limitations can be very difficult. How do
you describe the non-overlapping requirement for example?
I don't see the method of requesting one thing and potentially getting
something completely different back as a decent solution. In most cases
it will just be plain confusing.
Could you describe how the client could suitably react to such a
response?
I wasn't proposing that the exact restrictions were described. I didn't
propose that the server response would actually be used, it would just
be a hint so that the client would have at least some request that worked.
But the client would probably need to adjust the server reply further.
An example (using monospace font):
Server has two screens 1024x768, side-by-side, fb-size 2048x768.
---------------------
| | |
| | |
| | |
---------------------
Client the asks for the initial two screens, plus a third screen 800x600
which is halfway overlapping the rightmost screen, fb-size 2448x768.
-------------------------
| | | | |
| | | | |
| | ----|----
---------------------
Server says "no" (since it can't handle overlapping screens) and informs
the client that it could change its request to not have any overlaps,
i.e. make the third screen only 400x600, fb-size still 2448x768.
-------------------------
| | | |
| | | |
| | |----
---------------------
The client can then do what it wants with that info. If it takes it, it
could render on only half its third screen.
Or the server might decide to move the overlapping screen to the right
instead. And since it has no idea what the client's restrictions are,
the client might need to readjust what the server wants. And then
things quickly spiral out of control. :)
But if the server suggests that, its suggestion isn't smaller than the
client request *in all aspects*.
But yes, there could potentially be many roundtrips and still no working
end result. But that is equally true if the server is only saying "no".
A mechanism that allows the client to handle server side limitations
would be fantastic. But the only solutions I see either cannot describe
all the possible limitations, or start to cross over into the whole
"implementation defined" neck of the woods. And "implementation
defined" is the greater evil IMO, so I've opted for an incomplete, but
common set of restrictions.
We might want more/other fields than what I've proposed, but the whole
"throw stuff at the server and see what comes back" approach does not
give me a good feeling.
Ok, you don't like it. I was only a suggestion that popped up in my head.
Since it is nearly impossible to envision all possible server side
limitations, we shouldn't even try. Instead, let the server come up with
one possible workaround for the client, but never force that suggestion
on the client. The client can always request something completely
different, should it dislike the server suggestion.
People tend to follow popular implementations, not the specification.
So I don't think we should add anything on the premise "might be
useful, perhaps, but everyone else can just ignore it" as there is a
high risk of implementations popping up that rely on this optional
behaviour.
I believe the only sane way is to have a set of restrictions where the
client can compute beforehand if a request will fail, and a failsafe of
the server saying "no" for the restrictions that we were unable to
describe. The server might for example be saying no just because it
doesn't allow any changes at all. What would it fill into the fields as
a suggested alternative at that point?
Since even you can't figure out the answer to that question (which is
really simple, there is only one multihead config that is acceptable for
the server so of course it is supposed to suggest that one), I have to
face facts and realize that my suggestion is to hard to describe and
implement sanely.
However, I still think 16 bits to be too little to deliver a useful
error response for something as complex as this and I wish you a happy
time telling users to read the manual of the server they are connecting
to when the client gets a blanket "no" ;-)
Or are the servers you are planning either
A) fully capable of all screen layouts (Xvnc type server with no local
screen HW to consider) or
B) capable of only one screen layout (Windows type server with the local
screen HW deciding the layout)?
Is that why you seem eager to punt on the error case issue?
Cheers,
Peter
_______________________________________________
VNC-List mailing list
VNC-List@realvnc.com
To remove yourself from the list visit:
http://www.realvnc.com/mailman/listinfo/vnc-list
