[PATCH 1/2] xwayland: Update screen size on output removal

Olivier Fourdan ofourdan at redhat.com
Tue Nov 17 02:36:50 PST 2015


Hi

----- Original Message -----
> > Or does Xwayland perhaps have a requirement for compositors to have
> > no output space to the left and/or right of 0,0?
> 
> I don't know if there's such a written requirement, but reading the code as
> you did, I don't think it expect outputs to a have negative position.

So I made a patch that does handle negative position for outputs, but I am not posting it as I am not sure it's worth it, see below.
 
> > We have also entertained a thought to position the first output in
> > Weston not to x=0, y=0 but somewhere totally different like x=-3000,
> > y=2000 and see what would break, but I'm not sure if anyone tried it
> > yet. In theory it should not make any difference.
> 
> That's a good idea, and worth a try.

I did try that with my patch to handle negative position for outputs, and while my patch does what it says on the tin, it won't work because X will not allow for negative root coordinates, it basically clamps the root coordinates to (0,0) -> (width, height) so any X window located in the negative range of root coordinates will receive no pointer event.

I noticed xrandr allows for negative positioning but would normalize coordinates so that the top left corner would always be on (0,0) but could not find where in the Xserver this was done. Until I found out, it's not in the Xserver but in xrandr (the command) instead:

http://cgit.freedesktop.org/xorg/app/xrandr/tree/xrandr.c#n2074

I susopect doing the same in Xwayland is not really workable because only the compositor knows the number and positions of all outputs initially, so moving outputs as we receive notifications from the compositor fools the whole computation of relative placements of outputs.
 
> > [*] Why? So it does not need to move all existing outputs, which would
> > lead to sending geometry events for all outputs rather than just one,
> > and perhaps updating the internal position of every wl_surface.

I am really tempted to think it's a case of let's not do that, I'm pretty sure it would break X in many subtle ways.

Now, if someone wants my patch that does what it's meant but then breaks X, just let me know and I'll post it here.

Cheers,
Olivier


More information about the xorg-devel mailing list