Hi, >> Are we going to have one more input/cursor channel per head? Probably >> not, but it would be nice to specify. I guess the coordinate will need >> to be adjusted to the respective heads. (ie some messages will be >> relative to heads, other to primary surface: INPUTS_MOUSE_POSITION vs >> CURSOR_MOVE). > > Uh, I think not - we don't have multiple inputs for multiple display > channels right now, why change that? actually, didn't consider input > because there is no change. We already handle multiple monitors fine > with an agent and badly without. I think this needs some more thougth. Right now primary surface == head/monitor and the mouse is relative to that. With the head/monitor being defined as rectangle within the primary surface we need to pick one model: either make them relative to the primary surface, or make them relative to the head/monitor. Making it relative to the head needs a protocol change I think as we need to send over the head id then. We could get away with reusing the display channel id field, but that assumes that nobody ever tries to use the new multihead mode with multiple qxl cards, thereby creating 4 monitors with 2 qxl cards or something like that. Making it relative to the primary surface makes more sense to me. That way the spice client has to do the head -> primary coordinate mapping (instead of the guests vdagent). Multihead mouse will also work without the agent then. Backward compatibility to old spice clients (which present just a single, big window) is no problem too. cheers, Gerd _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel